matheus23

There's no LLM endpoint :) These prompts were meant for humans to fill in :P (this post was from 2024)

That said, this was an old blog post that never actually got finished, so we've taken it offline and replaced it with a redirect to our relay docs page.

You need to know the public key you communicate with ahead of connecting to the correct relay. It needs to be shared securely out-of-band, relays don't help with that.

Somewhat easy, unfortunately.

If you look at Wireguard traffic, you'll see a <EndpointID>.iroh.invalid SNI in the QUIC Initial packet.

Encrypted ClientHello can fix that, but support hasn't shipped into rustls yet. So it's definitely fixable.

The interesting thing is that the ClientHello is undetectable when it's sent via the relay transport (sent inside a WSS connection). And in that case, any traffic that happens on IP is fully encrypted and can't be categorized.

We keep thinking about ways to combine iroh + zeroMQ! I think these two could compose. (Not familiar with nanomsg myself)

About tailscale: It's similar, but iroh is not a VPN, so it doesn't add a TUN interface. Instead, you'd build iroh directly into your application. Using iroh you can build a VPN, and there are projects that do so (iroh-lan/iroh-vpn are some hobbyist projects). The upside of building it into your application is that it doesn't need special permissions and is easy to ship to the user.

The secret is that iroh still uses IPs under the hood :) But with QUIC, your connections aren't bound to your four-tuple, your connection can migrate from e.g. WiFi to Cellular with only a small blip/hiccup. And with QUIC multipath, you can have multiple four-tuples "active" at the same time. iroh uses e.g. a "real" IP path mainly, with a websocket-based HTTPS path via relay servers as the backup (e.g. in case UDP is blocked).

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