Update FAQ

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 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?
@@ -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 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, 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?
@@ -56,6 +58,23 @@ 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?
+
+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<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](/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 +86,87 @@ 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 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?
+
+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 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.
+
+- **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.
+
+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 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.
+
+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?
@@ -100,4 +182,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.
+We fully believe the work on post-quantum-cryptography is good and important and follow developments closely.