Thomas Eizinger

> **Status Update** > > #3454 merged and thus our `libp2p-quic` implementation depends on upstream `quinn` directly. Thank you @kpp for the work. In case no major blockers are discovered...

> I am still in favor of this change. @efarg let me know in case you are still interested in contributing this change. (Sorry in case I am missing a...

I'll leave that for future maintainers to decide.

I've put up a draft PR [here](https://github.com/libp2p/rust-libp2p/pull/3099) that aims to build the foundation for the above idea.

> The proposal would work very well for us and save a lot of time spent on disconnecting peers we were not interested in having in the first place +1...

Unless I am missing something, the only thing not possible with my proposal is blocking a new incoming connection _before_ the upgrade process is finished. For any policy that purely...

We could retain a prototype-based system where creating a handler is a two-step process for inbound connections: - Replace `new_inbound_handler` with `on_new_pending_connection` that returns a `Result`. - The `Ok` of...

> > The second failure point can be used for established connections and policies like banning by peer ID. > > But that second failure point needs some synchronization mechanism...

> I've put up a draft PR [here](https://github.com/libp2p/rust-libp2p/pull/3099) that aims to build the foundation for the above idea. Removing `IntoConnectionHandler` is proving difficult (see PR comments). I am tempted to...

I put up a draft PR here for what this could look like: https://github.com/libp2p/rust-libp2p/pull/3118