Thomas Eizinger

I'll see to spend some cycles on it soon.

Closing because stale.

So I thought a bit more about this. The current abstraction allows us to directly yield a message from the upgrade. That actually takes some boilerplate off the handler and...

> To progress on this front (other than something like #2878), I am thinking of going with a `FuturesUnordered` wrapper that: > > * Wraps the future in a timeout...

The `TimedFutures` type will allow us to replace the "timeout" feature currently provided by the upgrade mechanism. @mxinden [seems to agree](https://github.com/libp2p/rust-libp2p/issues/2863#issuecomment-1238152925) that we won't be losing much type-safety. Hence, the...

You need to implement `IntoConnectionHandler` instead of `ConnectionHandler`. That will give you access to the `ConnectedPoint`.

> right, thanks Thomas. What about `listen_addresses` and `supported_protocols` needed to create the Identify `Info`? > We only get them from `PollParameters` on `NetworkBehaviour::poll` not `ConnectionHandler:poll` and we need ....

> > > right, thanks Thomas. What about `listen_addresses` and `supported_protocols` needed to create the Identify `Info`? > > > We only get them from `PollParameters` on `NetworkBehaviour::poll` not `ConnectionHandler:poll`...

It makes the implementation of the handler more complicated because you now have to suspend the substream and can't use async-await to implement the protocol (unless you use a channel)....

Status update: We now enforce that each PR uses conventional commits: https://github.com/libp2p/rust-libp2p/pull/3204 This should allow us to at least stop writing changelog entries in every PR and instead generate one...