A QR code. Or a file passing through 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 verified hash: black and white on one band 15.8 KB/s, black and white on four bands 37.7 KB/s, colour on one band 40.1 KB/s, colour on four bands 115.7 KB/s. Colour on one band beats black and white on four. The miss rate was zero everywhere. Keep in mind where the figures come from: geometrically perfect frames, with no lens and no motion. A real phone has not yet been put in front of them.

The camera is required at 1920x1080 at 30 frames per second, with a preference for the rear one; if Android rejects the constraint, we fall back to any camera. Each captured frame is reduced to 1280 px on the long side before decoding. What really matters is not resolution, but how many sensor pixels fall on a module: black and white needs about three, colour about twice that, because the 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 versus how many were requested from it — a statement about a processor, not about a camera two handspans away. A laptop never misses a step, so a controller that reads “zero misses” as “carry on” climbs to the top and puts four codes on the screen that change thirty times a second, which nothing can scan. That was actually delivered once and a person found it in a minute. Now automatic mode is capped at one band, black and white, version 26 and 15 frames per second. 15 is not a round number: a phone camera records at 30 and is not synchronised with the screen, so one frame must stay displayed for two consecutive exposures — 67 ms — to be captured in full.

Nothing special, and that is the whole 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 about 2x K recovers 2 MB without the list ever being replayed a second time. The absolute ceiling is 60,000 packets; above that the sender simply restarts the list more often, which costs time, not memory. If something still goes wrong, the SHA-256 hash catches it and the transfer fails declared rather than delivering a corrupted file.

No, and that is not an omission. There is no return channel — a screen emits light, and light does not come back with confirmations. Completion is seen on the receiving device. Any interface claiming otherwise would be lying, and we already once had a test that offered exactly this proof that the product never has: the simulation calculated its miss rate from what the simulated camera managed to resolve. That is a return channel. When a test and the delivered code disagree on what can be known, the test is the one that is lying.

32 MB, rejected at selection if larger. The limit does not come from the protocol, but from a browser tab’s memory: RaptorQ materialises all packets at once, and a 50 MB file at 2x redundancy would mean 150 MB of live arrays, enough to kill a phone 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 file size: the envelope is compressed with gzip before RaptorQ, so a 1 MB table is a few kilobytes of packets, and a 1 MB photo is a megabyte of packets.

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