You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update quickstart
* Simplify code in `concepts/discovery/page.mdx`
* Fix `router/page.mdx`
* Remove ticket section that's outdated
* Fix numbering in the tour
* Fix the tour styling
* Update tour to latest protocol & iroh versions
Copy file name to clipboardExpand all lines: src/app/docs/concepts/tickets/page.mdx
-10Lines changed: 0 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,16 +40,6 @@ It's worth point out this setup is considerably better than full peer-2-peer sys
40
40
41
41
When you create a document ticket, you're creating a secret that allows someone to read or write to a document. This means that you should be careful about sharing document tickets with people you don't trust. What's more, someone who has a document ticket can use it to create new tickets for the same document. This means that if you share a document ticket with someone, they can use it to create new tickets for the same document, and share those tickets with others.
by default, tickets only include the nodeID If you still want to add relay and direct addresses to the ticket, you can pass `--addr-options RelayAndAddresses` to the ticket generation commands.
52
-
53
43
## Tickets in Apps
54
44
Using tickets in your app comes down to what you're trying to accomplish. For short-lived sessions where both devices are online at the same time, tickets are an incredibly powerful way to bootstrap connections, and require no additinonal servers for coordination.
I've also taken the liberty to make sure that we're gracefully shutting down the `Router` and all its protocols with it, as well as the `LocalPool`that the iroh-blobs library needs to operate.
139
+
I've also taken the liberty to make sure that we're gracefully shutting down the `Router` and all its protocols with it, in this case that's only iroh-blobs.
143
140
144
141
145
142
## Doing something
146
143
147
144
So far, this code works, but doesn't actually do anything besides spinning up a node and immediately shutting down.
148
-
Even if we put in a `tokio::time::timeout` or `tokio::signal::ctrl_c().await` in there, it *would* actually respond to network requests for the blobs protocol, but even that is practically useless as we've stored no blobs to respond with.
145
+
If we put in a `tokio::time::timeout` or `tokio::signal::ctrl_c().await` in there, although it *would* actually respond to network requests for the blobs protocol, these responses are practically useless as we've stored no blobs to respond with.
149
146
150
147
Here's our plan for turning this into a CLI that actually does what we set out to build:
151
148
1. We'll grab a [`Blobs::client`](https://docs.rs/iroh-blobs/latest/iroh_blobs/net_protocol/struct.Blobs.html#method.client) to interact with the iroh-blobs node we're running locally.
@@ -162,18 +159,23 @@ Here's our plan for turning this into a CLI that actually does what we set out t
162
159
Phew okay! Here's how we'll grab an iroh-blobs client and look at the CLI arguments:
163
160
164
161
```rust
165
-
letblobs=blobs.client();
162
+
// We use a blobs client to interact with the blobs protocol we're running locally:
println!("Couldn't parse command line arguments.");
178
+
println!("Couldn't parse command line arguments: {args:?}");
177
179
println!("Usage:");
178
180
println!(" # to send:");
179
181
println!(" cargo run --example transfer -- send [FILE]");
@@ -189,23 +191,26 @@ Now all we need to do is fill in the `todo!()`s one-by-one:
189
191
190
192
### Getting ready to send
191
193
192
-
If we want to make a file available over the network with iroh-blobs, we first need to index this file.
194
+
If we want to make a file available over the network with iroh-blobs, we first need to hash this file.
193
195
194
196
<Note>
195
197
What does this step do?
196
198
197
-
It hashes the file using BLAKE3 and stores a so-called "outboard" for that file.
198
-
This outboard file contains information about hashes for parts of this file.
199
+
It hashes the file using [BLAKE3](https://en.wikipedia.org/wiki/BLAKE_(hash_function)) and stores a so-called ["outboard"](https://github.com/oconnor663/bao?tab=readme-ov-file#outboard-mode) for that file.
200
+
This outboard file contains information about hashes of parts of this file.
199
201
All of this enables some extra features with iroh-blobs like automatically verifying the integrity of the file *during* streaming, verified range downloads and download resumption.
This first download the file completely into memory, then copy that memory into a file in two steps.
279
+
This first downloads the file completely into memory, then copies it from memory to file in a second step.
267
280
268
-
There's ways to make this work without having to store the whole file in memory, but that involves setting up `Blobs::persistent` instead of `Blobs::memory` and using `blobs.export` with `EntryMode::TryReference`.
281
+
There's ways to make this work without having to store the whole file in memory, but those involve setting up `Blobs::persistent` instead of `Blobs::memory` and using `blobs.export` with `EntryMode::TryReference`.
269
282
We'll leave these changes as an exercise to the reader 😉
270
283
</Note>
271
284
@@ -281,5 +294,3 @@ If you're hungry for more, check out
281
294
-[other examples](/docs/examples),
282
295
- other available [protocols](/proto) or
283
296
- a longer guide on [how to write your own protocol](/docs/protocols/writing).
284
-
285
-
If rust is not actually your jam, make sure to check out the [language bindings](/docs/sdks)!
The journey of a connection starts with an endpoint. An endpoint is one of the two termination points for a connection. It’s one of the tin cans that the wire is connected to. Because this is peer-2-peer, endpoints both _initiate_*and*_accept_ connections. The endpoint handles both.
6
6
@@ -9,10 +9,10 @@ Let's first add iroh to our project. From the project root run `cargo add iroh`
9
9
```bash
10
10
$ cargo add iroh
11
11
Updating crates.io index
12
-
Adding iroh v0.31.0 to dependencies
12
+
Adding iroh v0.32.1 to dependencies
13
13
Features:
14
-
+ discovery-pkarr-dht
15
14
+ metrics
15
+
- discovery-pkarr-dht
16
16
- discovery-local-network
17
17
- examples
18
18
- test-utils
@@ -31,7 +31,7 @@ In the end your `Cargo.toml` file's `[dependencies]` section should look somethi
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.
6
6
@@ -41,27 +41,22 @@ This will change our `Cargo.toml` file `[dependencies]` section to look like thi
41
41
```toml
42
42
[dependencies]
43
43
anyhow = "1.0.95"
44
-
iroh = { version = "0.31.0", features = ["discovery-local-network"] }
44
+
iroh = { version = "0.32.1", features = ["discovery-local-network"] }
45
45
rand = "0.8.5"
46
46
tokio = "1.43.0"
47
47
```
48
48
49
-
And with that we can set up local discovery. It does add some complexity to the endpoint setup:
0 commit comments