diff --git a/src/app/docs/tour/2-relays/page.mdx b/src/app/docs/tour/2-relays/page.mdx
index cb78c1de..81df0c56 100644
--- a/src/app/docs/tour/2-relays/page.mdx
+++ b/src/app/docs/tour/2-relays/page.mdx
@@ -6,9 +6,9 @@ A bunch of things happen in the background when an endpoint binds. The first thi
Relays are servers that help establish connections between devices. They’re the backbone of an iroh network. When your endpoint starts, it sends pings to all of the configured relays & measures how long the PONGs take to come back, also known as a measure of round trip latency. Relay servers are spread around the world, and the one with the lowest latency is usually the relay server you are physically closest to, but all we really care about is which one answers the fastest. Your endpoint will pick the relay with the lowest latency (the one that answered first) & use that as a *home relay.* With a home relay picked our endpoint opens a single WebSocket connection & work with the relay to figure out the details like our endpoint’s public IP address. At this point our endpoint is ready to dial & be dialed. This entire process happens in 0-3 seconds.
-Aside from being a public-facing home-base on the internet, relays have a second crucial role, which is to… relay. Meaning: when one node *doesn’t* have a direct connection to another node, it’ll use the relay to send data to that node. This means that even if we *can’t* establish a direct connection, data will still flow between the two devices. This is the part that let’s us say it’s “peer 2 peer that works”: sometimes peer-2-peer isn’t possible, so we have a seamless fallback baked in.
+Aside from being a public-facing home-base on the internet, relays have a second crucial role, which is to… relay. Meaning: when one endpoint *doesn’t* have a direct connection to another endpoint, it’ll use the relay to send data to that endpoint. This means that even if we *can’t* establish a direct connection, data will still flow between the two devices. This is the part that let’s us say it’s “peer 2 peer that works”: sometimes peer-2-peer isn’t possible, so we have a seamless fallback baked in.
-Keep in mind, connections are end-2-end encrypted, which means relays can’t read traffic, only pass along encrypted packets intended for the other side of the connection. Relays *do* know the list of node identifiers that are connected to it, and which nodes are connected to whom, but not what they are saying.
+Keep in mind, connections are end-2-end encrypted, which means relays can’t read traffic, only pass along encrypted packets intended for the other side of the connection. Relays *do* know the list of endpoint identifiers that are connected to it, and which endpoints are connected to whom, but not what they are saying.
Coming back to our program, let’s add support for relays:
@@ -20,7 +20,7 @@ async fn main() -> anyhow::Result<()> {
.relay_mode(iroh::RelayMode::Default);
let endpoint = builder.bind().await?;
- println!("node id: {:?}", endpoint.node_id());
+ println!("endpoint id: {:?}", endpoint.id());
Ok(())
}
diff --git a/src/app/docs/tour/3-discovery/page.mdx b/src/app/docs/tour/3-discovery/page.mdx
index 21dba69c..f255b99d 100644
--- a/src/app/docs/tour/3-discovery/page.mdx
+++ b/src/app/docs/tour/3-discovery/page.mdx
@@ -2,35 +2,31 @@ import { PageLink } from '@/components/PageNavigation';
# 3. Discovery
-Discovery is the glue that connects a [Node Identifier](/docs/concepts/endpoint#node-identifiers) to something we can dial. There are a few different types of discovery services, but for all of them you put a `NodeID` in, and get back either the home relay of that node, or IP addresses to dial.
+Discovery is the glue that connects a [Endpoint Identifier](/docs/concepts/endpoint#endpoint-identifiers) to something we can dial. There are a few different types of discovery services, but for all of them you put a `EndpointID` in, and get back either the home relay of that endpoint, or IP addresses to dial.
-There are different implementations of the discovery service in iroh, the most popular of which are DNS & Local Discovery. DNS uses the same domain name system that connects "example.com" to an IP address to map node ids to relay servers, and local discovery uses your local network to find nodes to talk to on local WiFi, even if that WiFi network doesn’t have a wider internet connection.
+There are different implementations of the discovery service in iroh, the most popular of which are DNS & Local Discovery. DNS uses the same domain name system that connects "example.com" to an IP address to map endpoint ids to relay servers, and local discovery uses your local network to find endpoints to talk to on local WiFi, even if that WiFi network doesn’t have a wider internet connection.
### DNS Discovery
-First, let's add the n0 DNS discovery service as a default:
+Iroh endpoints come with some defaults that include using our public infrastructure to enable discovery:
```rust
use iroh::{Endpoint, RelayMode};
#[tokio::main]
async fn main() -> anyhow::Result<()> {
- let builder = Endpoint::builder()
- .relay_mode(RelayMode::Default)
- .discovery_n0();
-
- let endpoint = builder.bind().await?;
+ let builder = Endpoint::.bind().await?;
- println!("node id: {:?}", endpoint.node_id());
+ println!("endpoint id: {:?}", endpoint.id());
Ok(())
}
```
-Now when this endpoint boots up, it will list itself on the n0 DNS service. From here we can pass along the node identifier, and other nodes can use the n0 DNS service to find the home relay of this node.
+Now when this endpoint boots up, it will list itself on the n0 DNS service. From here we can pass along the endpoint identifier, and other endpoints can use the n0 DNS service to find the home relay of this endpoint.
### Local Discovery
-Local discovery has the extra trick of being able to actually find new nodes on the local network. Before we can do that, we need to add the `discovery-local-network` feature to our `Cargo.toml` file:
+Local discovery has the extra trick of being able to actually find new endpoints on the local network. Before we can do that, we need to add the `discovery-local-network` feature to our `Cargo.toml` file:
```
cargo add iroh --features discovery-local-network
@@ -46,25 +42,24 @@ rand = "0.8.5"
tokio = "1.43.0"
```
-And with that we can set up local discovery:
+And with that we can set up local discovery, alongside our default discovery:
```rust
use iroh::{Endpoint, RelayMode, SecretKey};
#[tokio::main]
async fn main() -> anyhow::Result<()> {
+ let mdns = iroh::discovery::mdns::MdnsDiscovery::builder();
let builder = Endpoint::builder()
- .relay_mode(RelayMode::Default)
- .discovery_n0()
- .discovery_local_network();
+ .discovery(mdns);
let endpoint = builder.bind().await?;
- println!("node id: {:?}", endpoint.node_id());
+ println!("endpoint id: {:?}", endpoint.id());
Ok(())
}
```
-Here we’ve added discovery to the endpoint constructor, passing in our two discovery services, and that’s it, iroh will now use these two services to get something it can dial for a given node ID.
+Here we’ve added discovery to the endpoint constructor, passing in our two default and one custom discovery services, and that’s it, iroh will now use these three services to get something it can dial for a given endpoint ID.
For an example of this in action, check out the [local discovery example](https://github.com/n0-computer/iroh/blob/main/iroh/examples/locally-discovered-nodes.rs).
diff --git a/src/app/docs/tour/4-protocols/page.mdx b/src/app/docs/tour/4-protocols/page.mdx
index abc8fc95..3f072433 100644
--- a/src/app/docs/tour/4-protocols/page.mdx
+++ b/src/app/docs/tour/4-protocols/page.mdx
@@ -18,17 +18,19 @@ then adjust our code:
```rust
use iroh::{protocol::Router, Endpoint};
-use iroh_blobs::net_protocol::Blobs;
+use iroh_blobs::{store::mem::MemStore, BlobsProtocol};
#[tokio::main]
async fn main() -> anyhow::Result<()> {
- let endpoint = Endpoint::builder().discovery_n0().bind().await?;
+ let endpoint = Endpoint::bind().await?;
- let blobs = Blobs::memory().build(&endpoint);
+ let store = MemStore::new();
+
+ let blobs = BlobsProtocol::new(&store, None);
// build the router
let router = Router::builder(endpoint)
- .accept(iroh_blobs::ALPN, blobs.clone())
+ .accept(iroh_blobs::ALPN, blobs)
.spawn();
router.shutdown().await?;
@@ -41,7 +43,7 @@ async fn main() -> anyhow::Result<()> {
This code doesn't actually _do_ anything with the blobs protocol. For a real-world example, check out [sendme](https://github.com/n0-computer/sendme)
-This code sets up everything we need to both provide data we have locally when others request it, and ask other nodes that run the blobs protocol for data. Starting at the top, we first construct the endpoint, then we construct an instance of the blobs protocol, then add a _router_ (more on that in a minute) that listens for blobs protocol connections.
+This code sets up everything we need to both provide data we have locally when others request it, and ask other endpoints that run the blobs protocol for data. Starting at the top, we first construct the endpoint, then we construct an instance of the blobs protocol, then add a _router_ (more on that in a minute) that listens for blobs protocol connections.
diff --git a/src/app/docs/tour/5-routers/page.mdx b/src/app/docs/tour/5-routers/page.mdx
index 5fc5d017..b71ac453 100644
--- a/src/app/docs/tour/5-routers/page.mdx
+++ b/src/app/docs/tour/5-routers/page.mdx
@@ -19,7 +19,7 @@ use iroh_gossip::{net::Gossip, ALPN};
#[tokio::main]
async fn main() -> anyhow::Result<()> {
- let endpoint = Endpoint::builder().discovery_n0().bind().await?;
+ let endpoint = Endpoint::bind().await?;
let blobs = Blobs::memory().build(&endpoint);
diff --git a/src/app/docs/tour/6-conclusion/page.mdx b/src/app/docs/tour/6-conclusion/page.mdx
index 04a123a9..8ee592ff 100644
--- a/src/app/docs/tour/6-conclusion/page.mdx
+++ b/src/app/docs/tour/6-conclusion/page.mdx
@@ -4,14 +4,14 @@ import { PageLink } from '@/components/PageNavigation';
Before we go, let’s talk through a little of what iroh *doesn’t* cover:
-### Magically keep nodes online
-First, iroh doesn’t magically ensure the device you’re trying to dial is online. It doesn’t buffer messages & wait until you turn your phone back on. The technical term for this is “network churn”, and programming around the reality that nodes can come online & go offline whenever they want is the core concern of all distributed systems programming.
+### Magically keep endpoints online
+First, iroh doesn’t magically ensure the device you’re trying to dial is online. It doesn’t buffer messages & wait until you turn your phone back on. The technical term for this is “network churn”, and programming around the reality that endpoints can come online & go offline whenever they want is the core concern of all distributed systems programming.
### Obscure your IP address
-Second, iroh doesn’t obscure your IP address. nodes accepting connections will know your IP address. This is one of the biggest reason we think that iroh should be a library that users build into apps that have an in-built sense of trust. Keep in mind: sharing IP addresses is common practice in the wild, nearly all of major video conferencing tools do this. Video games do this. Heck, Spotify used to do this. And keep in mind, seeing your IP address is a thing traditional servers *always* have access to.
+Second, iroh doesn’t obscure your IP address. endpoints accepting connections will know your IP address. This is one of the biggest reason we think that iroh should be a library that users build into apps that have an in-built sense of trust. Keep in mind: sharing IP addresses is common practice in the wild, nearly all of major video conferencing tools do this. Video games do this. Heck, Spotify used to do this. And keep in mind, seeing your IP address is a thing traditional servers *always* have access to.
### Peer Signaling
-Lastly, iroh doesn’t yet come with a built-in peer signaling mechanism, that is, a way to get alice’s node id to bob. This seems like a massive oversight, but it’s on purpose: different apps have different opinions about how peers should learn about each other. In some cases it’s as simple as storing NodeIDs in an app database & passing them out as API responses. In other cases it’s local discovery only, or using tickets to encode dialing details + protocol invocations in a single string. We'll talk through patterns for peer signaling in future docs.
+Lastly, iroh doesn’t yet come with a built-in peer signaling mechanism, that is, a way to get alice’s endpoint id to bob. This seems like a massive oversight, but it’s on purpose: different apps have different opinions about how peers should learn about each other. In some cases it’s as simple as storing EndpointIDs in an app database & passing them out as API responses. In other cases it’s local discovery only, or using tickets to encode dialing details + protocol invocations in a single string. We'll talk through patterns for peer signaling in future docs.
## Conclusion
diff --git a/src/app/docs/tour/page.mdx b/src/app/docs/tour/page.mdx
index 4347581a..f54b429a 100644
--- a/src/app/docs/tour/page.mdx
+++ b/src/app/docs/tour/page.mdx
@@ -26,7 +26,7 @@ Hello, world!
Here's a high level overview of how everything fits together:
-Iroh is a library for establishing the most direct QUIC connection possible between two devices. Every _endpoint_ uses the public half of a cryptographic keypair to identify itself. Assuming at least one configured _relay server_ is reachable, an endpoint keeps exactly one TCP connection to a “home relay” that other nodes use for connection establishment, and as a fallback transport. Iroh uses a suite of _discovery services_ to resolve home relays & endpoint IDs. Connections between endpoints use QUIC ALPNs to distinguish between _protocols_, while _routers_ automate the endpoint accept loop for protocol multiplexing.{{ className: 'lead' }}
+Iroh is a library for establishing the most direct QUIC connection possible between two devices. Every _endpoint_ uses the public half of a cryptographic keypair to identify itself. Assuming at least one configured _relay server_ is reachable, an endpoint keeps exactly one TCP connection to a “home relay” that other endpoints use for connection establishment, and as a fallback transport. Iroh uses a suite of _discovery services_ to resolve home relays & endpoint IDs. Connections between endpoints use QUIC ALPNs to distinguish between _protocols_, while _routers_ automate the endpoint accept loop for protocol multiplexing.{{ className: 'lead' }}
This paragraph touches on five key points worth understanding in iroh:
diff --git a/src/app/page.jsx b/src/app/page.jsx
index 90f80acc..98bf9fdc 100644
--- a/src/app/page.jsx
+++ b/src/app/page.jsx
@@ -172,16 +172,16 @@ use iroh_ping::{ALPN as PingALPN, Ping};
#[tokio::main]
async fn main() -> Result<()> {
// create the receive side
- let recv_endpoint = Endpoint::builder().discovery_n0().bind().await?;
+ let recv_endpoint = Endpoint::bind().await?;
let recv_router = Router::builder(recv_endpoint)
.accept(PingALPN, Ping::new())
.spawn();
// get the receive side's address:
- let addr = recv_router.endpoint().node_addr().await?;
+ let addr = recv_router.endpoint().addr().await?;
// create the send side & send a ping!
- let send_ep = Endpoint::builder().discovery_n0().bind().await?;
+ let send_ep = Endpoint::bind().await?;
let send_pinger = Ping::new();
send_pinger.ping(&send_ep, addr).await?;
diff --git a/src/app/proto/protocols.js b/src/app/proto/protocols.js
index 04cbd2bb..6d693574 100644
--- a/src/app/proto/protocols.js
+++ b/src/app/proto/protocols.js
@@ -13,7 +13,7 @@ export const protocols = [
"featured": 2,
"icon": "iconPlatforms",
"title": "Gossip",
- "tagline": "Broadcast messages to groups of nodes by topic.",
+ "tagline": "Broadcast messages to groups of endpoints by topic.",
"slug": "iroh-gossip",
"repository": "https://github.com/n0-computer/iroh-gossip",
"documentation": "https://docs.rs/iroh-gossip/latest/iroh_gossip/",
@@ -60,7 +60,7 @@ export const protocols = [
{
"icon": "",
"title": "Iroh ping",
- "tagline": "A minimal protocol to ping iroh nodes.",
+ "tagline": "A minimal protocol to ping iroh endpoints.",
"slug": "iroh-ping",
"documentation": "https://docs.rs/iroh-ping/latest/iroh_ping/",
"repository": "https://github.com/n0-computer/iroh-ping",
diff --git a/src/app/roadmap/roadmap.json b/src/app/roadmap/roadmap.json
index 9304655a..2bedfa45 100644
--- a/src/app/roadmap/roadmap.json
+++ b/src/app/roadmap/roadmap.json
@@ -255,13 +255,13 @@
"doc": null
},
{
- "done": false,
+ "done": true,
"title": "Move `Tickets` into their own crate",
"description": "Tickets now exist in `iroh-ticket`",
"tracking_issue": null,
"doc": null
},
- { "version": "v0.94.0", "done": false, "released": "2025-10-20", "doc": "" },
+ { "version": "v0.94.0", "done": true, "released": "2025-10-20", "doc": "" },
{
"done": false,
"title": "Clean up errors",