A QR code. Or a file that travels as light.

Through a simulated camera chain, at 10 frames per second, with the codes filling most of the image at 3-5 camera pixels per module, all four configurations came out with the hash verified: black-and-white on one lane 15.8 KB/s, black-and-white on four lanes 37.7 KB/s, colour on one lane 40.1 KB/s, colour on four lanes 115.7 KB/s. Colour on a single lane beats black-and-white on four. The miss rate was zero everywhere. Remember where the numbers come from: geometrically perfect frames, no lens and no motion. A real phone has not yet been put in front of them.

The camera is requested at 1920x1080 at 30 frames per second, with a preference for the rear one; if Android refuses the constraint, we fall back to any camera. Every captured frame is scaled down to 1280 px on its long side before decoding. What really counts is not resolution but how many sensor pixels land on one module: black-and-white needs roughly three, colour roughly twice that, because a phone's video chain usually delivers 4:2:0 and halves both colour planes in both directions. Fine colour detail is the first thing a real camera destroys.

Because the only thing the sending device can measure is how many symbols its own encoders produced against how many were asked of them — a statement about a processor, not about a camera a couple of hand-widths away. A laptop never misses a step, so a controller reading "zero misses" as "push on" climbs to the very top and puts four codes on screen changing thirty times a second, which nothing on earth can scan. That did ship once, and a person found it inside a minute. Automatic mode is now capped at one lane, black-and-white, version 26 and 15 frames per second. 15 is not a round number chosen for tidiness: a phone camera records at 30 and is not synchronised with the screen, so a frame has to stay up for two consecutive exposures — 67 ms — to be caught whole.

Nothing special, and that is the entire point. There are no sequence numbers to recover. The encoder produces repair packets at 2x the source symbols — measured on this code: at 60% frame loss, a set of roughly 2x K recovers 2 MB without the list ever being played a second time. The absolute ceiling is 60,000 packets; beyond that the sender simply replays the list more often, which costs time, not memory. If something does come out wrong, the SHA-256 catches it and the transfer fails openly instead of delivering a corrupt file.

No, and it is not an oversight. There is no return channel — a screen emits light, and light does not come back carrying receipts. Completion shows on the receiving device. Any interface claiming otherwise would be lying, and we already had a test that supplied exactly the proof the product can never have: the simulation computed its miss rate from what the simulated camera managed to resolve. That is a return channel. When a test and the shipped code disagree about what can be known, it is the test that is lying.

32 MB, refused at selection if it is larger. The limit does not come from the protocol but from the memory of a browser tab: RaptorQ materialises every packet at once, and a 50 MB file at a 2x ratio would mean 150 MB of live arrays, quite enough to kill a phone's tab. Encoding runs synchronously on the main thread, measured at 2.5 seconds for 32 MB on a computer. What actually travels is not the size of the file: the envelope is gzipped before RaptorQ, so a 1 MB spreadsheet is a few kilobytes of packets, while a 1 MB photograph is a megabyte of packets.

Neither. There is no account and no subscription. After the first visit the pages work with no network at all, because everything — the two WebAssembly binaries included — is served from our own domain. Worth saying what we learned along the way: a registered service worker does not mean offline support. On the first load the page and its assets are fetched before the worker takes control, so its handler never sees them. The page reports its own assets through the Performance API instead of assuming.