A machine’s name is a key,
not an address.
Most file transfer tools work the way you’d guess: you upload to a company’s servers, they hand you a link, your friend downloads it back out. DashBeam doesn’t do any of that – and the interesting part isn’t the claim. It’s what has to be true underneath for the claim to hold.
Drag in 4 GB, get a short string
Drop a folder into DashBeam. There’s no upload bar. A few seconds later there’s a string of text you can send to somebody. Nothing was uploaded, because there’s nowhere to upload it to.
What DashBeam did instead was read the folder and compute a fingerprint of its contents. Not a fingerprint of the whole thing at once – it split the data into chunks, fingerprinted each chunk, then fingerprinted those fingerprints in pairs, and again, and again, until everything collapsed into a single 32-byte value at the top. Change one byte anywhere in that folder and the value at the top changes.
Your file never moved. It’s still sitting where you left it, and your machine is what will serve it. The string you’re holding isn’t a copy of your file. It’s an address for it – and it happens to be an address that can only ever refer to exactly those bytes and no others.
DashBeam never moves your file somewhere and then moves it again. There is one transfer, and it hasn’t started yet.
Chunk 4 changed. Only 4 hashes on the path to the root are recomputed – the other 11 nodes are untouched, and the 32-byte value at the top is now a different address entirely.
Notice how little of the tree has to change.
Someone on another continent pastes it, and it starts
They don’t have an account. Neither do you. Neither of you told anyone your IP address. They paste the string, and bytes start moving.
The string carries three things: who to talk to, where to start looking, and what to ask for. The third one is the fingerprint from section 1. The first one is where it gets interesting.
Your machine has a name on the network. That name isn’t an address – it’s a public key. When DashBeam first ran, it generated a keypair and kept the secret half on your device. The public half, written out, is 52 characters. That’s the name.
This looks like an odd choice until you notice what comes free with it. Anyone who knows your machine’s name can encrypt something that only your machine can open. Anyone who knows your machine’s name can verify a signature that only your machine could have produced. Naming, encryption, and authentication stop being three problems and become one. There’s no separate step where you check you’re talking to the right person, because addressing them at all requires their key.
That still leaves a practical question: a key isn’t somewhere you can send packets. Turning a name into a location is a lookup. Your device publishes a small record – the key you’re looking for can currently be reached at this relay, and possibly at these addresses directly – and signs it with the same secret key the name is derived from. Your friend’s device fetches that record and checks the signature against the name it already has. A tampered record fails that check, which means the lookup service doesn’t have to be trusted, only available.
The lookup service can lie. It just can’t lie successfully.
This is a lookup, not a directory. You can resolve a name you already have. You cannot browse for one, because there is no list to browse. If someone doesn’t know your key, your record may as well not exist.
It moves at a speed web tools don’t
Two reasons, and the second one is the one worth reading.
The first is that there’s no detour. Bytes go from your disk to their disk. Upload-then-download means every byte crosses the internet twice, and the whole thing runs at the speed of the slower of two links that have nothing to do with each other.
The second reason is that the direct connection exists at all – which, if you think about home networks for a second, it shouldn’t. Both machines are almost certainly behind a router doing address translation. Such a router only forwards inbound packets that belong to a conversation it already watched begin. From the outside, neither machine has a reachable address at all. Neither one can be dialled by the other.
They connect directly about nine times in ten anyway.
The trick is that the router doesn’t ask anyone’s permission – it just keeps a table. When your laptop sends a packet out to some address, the router writes down if something comes back from there, it’s for the laptop. So if both machines send a packet toward each other at roughly the same moment, each router independently opens a hole for a reply it now expects. Neither router believes it accepted an inbound connection. Both of them did.
What needs coordinating is the roughly the same momentpart, and which addresses to aim at. That’s what a relay is for. And notice the ordering, because it’s the part people assume wrong.
Two machines, each behind a router doing address translation. From the outside neither has a reachable address. Neither can dial the other.
Set both routers strict and watch the direct connection fail – then watch the transfer carry on anyway.
The relay is already carrying your data while this negotiation happens. Nothing is waiting on the direct connection to succeed. When it does succeed, traffic moves over and the relay steps back.
Someone on your Wi-Fi appears, with no code typed
Another DashBeam device on the same network shows up under Nearby. You pick it and send. Nobody typed a pairing code, and nothing went out to the internet to make that happen.
When a machine is on the same network segment, all of section 2’s lookup machinery is unnecessary work – the network itself can answer. DashBeam advertises and browses using multicast DNS, the same mechanism that makes printers and speakers show up without configuration.
Being precise about where this comes from is worth more than making it sound effortless: iroh ships local discovery switched off by default. DashBeam turns it on, and wraps it in a policy, because “everyone on this coffee shop Wi-Fi can see my laptop’s name” is a decision that belongs to you rather than to us.
The first time two devices meet this way, both show a short verification code derived from both public keys. Same code on both screens means you’re talking to the machine that’s actually in front of you.
Discoverable by name on the local network.
Discoverable by name on the local network.
Try “Paired only” on one side and notice what still gets through.
The local path replaces the lookup, not the transfer. Everything after this point – the encryption, the verification, the resumption – is identical either way.
You walk out the door mid-transfer, and it keeps going
The transfer is running. Your phone drops off Wi-Fi and picks up cellular. The progress bar doesn’t stop.
This is where the strange decision back in section 2 pays for itself completely. The connection was never attached to an IP address. It’s attached to a key. The addresses were only ever a hint about where to find that key – and hints are cheap to replace. So when the network underneath changes:
- A monitor notices the network interfaces and routing table are different.
- Probes go out to relays to learn the new public addresses and how far away they are.
- A small message crosses the relay to the other device: here’s where I am now.
- The other device updates its address book. Same key, new addresses.
- The new path validates, and traffic moves onto it.
And the reason the progress bar keeps moving through all of that, in iroh’s own words:
“While this hole-punching dance progresses, we are still able to send data back and forth over the relay connection, so data never stops flowing.”
A transfer is running over the phone’s home Wi-Fi. A relay connection is open alongside it, as it always is.
Try to break it. Notice what doesn’t happen.
A machine’s name is a key, not an address. The key does the encryption. So the address is disposable – and everything else here is a consequence of that.
Your laptop sleeps, and it picks up where it stopped
Close the lid, lose the network, quit the app. When you come back, the transfer resumes from where it stopped. It doesn’t start over.
Go back to the tree in section 1. Because the folder was fingerprinted as a tree rather than as one lump, any individual chunk can be checked on its own against that same root value. The receiver doesn’t need the whole file to know whether the part it has is right. That buys two things at once.
Verified streaming.A corrupted or tampered chunk is caught at that chunk – not at the end of a 400 GB download. Data is checked as it lands, continuously, against a fingerprint that was fixed before the transfer started.
Resumption. The receiver knows exactly which chunks it already holds and trusts. When the connection comes back, it asks for the rest. Nothing that already arrived is re-sent, and nothing that already arrived has to be taken on faith.
Folders and very large files use the same idea one level up: a blob whose contents are the fingerprints of other blobs.
A transfer in progress. Each chunk is checked against the root as it lands – not at the end.
Corruption localizes to one leaf. A resume asks only for what’s missing.
For what it’s worth against the comparison table: LocalSend and PairDrop don’t resume.
Nobody ever asked you to sign in
No account. No sign-up. No “your files” page, no dashboard, no history of what you’ve sent – not hidden somewhere, just absent.
That’s not restraint on our part. There’s nothing for an account to point at. The string from section 2 is the coordination protocol, in full. No server holds a record of the transfer because no server was involved in arranging it.
Section 3 admitted that a relay can end up in the path, so here’s the ledger written out rather than implied.
| A relay operator can see | that one key exchanged traffic with another key, roughly when, and roughly how much |
| A relay operator cannot see | what was sent – not the contents, not the filenames, not the folder structure. Traffic is encrypted end to end whether the path is direct or relayed |
| Your ISP sees | encrypted UDP going to a relay, or encrypted UDP going to a peer |
| The lookup service learns | that somebody asked for a particular key’s record |
| DashBeam, the project, sees | nothing. There is no server of ours anywhere in this drawing |
Filenames and contents are absent from the right-hand panel because they were never in the traffic.
If that ledger still isn’t good enough for you – and for some people it shouldn’t be – the relay and the lookup service are both self-hostable, and the instructions are in the repository. Point DashBeam at your own and the last third party leaves the diagram.
You paired your phone once, and now it’s one button
Your own devices are listed. Sending to one is a click. There’s no string to copy. Pairing doesn’t replace the string – it delivers it for you.
Two devices exchange a short code, and then each one proves it actually holds the secret behind its public name by signing material bound to that specific connection. A signature copied from somewhere else won’t do; it has to be produced live, for this connection. Once that’s done, each device remembers the other locally, and a long-lived connection between them carries presence – which is how you can see that a device is online before you send to it.
When you do send, DashBeam still mints an ordinary one-time ticket, exactly like section 1. It just delivers it as an in-app invite instead of asking you to copy and paste. Accepting a Nearby request from section 4 produces the same stored record – same destination, different way of meeting.
Manual tickets and the sendme CLI keep working exactly as they did.
The whole thing in one paragraph
A machine’s name is a key. The key does the encryption. So the address is disposable – and once the address is disposable, everything else follows. You can change networks in the middle of a transfer, because the connection was never about the address. You can attempt a direct connection without having to trust the result, because failure just means the relay stays. A relay can carry your traffic without being able to read it, because the name it’s routing to is the same key the traffic is encrypted for. And nobody needs an account, because there’s nothing an account could point at.
DashBeam is built on iroh. If you’d rather read source than prose, the protocol lives in engine/protocol. This page is available in English only.