From fb1b3bebfa90d482d05a138624e656901e1309c9 Mon Sep 17 00:00:00 2001 From: Rae McKelvey <633012+okdistribute@users.noreply.github.com> Date: Mon, 16 Mar 2026 11:25:36 -0700 Subject: [PATCH 1/8] Add faq based on https://github.com/n0-computer/iroh.computer/issues/213#issuecomment-4056030485 --- about/faq.mdx | 126 ++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 108 insertions(+), 18 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index 6ba00d8..d9205b3 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -4,11 +4,13 @@ title: "FAQ" ## Does iroh use relay servers? -Iroh uses relay servers to support establishing direct connections, to speed up initial connection times, and to provide a fallback should direct connections between two endpoints fail or be impossible otherwise. -By default iroh is configured with three relay servers run by number 0. -One in the US, one in Europe and one in Asia. -We can afford to run these servers for free, because [hole-punching](https://en.wikipedia.org/wiki/Hole_punching_(networking)) rates with iroh are really high. -Still, to prevent abuse, we rate-limit throughput through our public relays. +Yes — and relay servers are a core part of what makes iroh connections reliable. See the [Relays concept page](/concepts/relays) for a full overview. + +Relays serve two roles: they assist with [hole-punching](/concepts/holepunching) 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 three public relay servers run by number 0 — one 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](/concepts/relays#dedicated-relays) or [self-host your own](/concepts/relays#deploy-your-own-relay). ## Can relays read the traffic they route? @@ -34,11 +36,11 @@ Be aware of security caveats to forward secrecy when using the [opt-in 0-RTT fea ## What if number 0 stops running relay servers? -The relay servers we run in production [are open-source](https://github.com/n0-computer/iroh/tree/main/iroh-relay), and we highly encourage you to run your own! -You need a server with a public IP address and a DNS name that points to that IP address. -Automatic TLS setup via [ACME](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) is built into the iroh-relay code. -Use the configured DNS name to add your relay to the [`RelayMap`](https://docs.rs/iroh/latest/iroh/endpoint/struct.Builder.html#method.relay_mode) you configure your iroh endpoint with. -Running a custom relay server doesn't prevent you from connecting to others connected to other relay servers. +You're not dependent on us. The relay code is [open-source](https://github.com/n0-computer/iroh/tree/main/iroh-relay), and running your own is straightforward — for production use, we recommend it regardless. + +The easiest path is a [dedicated relay via Iroh Services](/concepts/relays#dedicated-relays), 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](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) is built in. Either way, configure the relay URL for your endpoint (see [Custom Relays](/connecting/custom-relays)) and you're set. + +Running your own relay doesn't affect interoperability — your endpoints can still connect to peers using other relay servers. ## Is establishing a connection without relays or when offline possible? @@ -56,6 +58,27 @@ If you do not disable the default discovery services or other discovery services 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 `Discovery` service, you gain control over the relay URLs iroh can discover. +## How can I monitor endpoint connection status to update a UI? + +"Online" and "offline" are more nuanced in iroh than they might seem. An endpoint can be unreachable from the wider internet but still fully able to connect to peers on the same LAN — so a simple online/offline indicator can be misleading to users. + +It's often more useful to show which specific peers the endpoint is currently connected to, rather than a general connectivity state. For example: "syncing with 2 devices" is more meaningful than "online". + +That said, if you want a proxy for general internet connectivity, you can watch whether the endpoint currently has a relay connection: + +```rust +endpoint.watch_addr() + .map(|addr| addr.relay_urls().next().is_some()) +``` + +This returns an `impl Watchable` 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](/connecting/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 "Discovery" in iroh and which one should I enable? For most usage, using the services that are enabled by default in the `iroh::Endpoint::builder` is the best default. @@ -67,24 +90,91 @@ It's also possible to combine multiple discovery mechanisms at once, or write yo We think it's particularly helpful to write application-specific discovery mechanisms that are tailored to an application's need. +## What ports does iroh use? + +Iroh uses at least three ports: + +- **TCP 443** — relay connection (HTTP/1.1 over TLS) +- **Two UDP ports** — one for IPv4 and one for IPv6, used for direct P2P connections; configurable via [`endpoint::Builder`](https://docs.rs/iroh/latest/iroh/endpoint/struct.Builder.html) + +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. + + +## 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](https://www.iroh.computer/blog/tor-custom-transport) for a walkthrough of how this works in practice. + + ## 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 from customers today through https://n0.computer/n0ps, and are re-launching an “AWS for iroh protocols” in 2025. -While it will be a service you can pay for, it won’t have special treatment beyond being convenient. +We earn revenue through [Iroh Services](https://services.iroh.computer), which provides managed relay and DNS discovery 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 discovery. +## 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 TURN relay servers are stateful and 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 — discovery mechanisms handle address resolution. + +The main practical differences: + +- **Browser support.** WebRTC is native to browsers; iroh is not. If you need in-browser P2P, WebRTC is the default choice. +- **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)](https://www.iroh.computer/blog/secure-video-everywhere) 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. +- **Relay cost.** Iroh's stateless relays are much cheaper to operate than WebRTC TURN servers. + +If you're building a native app, iroh will generally be easier to work with and perform better. If you need browser support, WebRTC remains the default choice — iroh doesn't run in the browser. + + +## 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](https://github.com/n0-computer/iroh-gossip) provides gossip-based fan-out on top of iroh connections. +- **Privacy.** MQTT brokers can read all messages unless you add application-level encryption. Iroh connections are always end-to-end encrypted. +- **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](https://iroh.computer/contact) if this is relevant to your use case. + +If you need fan-out messaging to many subscribers, MQTT is a proven fit. If you need direct, private, encrypted connections between devices — especially across NATs — iroh is the stronger choice. + + ## How do iroh and libp2p compare? -Generally, we've put a lot of effort into making "connections that *just work*". -This means we've kept the scope small: There's no DHT, swarm, or gossipsub. -Instead, what you get are reliable direct [QUIC](https://en.wikipedia.org/wiki/QUIC) connections between iroh endpoints. -On top of these, some of said libp2p features can be implemented as *protocols* on top, see for example [iroh-gossip](https://github.com/n0-computer/iroh-gossip/) which provides gossipsub-like functionality. -While there are some features in libp2p like a DHT implementation based on kademlia that don't exist in the iroh ecosystem yet, we believe the features iroh *does* have work better. -The iroh project was founded by developers who were deeply involved with libp2p, and wanted to build a more focused library with less configuration that would be easier to deploy and use with high reliability. +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 hole-punching.** Iroh's [hole-punching](/concepts/holepunching) and discovery 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](https://github.com/n0-computer/iroh-gossip/) provides gossipsub-like fan-out on top of iroh connections. +- **Blob transfer.** Iroh has a built-in [blob transfer protocol](https://docs.rs/iroh-blobs) for exchanging hash-addressed data, similar to what you'd use IPFS for. + +Where libp2p has more: + +- **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. + +If your focus is on the protocol you're building rather than the networking layer beneath it, iroh is designed to get out of your way. + + +## 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 sign `EndpointAddr`s 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](https://github.com/n0-computer/iroh/issues) and we're happy to discuss it. ## Is iroh post-quantum-secure? From 6bb7a70c8f6c2a2c14b31495ed3249080280521c Mon Sep 17 00:00:00 2001 From: rae <633012+okdistribute@users.noreply.github.com> Date: Mon, 16 Mar 2026 11:34:57 -0700 Subject: [PATCH 2/8] Update faq.mdx --- about/faq.mdx | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index d9205b3..b514011 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -60,11 +60,7 @@ By changing iroh's relay mode or relay map you can control the home relay the en ## How can I monitor endpoint connection status to update a UI? -"Online" and "offline" are more nuanced in iroh than they might seem. An endpoint can be unreachable from the wider internet but still fully able to connect to peers on the same LAN — so a simple online/offline indicator can be misleading to users. - -It's often more useful to show which specific peers the endpoint is currently connected to, rather than a general connectivity state. For example: "syncing with 2 devices" is more meaningful than "online". - -That said, if you want a proxy for general internet connectivity, you can watch whether the endpoint currently has a relay connection: +If you want a proxy for general internet connectivity, you can watch whether the endpoint currently has a relay connection: ```rust endpoint.watch_addr() @@ -190,4 +186,4 @@ It also means DNS packets used for DNS discovery at the moment might get fragmen It would also mean Endpoint IDs would be exactly 37x as big. To support post-quantum-cryptography, we would need to trade off usability with the risk should a sufficiently powerful quantum computers would become real. We believe it is much more important to serve existing use cases efficiently, so they have encryption *today*. -We fully believe the work on post-quantum-cryptography is good and important and follow developments closely. \ No newline at end of file +We fully believe the work on post-quantum-cryptography is good and important and follow developments closely. From 07920933d733af1b4b7312ff5845a63daff7d1c5 Mon Sep 17 00:00:00 2001 From: rae <633012+okdistribute@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:12:20 -0700 Subject: [PATCH 3/8] Update about/faq.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Philipp Krüger --- about/faq.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/about/faq.mdx b/about/faq.mdx index b514011..7e7552f 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -10,7 +10,7 @@ Relays serve two roles: they assist with [hole-punching](/concepts/holepunching) 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 three public relay servers run by number 0 — one 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](/concepts/relays#dedicated-relays) or [self-host your own](/concepts/relays#deploy-your-own-relay). +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](/concepts/relays#dedicated-relays) or [self-host your own](/concepts/relays#deploy-your-own-relay). ## Can relays read the traffic they route? From 5a2256721b789b1fc7dd9f96e2f8656572c412d1 Mon Sep 17 00:00:00 2001 From: Rae McKelvey <633012+okdistribute@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:18:55 -0700 Subject: [PATCH 4/8] phillip comments --- about/faq.mdx | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index 7e7552f..2f09ea5 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -114,7 +114,7 @@ We rely on iroh remaining open source, and are committed to keeping it that way, 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 TURN relay servers are stateful and expensive to run at scale. +**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 — discovery mechanisms handle address resolution. @@ -123,7 +123,6 @@ The main practical differences: - **Browser support.** WebRTC is native to browsers; iroh is not. If you need in-browser P2P, WebRTC is the default choice. - **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)](https://www.iroh.computer/blog/secure-video-everywhere) 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. -- **Relay cost.** Iroh's stateless relays are much cheaper to operate than WebRTC TURN servers. If you're building a native app, iroh will generally be easier to work with and perform better. If you need browser support, WebRTC remains the default choice — iroh doesn't run in the browser. @@ -139,7 +138,7 @@ MQTT and iroh solve different problems, though they can overlap in IoT and devic The main practical differences: - **Pub/sub.** MQTT has native topic-based pub/sub built in. Iroh doesn't, though [iroh-gossip](https://github.com/n0-computer/iroh-gossip) provides gossip-based fan-out on top of iroh connections. -- **Privacy.** MQTT brokers can read all messages unless you add application-level encryption. Iroh connections are always end-to-end encrypted. +- **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](https://iroh.computer/contact) if this is relevant to your use case. From ac6621296753d6941b6b5146700e1056d90f9093 Mon Sep 17 00:00:00 2001 From: Rae McKelvey <633012+okdistribute@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:21:22 -0700 Subject: [PATCH 5/8] add phillip comments --- about/faq.mdx | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index 2f09ea5..3aa510e 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -88,13 +88,12 @@ We think it's particularly helpful to write application-specific discovery mecha ## What ports does iroh use? -Iroh uses at least three ports: - -- **TCP 443** — relay connection (HTTP/1.1 over TLS) -- **Two UDP ports** — one for IPv4 and one for IPv6, used for direct P2P connections; configurable via [`endpoint::Builder`](https://docs.rs/iroh/latest/iroh/endpoint/struct.Builder.html) +Iroh listens on **Two UDP ports** — one for IPv4 and one for IPv6, used for direct P2P connections; configurable via [`endpoint::Builder`](https://docs.rs/iroh/latest/iroh/endpoint/struct.Builder.html) 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? From 165aa812de8330299a526fe65d7e2b6d8f923550 Mon Sep 17 00:00:00 2001 From: Rae McKelvey <633012+okdistribute@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:24:28 -0700 Subject: [PATCH 6/8] clarify & link to webrtc browser support --- about/faq.mdx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index 3aa510e..892cc7a 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -117,9 +117,7 @@ Both iroh and WebRTC solve the same core problem — establishing direct P2P con **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 — discovery mechanisms handle address resolution. -The main practical differences: - -- **Browser support.** WebRTC is native to browsers; iroh is not. If you need in-browser P2P, WebRTC is the default choice. +- **Browser support.** Both WebRTC and iroh work in browsers. [Get started with iroh in the browser](https://docs.iroh.computer/deployment/other-languages#webassembly-and-browsers). Howevr, 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)](https://www.iroh.computer/blog/secure-video-everywhere) 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. From da64e012a611fcf538ea93d57d59ca18e426f1cf Mon Sep 17 00:00:00 2001 From: Rae McKelvey <633012+okdistribute@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:25:00 -0700 Subject: [PATCH 7/8] typo --- about/faq.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/about/faq.mdx b/about/faq.mdx index 892cc7a..3d61017 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -117,7 +117,7 @@ Both iroh and WebRTC solve the same core problem — establishing direct P2P con **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 — discovery mechanisms handle address resolution. -- **Browser support.** Both WebRTC and iroh work in browsers. [Get started with iroh in the browser](https://docs.iroh.computer/deployment/other-languages#webassembly-and-browsers). Howevr, WebRTC remains the only choice for hole-punched connections due to the current state of Web APIs. +- **Browser support.** Both WebRTC and iroh work in browsers. [Get started with iroh in the browser](https://docs.iroh.computer/deployment/other-languages#webassembly-and-browsers). 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)](https://www.iroh.computer/blog/secure-video-everywhere) 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. From 94af55b6e080532a41f1fde134634d37682e960a Mon Sep 17 00:00:00 2001 From: Rae McKelvey <633012+okdistribute@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:26:15 -0700 Subject: [PATCH 8/8] update relay text --- about/faq.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index 3d61017..a15f4b7 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -36,11 +36,11 @@ Be aware of security caveats to forward secrecy when using the [opt-in 0-RTT fea ## What if number 0 stops running relay servers? -You're not dependent on us. The relay code is [open-source](https://github.com/n0-computer/iroh/tree/main/iroh-relay), and running your own is straightforward — for production use, we recommend it regardless. +You're not dependent on us. The relay code is [open-source](https://github.com/n0-computer/iroh/tree/main/iroh-relay), and running your own is possible. The easiest path is a [dedicated relay via Iroh Services](/concepts/relays#dedicated-relays), 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](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) is built in. Either way, configure the relay URL for your endpoint (see [Custom Relays](/connecting/custom-relays)) and you're set. -Running your own relay doesn't affect interoperability — your endpoints can still connect to peers using other relay servers. +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. ## Is establishing a connection without relays or when offline possible?