iroh

Wanted to sync data between two of my apps without standing up a server, and iroh just did it. No IP addresses, no port forwarding nightmare, no cloud bill at the end of the month. Connect by key and you are talking. I had a working prototype before my coffee went cold. This is the peer-to-peer library I kept wishing existed every time I gave up and reached for a server.

Stood up a working peer-to-peer connection in about forty lines, most of which was my own logging. Dialing by key instead of address removed an entire class of configuration I usually dread. It reconnected cleanly when I moved my laptop between networks mid-stream. Boring in the best way. I trust it enough to put it under something real.

I tried to break the relay fallback because that is my job. Pulled the network out from under an active connection, switched between wifi and tethering, blocked the direct path at the firewall. It kept the stream alive every time, slower on relay but never dead. Operationally that resilience is worth more than the raw numbers. I would page someone over this far less often.

I have written enough holepunching code by hand to be wary of anything that promises to make it pleasant. Iroh mostly delivers. Dialing by public key is the right abstraction, and the connection it hands you is a real authenticated QUIC stream, not a leaky wrapper you have to fight.

I cared about two things: how it behaves when the direct path fails, and what it costs me in allocations on the hot path. The relay fallback is transparent and fast enough that a multipath workload did not stutter when I killed the direct route mid-transfer. Throughput stayed close to a hand-rolled QUIC baseline, which is high praise from me.

The modularity is the quiet win. I pulled in only the pieces I needed instead of swallowing a framework whole. If you are building peer-to-peer anything in Rust, this saves you the most miserable six months of the project.

I do not trust networking libraries until I have read how they handle the unhappy paths, so I spent an evening with iroh's internals before I let it near anything I care about. I came away more impressed than I expected, and with a few honest reservations worth writing down.

The core idea is dialing by public key. Instead of asking where a peer is, you ask who it is, and iroh takes responsibility for finding and maintaining the fastest connection to that identity. This sounds like a small reframing and is actually a large one. Addresses are an implementation detail that change constantly as devices move between networks, and most of the pain in peer-to-peer code comes from treating a mutable address as if it were a stable identity. Iroh moves that mess behind the API where it belongs.

Underneath, the connection you get is QUIC, authenticated against the key you dialed, which means encryption and identity are not bolted on afterwards but are the substrate. I read through the path where the direct connection cannot be established. Holepunching is attempted first, and when the network is too hostile for that, traffic falls back to a relay. The part I appreciated is that this fallback is not a separate code path you have to handle. From the application's point of view the stream simply stays up, slower but alive. I tested this by severing the direct route mid-transfer and the data kept flowing without my code noticing.

The modularity deserves a mention. This is not a monolith that demands you adopt its worldview. The networking stack is composed of pieces, and you pull in the protocols you actually need on top of the base connection. For anyone who has tried to extract one useful feature from a framework that wanted to own your entire process, this restraint is a relief.

My reservations are mostly about expectations rather than the code. Carrier-grade NAT and aggressively symmetric firewalls will still defeat direct connections, as they defeat everyone, so you must design for the relay path as a normal mode of operation rather than a rare degradation. The relay is good, but it is not free, and a deployment that quietly relays everything will cost more and run slower than the benchmarks on a friendly network suggest. The documentation is solid for getting started, though I had to read the Rust docs directly to understand some of the connection lifecycle, which a more narrative guide could smooth over.

None of that changes my overall read. This is the most honest and least painful peer-to-peer stack I have used in Rust, and it gets the fundamental abstraction right in a way that most attempts do not. I have already started rebuilding a side project on top of it. The question I am sitting with now is less about whether it works and more about operations: at what scale does running your own relay infrastructure become the sensible move rather than leaning on the defaults?

Peer-to-peer libraries have broken my heart for two decades, so my standards are low and my patience lower. This one did not annoy me, which is the highest compliment I give. The API is small and the connection actually holds. My one caveat: NAT traversal still fails against the most hostile carrier-grade setups, as it must, so plan for the relay path rather than praying the direct one always wins.