Iroh 1.0 Wants You to Dial Keys, Not IP Addresses

Anyone who has tried to open a direct connection between two devices behind separate NATs knows the pain: STUN servers, TURN relays, ICE candidate gathering, and the quiet acceptance that some fraction of your traffic will end up bouncing through a relay you pay for. Iroh has spent four-plus years trying to make that problem someone else's, and as of this week it has shipped its first stable release, 1.0.

The pitch hasn't changed since the early versions: dial keys, not IPs. Instead of addressing a peer by an IP that can vanish when a device roams between networks or hides behind a firewall, you address it by a public key the device owns and controls. That key stays constant as the device moves, secures the connection, and doubles as the basis for identity, permissions, and attribution. The Iroh team likes to describe the end state as turning the internet into "a secure localhost" — which is marketing-speak, but it's pointing at a real and familiar idea.

What's actually under the hood

If the key-as-address model sounds like Tailscale or libp2p, that's because they share DNA — encrypted overlay networking with relay fallback and direct-connection upgrades. Iroh's distinguishing bet is to build the whole thing on QUIC and lean on IETF drafts wherever it can rather than rolling proprietary protocols. The 1.0 announcement lays out the pieces the project says it built to get here:

• A custom QUIC multipath implementation, so a single connection can manage multiple routes and hot-swap between them as network conditions change.
• QUIC NAT traversal that establishes direct connections while keeping connection details encrypted.
• Local-first configuration, so devices can discover and connect to each other on a LAN with no internet access at all.
• WASM support, with the project claiming it continuously checks that Iroh compiles to WebAssembly and runs in the browser.
• Hooks for injecting custom connection logic, and custom transports that fit under the same dial-by-key abstraction — Bluetooth Low Energy, WiFi Aware, Tor, and LoRa (which the team flags as still under construction).

The payoff Iroh emphasizes is going direct. It says it's normal to see 95% of a connection's data pass straight between devices rather than through the cloud, which means lower egress bills and fewer router hops. Treat that 95% as a vendor figure measured across their own fleet rather than a guarantee for your workload — real-world NAT traversal success depends heavily on the network topologies and middleboxes involved, and there will always be a tail of connections that can't punch through and fall back to a relay.

Relays, and who pays for them

That fallback is where the economics live. Iroh runs a set of public relays, most commonly reached through the n0 preset when you build an endpoint. The project says those public relays have seen more than 200 million endpoints created in the last 30 days alone, and that Iroh is running in production on hundreds of thousands of devices — figures worth noting but, again, self-reported.

Advertisement

AirDroid Personal Best mobile device management suite — only $3.99/mo →

The relays matter because they're the safety net when direct connections fail, and they come with strings: public relays are rate-limited for relayed traffic, and those limits can change at any time. The relay binaries are open source, so you can run your own, and n0 also offers hosted relays as a paid service. This is the same shape as Tailscale's DERP servers — fine for getting started, something you'll want to think hard about before you build a product on someone else's free tier.

Stability promises you can plan around

The most consequential thing about a 1.0 isn't usually a feature — it's the contract. Iroh is asserting wire-protocol stability: a v1 endpoint will talk to another v1 endpoint regardless of minor version or implementation language. Any change that breaks wire compatibility will coincide with a major release, and the team says it may eventually version the wire protocol and the language APIs independently — bumping a language API to v2 while keeping the wire format compatible, for instance. For anyone shipping software that has to interoperate across versions in the field, that's the line that makes the difference between "interesting" and "adoptable."

The support schedule is spelled out alongside it:

The 0.35 line won't get further releases, and the canary (0.9x) and release candidate builds are dropped as of launch. Wire-breaking relay changes get new URLs so older clients keep working — a sensible touch. If you're on an older version and hit a bug, the team's request is the usual one: reproduce it on 1.0 before filing, since a lot of fixes landed in the jump.

Bindings beyond Rust

Iroh is a Rust crate at heart, and earlier on the project paused its foreign-function-interface support, citing the maintenance cost of chasing a churning API. With a stable surface to commit to, 1.0 brings official Python, Node.js, Swift, and Kotlin bindings back. The practical unlock is mobile: you can now embed Iroh into a Swift iOS app or a Kotlin Android app, which is exactly where peer-to-peer connectivity and roaming-across-networks problems tend to bite hardest.

Whether Iroh is the right abstraction for your project still comes down to the usual questions — how much you trust the direct-connection hit rate on your users' networks, whether you're comfortable depending on public relays or willing to host your own, and how much you value building on QUIC and open standards versus a more battle-tested stack like WireGuard-based meshes. But a stable wire protocol, a published support schedule, and four official language bindings are the things that turn a promising library into one you can actually justify shipping. On that count, 1.0 is the release that matters.