Libp2p does have quic, at least the rust implementation.

libp2p does have QUIC, but it is one of many possible transports.

So libp2p builds many things on top of the underlying transport where we use QUIC directly and use existing mechanisms such as TLS ALPNs for protocol negotiation.

We also use the stream multiplexing that is built into QUIC instead of putting a stream multiplexer on top of QUIC.

You can think about it like this: libp2p abstracts transports as streams, and then puts many required features on top (protocol negotiation, stream multiplexing)

Iroh uses QUIC and abstracts transports below QUIC. We can work with any unreliable datagram transport that has (or can be hacked to have) a minimum MTU of 1200 bytes (needed to be QUIC compliant).

Minor clarifications, but libp2p also uses TLS ALPN for protocol negotiation, and also uses native quic streams - there is no additional muxer layer when using quic.

Iroh is still awesome.

Yes, but libp2p was mainly designed around the limitations of tcp, as quic simply wasn't there yet when the design started. Iroh gets the benefit of having been designed and built from the ground up, based on quic.

would it possible to have iroh as a libp2p pluggable transport? So you could dial a iroh node with /iroh/proxy/ed25519key?