Is that not what libp2p already offers? Not sure if it has QUIC out of the box, but hole-punching to UDP connectivity and then running QUIC over it isn't that hard.

▲

karissa 6 hours ago | parent | next [-]

The folks who made iroh worked on libp2p first, but found many limitations in libp2p's design. iroh is a better more flexible and powerful version of libp2p

▲

orthecreedence 6 hours ago | parent | prev [-]

Libp2p does have quic, at least the rust implementation.

▲

rklaehn 6 hours ago | parent | next [-]

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

	▲	ianopolous 5 hours ago \| parent [-]
		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.

▲

dignifiedquire 6 hours ago | parent | prev | next [-]

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.

▲

dannyobrien 4 hours ago | parent | prev [-]

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