matheus23's comments

There were experiments :) https://github.com/dignifiedquire/nquinn

The cool thing about noq (and Quinn, where we inherited this from), is that you can implement your own "Session" trait. So that can be either TLS or nQUIC.

The TLS authentication story is fully configurable. This hasn't changed compared to Quinn. We use noq in iroh, and in iroh we use raw public keys (RFC7250). When you use iroh, you don't need to set up DNS or TLS certificates, you just generate a key, share the public key and others can connect to you. (Of course the trouble is sharing the public key securely.)

noq doesn't implement any relaying logic itself. From the perspective of noq, iroh relays are another IP subnet that it's sending packets to and receives packets from, so just another path.

> Or is the relayed QUIC wrapped in different protocol?

Yes, that's what's happening.

On the iroh/iroh-relay side, we implement this relaying using WebSockets. The datagrams are wrapped with a header saying which EndpointId (ed25519 public key) we want the packet to be relayed to. Because of a handshake between iroh clients and iroh relays, the relay knows and has authenticated the source EndpointId of datagrams it relays.

So yeah, we're tunneling QUIC datagrams through HTTPS over TCP (we encrypt twice). The relay really is just a fallback and for coordination. We specifically made these choices for maximum ubiquity for the fallback (not affected by UDP blocking, looks like "normal" traffic).