Max Inden

> > 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...

> I'd expect the behaviour to be notified. :+1: like we do for new listen addresses via `FromSwarm::NewListenAddr` I think we should have an event informing a `NetworkBehaviour` of a...

Closing here with #3208 merged.

Closing here since stale and not needed.

With https://github.com/prometheus/client_rust/pull/105 and the latest `prometheus-client` `v0.19.0` release, this should be resolved. @ackintosh @divagant-martian please comment in case I am missing something.

> 1. `inject_listen_negotiation_error` for errors during the multistream select protocol execution. Not specifically related to the protocol of this `ConnectionHandler`. In case neither us nor any user ever makes use...

> Thanks for the update @jxs I am bit preoccupied with some issues on js-libp2p so I haven't had a chance to work on this. Perhaps it may be best...

> Basically switching a third level of enum variant, `ConnectionEvent::ListenUpgradeError::UpgradeError::Err` > for two second level enum variants, > `ConnectionEvent::DialNegotiationError::ConnectionHandlerNegotiationError` and > `ConnectionEvent::ListenNegotiationError::ConnectionHandlerNegotiationError`. Just to make sure we are on the...

> But then who should deal with the Timeouts when negotiating streams, or rather, where were you thinking having `inject_listen_negotiation_error` ? On the outbound side we know which `ConnectionHandler` initiated...

> Is there an issue or note somewhere what is missing for a working setup with QUIC + DCUTR + relay v2? As far as I remember, the only thing...