Support upgrades on libp2p_quic::GenTransport

[kayabaNerve]

Description

Support InboundConnectionUpgrade, OutboundConnectionUpgrade, on libp2p_quic::GenTransport.

Motivation

I have an InboundConnectionUpgrade and OutboundConnectionUpgrade to replace the encryption layer's PeerIds with my own long-lived identity keys (unsupported by libp2p, hence the need for the custom middleware). While tcp lets me provide such upgrades, quic doesn't, with the quote:

Note that QUIC provides transport, security, and multiplexing in a single protocol. Therefore, QUIC connections do not need to be upgraded. You will get a compile-time error if you try. Instead, you must pass all needed configuration into the constructor.

I spent a few hours seeing if I could manually wrap GenTransport, or compose with and_then, to achieve the desired effects but I was unable as libp2p-quic yields Connection, not Stream to these locations. I'd have to further wrap Connection into my own which applies upgrades while manually calling poll_inbound/poll_outbound. While I am debating doing that, having just spent a notable amount of time attempting to do this and wanting to be successful, I don't feel I should have to. I should be able to just provide arbitrary connection upgrades. QUIC may be great and not need upgrades, but that doesn't mean it should be limited as to not support upgrades.

Requirements

• Make an underlying type which accepts connection upgrades
• Make GenTransport an alias to the underlying type with no connection upgrades (optional)

Open questions

No response

Are you planning to do it yourself in a pull request?

No, as I don't believe I have the proper expertise

[kayabaNerve]

Actually, I'm unsure even Connection would be the possible place for me to do this as that's after libp2p has yielded a PeerId for this connection. While and_then lets me malleate it, I can't read/write without obtaining a stream. While I could spend the time to work on if that's valid, the fact it's a Poll-based API (not a Future-based API) reaffirms my belief this should be supported in a first-party sense.

[elenaf9]

How exactly do you use your custom keys in the network? Just to verify that the remote peer is a authenticated peer in the network (i.e. to check if a connection should be established or not), or as an identifier for peers in the network?
In case of the latter: is my assumption correct that your key can be converted into a PeerId?

[kayabaNerve]

The latter.

Yes, in the sense PeerIds are bytes and you can put whatever you want there. Referring to the examples/common practice, if you use noise, the long-lived Ed25519 key used with noise becomes your PeerId. My key isn't Ed25519 so I cannot use it directly with noise. I need to define my own security upgrade, whereas noise returns the long-lived Ed25519 key as its PeerId, I return my key.

https://github.com/serai-dex/serai/blob/next/coordinator/p2p/libp2p/src/authenticate.rs for my literal upgrade. I use this with allow-block-list, populated with PeerIds of this form.

I'm sure I could alternatively use a construction on top of identify, or my own behavior, yet then I can't identify peers by their keys without defining, maintaining, and passing around an additional mapping for the translation. This was by far the most ergonomic solution.