I was just reading the QUIC multipath RFC. Didn't it come out literally yesterday? I guess it's common to have the implementation foreshadowing the RFC but it's jarring to see them back to back like this.
It’s common enough for groups to not consider the spec done until there is a decent bit of implementation experience (both because actual implementers tend to find interesting bugs in specs, and because many things are hard to measure without any implementation).
iroh seems like a very well positioned product in the era of people rapidly building applications for personal use. I'm really interested in seeing how they continue to grow.
I personally have been looking off and on at providing an "app relay" using it, where people can get an OSS, self-hostable (if desired), zero config way to remotely access their app/data on their network. This would be separate than a "network relay" (a la Tailscale), as this is done selectively as part of the application server and client, requires no knowledge or configuration as the user, and exposes a much smaller surface area.
I’m excited to have a weekend to just sit down and tinker with iroh, it’s been on my list for a while. I want to make an overlay network like nebula with it
Excuse me if this is explained somewhere, but how does noq/iroh relays QUIC packets between peers? How does relay know which QUIC packets it receives should be sent where, since QUIC is famously hard to track? Do you stream to relay new/retire_connection_id packets through different connection so that it can link them to specific peers? Or is the relayed QUIC wrapped in different protocol?
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).
Can this establish an QUIC connection without the other end having a CA cert? Or, like most other QUIC libs will it default to only allowing connections to corporation approved domains?
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.)
23 comments
[ 5.0 ms ] story [ 40.1 ms ] threadIt's lovely to see the polite and respectful back and forth in this comment thread where the Iroh folks are talking about deciding to fork. :)
"Rough consensus and running code" is the IETF's unofficial motto. Working Group Drafts are generally accompanied by implementations.
I personally have been looking off and on at providing an "app relay" using it, where people can get an OSS, self-hostable (if desired), zero config way to remotely access their app/data on their network. This would be separate than a "network relay" (a la Tailscale), as this is done selectively as part of the application server and client, requires no knowledge or configuration as the user, and exposes a much smaller surface area.
I’m excited to have a weekend to just sit down and tinker with iroh, it’s been on my list for a while. I want to make an overlay network like nebula with it
> 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).
Wouldn't that be n0q then?
Which got it's name from 'Not Coq'