What problem does iroh solve?
iroh is built on QUIC and doesn’t try to reinvent the wheel; it combines existing IETF standards in a new way. The concrete problem it solves is connecting two devices that can’t easily reach each other today. Say one device is in your home WLAN behind a NAT and the other is on a 4G network or behind a different NAT at work. In most cases iroh can establish a direct connection between the two via hole punching, giving you the highest possible bandwidth and the lowest possible latency. Reliably getting that direct connection across arbitrary networks was not a solved problem until now. On top of that, iroh lets you dial a device by its public key (its Endpoint ID) instead of by IP address, so you don’t need to know or care where the other device currently sits on the network.Is iroh a replacement for IP addresses?
No, iroh is an addition, not a replacement. IP isn’t going anywhere, and iroh runs on top of it, adding two capabilities: the ability to dial an endpoint by its public key, and the ability to get a direct connection whenever one is possible. Because applications dial by key rather than by address, iroh is also well positioned for the future. If some other technology eventually replaces the IP address paradigm, nothing changes from the application developer’s point of view: you still dial by key, and iroh makes sure under the hood that you get the best possible connection, over IP or otherwise.How is iroh different from other peer-to-peer networks?
The main difference is that iroh tries to use existing IETF standards as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation. If you look at one in Wireshark, it’s indistinguishable from any other QUIC connection, so existing tooling works and what you learn using iroh transfers to plain QUIC and vice versa. Many iroh contributors come out of the P2P world and had a bit of “abstraction fatigue” after years of working on traditional P2P networks. So where many P2P networks ship their own DHT for discovery, iroh resisted that temptation and instead uses the biggest DHT that already exists, BitTorrent’s Mainline DHT, for peer-to-peer address lookup. Some “regular P2P networks” actually run on iroh under the hood, including Holochain and various P2P chat apps.Does iroh use relay servers?
Yes, and relay servers are a core part of what makes iroh connections reliable. See the Relays concept page for a full overview. Relays serve two roles: they assist with NAT Traversal to help establish direct P2P connections, and they act as an encrypted fallback when a direct connection can’t be made. In practice, roughly 9 out of 10 connections go direct; the relay is only a stepping stone. Because relays are stateless (they route encrypted packets but store nothing), they’re cheap to run and easy to scale. There’s no database to sync, no state to migrate, and automatic failover across relay instances is built in. By default iroh is configured with four public relay servers run by number 0 (two in the US, one in Europe, and one in Asia), free to use for development and testing. To prevent abuse, throughput through public relays is rate-limited. For production workloads, you can run a dedicated relay or self-host your own.Can relays read the traffic they route?
No, all connections in iroh are end-to-end encrypted. We use QUIC which is based on TLS 1.3. From the perspective of our QUIC implementation, the relay is “just another UDP socket” for sending encrypted packets around. Because the relays are relaying traffic, they theoretically know that Endpoint ID X talks to Endpoint ID Y and how many bytes are sent this way, but only for as long as these endpoints haven’t established a direct connection yet. However, we don’t record this data on our relays.How secure is iroh’s end-to-end encryption?
Iroh provides a secure, encrypted, forward and backward-secret, authenticated data channel between you and the recipient and protects you both from eavesdroppers. This assumes the Endpoint ID you’re connecting to was exchanged securely, e.g. via scanning a QR code, sharing a link with the Endpoint ID in an encrypted chat app or using a trusted server and the corresponding secret keys haven’t been compromised. The established connection is a QUIC connection, which together with TLS 1.3 specifies how it’s encrypted. This specification is widely used, for example as part of the latest generation of HTTP, HTTP3. Instead of PKI-based certificates, at the moment iroh uses self-signed certificates with Endpoint IDs to authenticate both ends of the connection, borrowing the libp2p handshake specification. In the future, we plan on switching to the raw public key TLS certificate type instead. To make use of this end-to-end encryption, no additional setup in iroh is required, it is always enabled. Be aware of security caveats to forward secrecy when using the opt-in 0-RTT feature.What if number 0 stops running relay servers?
You’re not dependent on us. The relay code is open-source, and running your own is possible. The easiest path is a dedicated relay via Iroh Services, which gives you an isolated, managed relay with uptime guarantees. If you’d rather self-host, you need a server with a public IP and a DNS name pointing to it. Automatic TLS via ACME is built in. Either way, configure the relay URL for your endpoint (see Use your own relay) and you’re set. Running your own relay doesn’t affect interoperability. Your endpoints can still connect to peers using other relay servers, and since relays are stateless and logic lives at the client, can be swapped independently.What are the risks of running a public relay?
Running a public, unauthenticated relay means you act as the home relay for anyone who has your relay in their relay map and is close to you in terms of latency. The main practical consequence is traffic: you might get a lot of it, so you’ll want to configure rate limiting, as we do on our public relays. The security exposure is limited. The traffic you relay is fully end-to-end encrypted and cannot be decrypted by the relay. The only information a relay has is what it needs to function: the endpoint IDs and IP addresses of the endpoints currently connected to it, plus which endpoints are paired. A relay has no egress to the open internet, so if you’re comparing it to Tor, running a relay is like running a guard/middle relay, not an exit node.Is establishing a connection without relays or when offline possible?
Yes. When you share aEndpointAddrs with “direct addresses”, then iroh will try to use these addresses to establish a connection with or without a relay.
If you’re in a local network together you can enable local network address lookup to help establish connections in LANs even when the EndpointAddr doesn’t contain direct addresses.
How can I control which relay servers iroh connects to?
Iroh will only talk to relay servers that it knows URLs for. By default iroh is configured with 3 relay servers from the defaultRelayMap.
If your endpoint has address lookup services configured (which is
the default with the N0 preset), then iroh might connect to
relay servers discovered that way.
By changing iroh’s relay mode or relay map you can control the home relay the endpoint connects to, and by wrapping or writing your own AddressLookup service, you gain control over the relay URLs iroh can discover.
How can I monitor endpoint connection status to update a UI?
If you want a proxy for general internet connectivity, you can watch whether the endpoint currently has a relay connection:impl Watchable<Value = bool> that reflects whether the endpoint believes it’s connected to a relay, a reasonable signal for “has outside connectivity”.
How do you limit which nodes can join?
Iroh gives you full control over which endpoints are allowed to connect via endpoint hooks. Hooks let you intercept incoming connections before they’re accepted, so you can allow or reject them based on the connecting endpoint’s ID, your own allowlist/denylist logic, or any application-specific policy.What is “Address Lookup” in iroh and which one should I enable?
For most usage, using the services that are enabled with theiroh::endpoint::presets::N0 preset is the best default.
Address Lookup helps iroh find ways to connect to a specific Endpoint ID.
The Endpoint ID on its own can only be used to identify if you’re talking to the right recipient, but doesn’t tell how to address the recipient on its own.
Via configured address lookup mechanisms, iroh resolves an Endpoint ID to IP addresses and relay URLs that help to actually attempt a connection.
For more information on available address lookup mechanisms, take a look at the address lookup docs.
It’s also possible to combine multiple address lookup mechanisms at once, or write your own.
We think it’s particularly helpful to write application-specific address lookup mechanisms that are tailored to an application’s need.
Does using the Mainline DHT mean BitTorrent clients respond to iroh lookups?
First, peer-to-peer address lookup over the Mainline DHT is an optional feature that you have to enable explicitly. It’s disabled by default, partly so that mobile apps don’t look like BitTorrent clients and get flagged by the OS. Mainline itself is very frugal in terms of resource use. When you do a P2P address lookup, any Mainline server node could respond: each BEP 44 record is stored on 20 random Mainline nodes. So yes, a BitTorrent client that participates in the DHT as a server and has been running long enough to be in the routing tables will respond.What ports does iroh use?
Iroh listens on Two UDP ports: one for IPv4 and one for IPv6, used for direct P2P connections; configurable viaendpoint::Builder
Iroh will work behind firewalls that only allow TCP outbound, but direct connections won’t be possible in that case; all traffic will fall back to the relay.
It’s totally possible that you maintain connections to multiple relays at a time, if you’re connected to iroh endpoints that have another home relay than yours. Each of these connections will use another TCP socket.
How would onion-routing work with iroh?
Iroh supports custom transports, which means you can route connections over Tor. Check out our blog post on using iroh with Tor for a walkthrough of how this works in practice.Will iroh support WebRTC, BLE, LoRa, or another transport?
Out of the box, iroh supports IPv4, IPv6 and relay transports. There’s such a large variety of potentially interesting transports out there that we can’t build them all in without turning the codebase into an unmaintainable maze of feature flags. Instead, iroh lets you implement custom transports that live in a completely separate crate. Existing experimental ones include Tor, Nym and Bluetooth (BLE). For a walkthrough of how custom transports work under the hood, see the custom transports blog post.Can iroh help route around internet segmentation or censorship?
iroh doesn’t solve every problem created by internet segmentation (DNS control, TLS certificate revocation, and so on), but it’s very much possible today to assemble iroh components into a setup that lets you forget about segmentation while you use it. iroh is designed from the ground up to build on existing internet technologies while avoiding lock-in and dependencies on browser vendors or other large players. For example, you can route iroh connections over custom transports like Tor or Nym, or connect over local links with Bluetooth or direct WiFi, giving application developers the building blocks to route around segmentation.How is iroh development funded?
The company behind iroh is number 0. It is partly venture capital and partly founder backed (as in: founders have invested their own money). Number 0 is healthy and has investors we actually think are a value-add. We earn revenue through Iroh Services, which provides managed relay and DNS address lookup infrastructure to keep your endpoints connected, from free public infrastructure for development and testing to dedicated cloud deployments for production. We rely on iroh remaining open source, and are committed to keeping it that way, including server-side code for relays and DNS address lookup.How does iroh compare to Tailscale?
Tailscale and iroh both get devices connected across NATs, but they operate at different layers. Tailscale is built to be global to your device: it sets up a network interface that all of your applications share. iroh is built to be embedded into each individual application. That difference matters. With iroh, connectivity lives inside your app rather than in a single global bridge, which gives developers and users a much more fine-grained and bespoke setup. You can ship an Android or iOS app that uses iroh direct connections under the hood, and the person using it never has to know or care that iroh is involved, with no separate VPN or daemon to install and manage. If you want one virtual network spanning all the apps on a machine, Tailscale is a natural fit. If you want direct, encrypted connections built directly into your application, iroh is designed for that.How does iroh compare to WebRTC?
Both iroh and WebRTC solve the same core problem (establishing direct P2P connections across NATs) but they make very different tradeoffs. WebRTC was designed for real-time media (audio and video) in browsers. It brings a complex stack: ICE for NAT traversal, STUN/TURN for relay, DTLS for encryption, SCTP for data channels, and a signaling layer that you have to implement yourself (WebRTC deliberately leaves signaling unspecified). This flexibility is powerful but adds significant complexity and is more expensive to run at scale. Iroh is built around QUIC (TLS 1.3) and focuses on reliable, encrypted data connections. The API is simpler: you connect to an endpoint ID and get a QUIC connection. Relays are stateless and cheap. Hole-punching works roughly 9 out of 10 times. There’s no signaling layer to design; address lookup mechanisms handle address resolution.- Browser support. Both WebRTC and iroh work in browsers. Get started with iroh in the browser. However, WebRTC remains the only choice for hole-punched connections due to the current state of Web APIs.
- Media streaming. WebRTC has first-class support for audio and video. Iroh is a general-purpose data transport, but you can run MoQ (Media over QUIC) on top of iroh for low-latency media streaming.
- Simplicity. Iroh’s connection model is significantly simpler to reason about and integrate. No SDP, no ICE candidate negotiation, no signaling server to build.
How does iroh compare to MQTT?
MQTT and iroh solve different problems, though they can overlap in IoT and device communication scenarios. MQTT is a publish/subscribe messaging protocol built around a central broker. Devices connect to the broker, publish messages to topics, and subscribe to topics they care about. It’s lightweight, well-suited to constrained hardware, and great for fan-out messaging (one message to many subscribers). The tradeoff is that the broker sits in the middle of all communication; it sees everything, and it’s a single point of failure and scaling pressure. Iroh is a P2P transport. There’s no broker; endpoints connect directly to each other, and all traffic is end-to-end encrypted. This means no central party can observe your data, and there’s no broker to scale or maintain. The main practical differences:- Pub/sub. MQTT has native topic-based pub/sub built in. Iroh doesn’t, though iroh-gossip provides gossip-based fan-out on top of iroh connections.
- Privacy. MQTT brokers require you to encrypt messages at the application level. Iroh connections are always end-to-end encrypted out of the box.
- Central infrastructure. MQTT requires a broker that all clients can reach. Iroh works across NATs without any central server, using relays only as a fallback.
- Constrained devices. MQTT was designed for low-power, low-bandwidth hardware. Iroh’s QUIC-based stack has higher resource requirements, but we do have solutions for constrained IoT environments. Get in touch if this is relevant to your use case.
How do iroh and libp2p compare?
Iroh is designed to be modular: you get a solid, reliable connection layer and compose protocols on top of it. Libp2p bundles more functionality (DHT, pubsub, transport negotiation) but those components are more tightly coupled, which makes the system harder to configure and reason about. The iroh project was founded by developers deeply involved with libp2p who wanted a library where you spend time on your protocol, not on networking configuration. Where iroh tends to win:- Peer discovery and NAT traversal. Iroh’s NAT traversal and address lookup story is significantly smoother. Getting peers to find each other reliably is one of the hardest parts of libp2p in practice; iroh has largely solved this.
- Direct messaging. Iroh gives you reliable, encrypted QUIC connections directly to specific peers. Straightforward to build routing or direct message delivery on top of.
- Gossip. iroh-gossip provides gossipsub-like fan-out on top of iroh connections.
- Blob transfer. Iroh has a built-in blob transfer protocol for exchanging hash-addressed data, similar to what you’d use IPFS for.
- DHT. Libp2p has a Kademlia-based DHT; iroh does not. If your design depends on DHT-based routing or content discovery, that’s a gap.
What languages can I use iroh from? Is there a Go version?
iroh’s focus is the Rust implementation, which is easy to use directly from Rust, C and C++ and to embed into languages like JavaScript, Python, Swift and Kotlin. See the Languages overview for the full list of official bindings. There’s no official Go version. Because iroh is a combination of existing standards (QUIC plus the multipath extension and a small amount of custom TLS logic), a native Go implementation is possible in theory using a Go QUIC library that supports multipath, and there are third-party efforts such as go-iroh. Our own focus stays on the Rust implementation.Do you support keys other than Ed25519?
No. Iroh endpoint IDs are Ed25519 keys, and that’s intentional. Ed25519 is deeply integrated across the stack: it’s used to signEndpointAddrs for Pkarr and other address lookups, as the raw public key trust root in mTLS, and for authentication in the relay protocol. Supporting pluggable key types would require threading that complexity through all of these systems simultaneously, with significant risk and little practical benefit for most use cases.
If you have a specific need around key types, open an issue and we’re happy to discuss it.