by UtubeMP3
Three ways to get bytes from one device to another without a server in the middle. The interesting part of each one is what it does when the channel is bad — because a channel with no server to retry against has to survive on its own.
There is no upload. That is not a privacy slogan bolted on afterwards, it is the design premise, and it removes the one thing normal file-sharing relies on: a reliable middleman that can store your bytes and hand them over later. Whatever channel Beam uses has to carry the file in one go, live, between two devices that may never have met.
How fast that can possibly go is set by physics, not by cleverness:
| Channel | Realistic ceiling | Why |
|---|---|---|
| Radio (Wi-Fi) | megabytes/second | Tens of MHz of bandwidth, purpose-built hardware on both ends. |
| Screen → camera | ~10–50 KB/s | Frame rate × how many bits survive a lens, at a distance, hand-held. |
| Speaker → microphone | ~1 KB/s | A few kHz of usable audio band, in a room full of echoes. |
So Wi-Fi is the one to use whenever it exists. The other two are not competing with it — they are what you use when there is no network to join at all.
Two browsers can open a direct encrypted connection to each other with WebRTC, but first they have to exchange a connection description. Normally a server relays that exchange. Beam does not have one, so the two phones exchange it optically: as a QR code on one screen, read by the other's camera.
The catch is size. A raw WebRTC description is roughly a kilobyte of boilerplate, which makes a QR code too dense to read across a table. Almost all of it is text both sides already know, so Beam strips it down to only the parts that are genuinely unique — the ICE username and password, the 32-byte DTLS certificate fingerprint, and up to six candidate addresses — and packs those into about 85 bytes. The receiver rebuilds a valid description from the pieces. That fits in a QR code big enough to scan casually, in one attempt.
After the scan the file streams over the data channel in 64 KB chunks with proper backpressure, each file carrying a CRC-32 the receiver checks and acknowledges. The connection is DTLS-encrypted, the same layer that protects browser video calls.
No STUN or TURN servers are configured, deliberately. Beam only ever uses addresses on your own network, so the traffic cannot leave it.
Sending a file as a sequence of QR codes sounds simple until you try it: the camera misses frames, hands shake, glare kills a code. If frame 47 is "the 47th chunk of the file", a single miss means the receiver has to ask for it again — and there is no back channel to ask on.
So Beam does not send chunks. It uses a rateless LT fountain code: every frame is a random combination of chunks, and the receiver can rebuild the whole file once it has collected enough frames — any frames, in any order. Dropping one costs nothing but a moment more filming. The sender simply keeps generating new combinations forever; the receiver stops it when it has what it needs.
Decoding uses the native BarcodeDetector where the browser has one, falling back
to a JavaScript decoder in a worker thread. The camera view centre-crops and adaptively zooms to
wherever the last code was found, which is what makes it usable hand-held rather than clamped.
The obvious library for data-over-audio tops out around 14 bytes per second. At that rate a 30 KB photo takes forty minutes, which is not a feature. Beam has its own modem instead, and it is the most involved part of the project.
The audio band is split into 199 separate carrier tones between 1.8 and 8 kHz, each carrying its own slow stream of data at the same time (this is OFDM, the same principle as Wi-Fi and digital radio). A room damages sound unevenly — a notch here, an echo there — and splitting the band this way means a bad patch of spectrum costs you a few carriers rather than the transmission.
The two phones, the room and the distance between them are different every time. So the adaptive mode first sends a probe, measures the quality of every carrier individually, and then assigns each carrier its own data rate — 4 bits per symbol on the clean ones, 2 or 1 on the marginal ones, and nothing at all on carriers the room has destroyed. A quarter of the carriers are given over to known pilot tones, which let the receiver track the constant phase drift between two devices whose clocks were never synchronised.
Everything is wrapped in Reed-Solomon error correction (the same family used on CDs and in QR codes themselves) with erasure decoding — meaning the receiver can tell the decoder "I don't trust these particular bytes", which is far more powerful than making it find the errors itself. Bytes are deliberately scattered across carriers and across separate code blocks, so a dead carrier or a door slamming damages a little of many codewords instead of destroying one.
If the receiver still ends up short, it says so: it sends back a list of exactly which frames it missed, and the sender repeats just those, dropping to a slower and tougher mode if the channel has clearly got worse. And if there is no back channel at all, the sender can export the whole transmission as a .wav file — which you can then send through a voice note, a phone call, or anything else that carries audio.
Beam started as a home-lab experiment in how much data you can push through channels that were never meant to carry it, and grew into something genuinely useful for the ordinary problem of getting a photo off one phone and onto another. It is published by UtubeMP3.