Thomas Eizinger

https://github.com/libp2p/rust-libp2p/pull/3763 is a pretty classic refactoring that users will have to do. The new version is more verbose but I _think_ that for new-comers, it is easier to understand because...

The remaining items for this one are: - ~`libp2p-rendezvous`: Ideally fixed by doing #3878.~ - `libp2p-relay`: Currently uses `OutboundOpenInfo` to track data alongside the actual upgrade. To remove this, we...

In https://github.com/libp2p/rust-libp2p/pull/4275, there is a discussion about whether we should actually remove these associated types. A middle-ground could be to only keep `OutboundOpenInfo` perhaps? Opening a stream is always asynchronous,...

> So he should know and do much more rather than with the associated types. This is what I am not so sure about. Storing / mutating state is "just...

> > We might be able to mitigate that by adding helper components that users can compose into their ConnectionHandler. > > Yes, this is a necessary thing. I have...

> A brief search around the codebase showed that there is no use case for the open info. Should this be added to `0.54` milestone? Yes we could. We would...

Related: https://github.com/libp2p/rust-libp2p/pull/4779.

> So even if my app is making request from port 30535, the actual request will go from a random port. If I make request from that port to a...

> So looks like you're saying that address translation will be moved to identify at some point in the future? Yes that is the plan. Identify is the protocol that...

> Note that the 500ms interval is for the tests, but I'm curious how we can properly estimate those. > > > I think the issue with this approach is...