GoKawiilToday we're delighted to announce noq (”number 0 QUIC”), our own general purpose QUIC implementation with multipath and NAT traversal support. It is the transport layer that has been powering iroh since v0.96, though is in no way limited to iroh's usecase.
From soft fork to hard fork
If you've been following iroh's development, you may have read why we forked Quinn back in 2024. The short version: iroh was doing a lot of heavy lifting around QUIC: switching between relay and direct paths, managing NAT traversal, juggling congestion state. But QUIC itself had no visibility into any of it. That mismatch created problems that we couldn't fix from the outside.
Our fork started small. We wanted to track upstream Quinn closely, contribute back where we could, and keep our diff minimal. That was the right call at the time. But as we pushed further into QUIC multipath, NAT traversal, and our own relay-as-a-path architecture, the development velocity of the two projects drifted into iteration cycles that didn't match. All our constant changed would lead to an unreasonable review burden for the Quinn maintainers. The n0 team wanted to try deeper, structural changes to our QUIC implementation, and it would have been unfair to foist the consequences of those changes onto all Quinn users. We think a hard fork with a continued commitment to collaboration makes more sense all around.
So we went all the way. We explained our thinking in the Quinn multipath issue thread. This isn't a rejection of Quinn, which remains a great implementation. It's an acknowledgment that the problems we're solving are specific enough that a separate codebase, with collaboration where our interests overlap, is the honest path forward.
What's in noq
The headline feature is a full implementation of the QUIC Multipath spec. This is where the real architectural shift happened, both inside Quinn/noq and for iroh's use. Before multipath, iroh managed multiple paths (relay, direct IPv4, direct IPv6) as a kind of sleight of hand below the QUIC layer. Quinn thought it was talking to the other endpoint via just one IP address while we shuffled packets across whichever path was working best. Kind of like iroh's own small NAT around Quinn.
With multipath, those paths are first-class QUIC concepts. The relay path is a QUIC path. The direct UDP path is a QUIC path. QUIC knows about all of them, maintains per-path congestion state, and can reason about which one to use. This means the latency improvements we had to hack in via congestion controller resets are now handled correctly and systematically.
The multipath implementation is generic though, it does not only serve iroh. It aims at being a full implementation of the QUIC Multipath spec, for any purpose. The implementation is still young however, so if you need more APIs from it, let us know.
We've implemented our own interpretation of the QUIC NAT traversal draft. To our knowledge we're the first to do this in a production-grade, robust way. NAT traversal is notoriously finicky, getting it right across the full range of NAT behaviors in the wild is a hard problem, and we've been battle-testing our approach across the hundreds of thousands of devices already running iroh. Though this is in no way a settled spec yet, we will keep iterating.
... continue reading