Breaking API changes and other feedback requests

[thomaseizinger]

I am opening this issue to provide a central place that users of rust-libp2p can subscribe to for potential breaking changes and other feedback requests that the rust-libp2p maintainers might have. The idea is that we (@libp2p/rust-libp2p-maintainers) post a link to a discussion, comment, pull request or issue with a short description as a comment under this issue. This will trigger a notification to every subscribed person and allow them to weigh in on the discussion if it concerns them.

Please refrain from discussing within this issue itself but use emoji reactions instead to indicate your thoughts (if you want to):

• 🚀 I've read the discussion and I support the idea.
• 👀 I've read the discussion and I am ambivalent about it.
• 👎 I've read the discussion and I disagree: Please weigh in on the linked discussion itself so we can iterate on the idea.

[thomaseizinger]

Tagging an initial list of users that I am aware of: @rkuhn @divagant-martian @dignifiedquire @melekes @da-kami @DieracDelta @austinabell @jolestar

[thomaseizinger]

I'd like to get some feedback on an idea that involves a breaking API change on SwarmEvent: Removing the THandlerErr type parameter and always boxing up the handler error instead. See #3201.

[jolestar]

Tagging an initial list of users that I am aware of: @rkuhn @divagant-martian @dignifiedquire @melekes @da-kami @DieracDelta @austinabell @jolestar

add @sanlee42

[thomaseizinger]

We are considering removing the handler from the ConnectionClosed event without a replacement: #3046 (comment)

Currently, this functionality can be used to extract some final information from the handler after a connection got closed. We are wondering whether anyone actually uses this functionality and whether that usecase could perhaps be modeled differently.

Please weigh in on the linked issue with your opinion.

[thomaseizinger]

A call-for-testing: We have just released libp2p-yamux 0.43.0-alpha. It is compatible with libp2p 0.50.0 but contains large internal refactorings.

We would very much appreciate it if folks could run this version on their network and tell us if it breaks anything (the expectation is that it does not). You should be able to just drop it in your dependencies and import yamux from that crate instead of via libp2p::yamux.

See #3013 for more details.

Thank you!

[thomaseizinger]

A call-for-testing: We have just released libp2p-yamux 0.43.0-alpha. It is compatible with libp2p 0.50.0 but contains large internal refactorings.

We would very much appreciate it if folks could run this version on their network and tell us if it breaks anything (the expectation is that it does not). You should be able to just drop it in your dependencies and import yamux from that crate instead of via libp2p::yamux.

See #3013 for more details.

Thank you!

Has anyone had a chance to deploy this to a live network? 🙏

[thomaseizinger]

We are considering to drastically cut down the number of errors that are reported to a ConnectionHandler. See #3353 (comment). We imagine users to welcome this change as it should simplify a lot of code.

Please speak up if the proposed change would break something for you.

[thomaseizinger]

We are considering to add tracing to libp2p to capture contextual information around connections: #1533

Please speak up if this would break something for you.

[thomaseizinger]

Any async-std users amongst our users? I'd be interested to know why and whether moving libp2p to tokio-only would be a problem for you: #4286