Thomas Eizinger
Thomas Eizinger
> If none of the code changed, then it's also possible this is a bug in cargo-semver-checks. I'll open a triage issue in the cargo-semver-checks repo and take a look...
> Sounds good to me. Also, should we be using `either::Either` or `futures::future::Either` or both? I am not sure how well maintained `either::Either` is but feels like the more appropriate...
> I've had a brief look and for example the Error impl in either::Either is not overriding all methods so it may need a bit of upstream work until we...
I've opened an issue regarding pin projection which is another blocker for some of our `Either` use cases: https://github.com/bluss/either/issues/76
I think that is a really good idea actually!
> I'll like to start contributing to rust-libp2p. [...] Before I go ahead, I'll like to ask if this is a welcome contribution. Thank you and yes, definitely! Some of...
Wow, this is super interesting! It might be a challenge though for the current abstractions in (rust) libp2p. As the [README](https://github.com/matrix-org/pinecone#why-not-libp2p) explains, libp2p is primarily designed around the abstraction of...
> I have been running into challenges with protoc installs as well, given that the protobufs rust-libp2p usually uses are quite simple, we should figure out if one of the...
Thanks @dignifiedquire ! Do you mind adding some rationale on why this is better? :) Is it supposedly easier to understand? Less susceptible to certain error conditions? Better encapsulation?
Thanks for that! I'll have a look with that in mind later :)