Airgapped File Transfer via Flashing QR Codes: How Decimen Works

u/Alstroph posted a 15-second demo to r/ClaudeAI on July 30, 2026: a phone streaming a file out of thin air by reading flashing QR codes off a laptop screen. 2.8K upvotes, 221 comments, front page of the subreddit within hours — followed almost immediately by the internet's favorite response to a clever demo: "this already exists."

Both reactions are correct, and neither is the interesting part. The interesting part is fountain codes — a genuinely elegant piece of engineering solving a real problem — and a comment thread that turned into one of 2026's clearest case studies on what changes, and what doesn't, when AI coding tools make building things nearly free.

TL;DR

How it actually works

The setup has zero network requirement by design: one device (ideally a laptop, for max screen brightness) opens a sender page and starts streaming immediately. A second device (a phone) opens a receiver page, requests camera access, and starts decoding. No pairing, no app install, no permission beyond the camera.

Under the hood:

1. Sender: encodes the file as a continuous stream of animated QR codes, each carrying a self-describing 20-byte header (session ID, sequence number, block count/size, file length, hash) — no handshake required.
2. Receiver: decodes frames from the camera feed using zxing-cpp compiled to WebAssembly, run in web workers fed by requestVideoFrameCallback. That WASM dependency exists because Safari has never shipped the native BarcodeDetector API (WebKit bug 281848) — a browser-compatibility gap the project has to route around entirely client-side.
3. Reconstruction: once the receiver has collected enough distinct frames, it solves the fountain-code peeling process and the file resolves — verified against the transmitted hash.

The whole thing runs as a Vite dev server over HTTPS (a self-signed cert, since getUserMedia — the camera API — is stripped entirely from insecure origins by every modern browser). Point a phone at the printed LAN URL, accept the certificate warning, and the transfer starts.

The real engineering: why fountain codes, not just "loop the QR code"

A naive version of this idea is easy to imagine and easy to build badly: cycle through QR codes representing sequential file chunks, and hope the receiver catches all of them. It will not. Camera autofocus hunting, motion blur, and refresh-rate mismatches guarantee dropped frames — and a sequential scheme means a single miss stalls the whole transfer until the cycle comes back around.

Fountain codes (specifically Luby Transform, or LT, coding) solve this cleanly. Instead of transmitting file blocks directly, each frame carries the XOR of a pseudorandom subset of blocks, with subset sizes drawn from a robust-soliton distribution — the same mathematical device used in erasure-coded storage and broadcast data distribution. The subset for any given frame is derived deterministically from that frame's sequence number, so sender and receiver never need to coordinate beyond agreeing on the algorithm.

The payoff: the receiver just needs to collect roughly K × 1.15 distinct frames — where K is the number of file blocks — in any order, from any point in the stream, and it can algebraically peel the original blocks back out. A dropped frame costs the receiver a little time waiting for another useful one to come around. It never breaks correctness, and the sender and receiver frame rates don't even need to match.

This is precisely the class of problem fountain codes were designed for: one-way channels with no feedback path, where retransmission requests are impossible. Broadcast satellite data, some multicast file distribution systems, and — as it turns out — a phone camera pointed at a flashing laptop screen, all share that same constraint.

The hard-won bugs

The README is unusually candid about the failure modes that ate real debugging time — worth reading regardless of whether you ever build anything QR-related:

None of these are exotic. They're the specific, unglamorous class of bug that shows up whenever two independent processes have to derive identical pseudorandom state without directly synchronizing — a useful pattern to recognize the next time you're building anything with deterministic-but-distributed randomness.

"This already exists" — the prior art, in full

The top Reddit comment landed within the first hour: u/TheReal-JoJo103 linked mohankumarelec/airgapped-qr-code-transfer, a browser-based QR transfer tool with sequential chunking — roughly two years old. The pile-on continued from there:

The creator's own README addresses this directly, crediting divan/txqr by name and calling the overlap "convergent evolution." u/Alstroph's Reddit comments add: they reached the concept independently — not via a Claude brainstorming session — but used Claude Code to build the working prototype in one overnight session, and only found mohankumarelec's repo afterward.

Reddit's stickied mod-bot summary put it best: "the idea of transferring files via flashing QR codes is not new... basically a live-action 'Simpsons did it' meme, but people are still impressed with the execution." Genuinely useful framing — novelty and execution quality are separate axes, and this project scores low on the first and reasonably high on the second (129+ KB/s goodput beats the cited 4 KB/s prior art by roughly 30x, purely from the fountain-code loss tolerance).

Is it actually "airgapped"?

The pedantry was inevitable and, honestly, correct. An airgap, in the security sense, means zero data path between two systems — physical isolation with no electrical, radio, or optical connection at all. A camera reading a screen is a data path. It's optical instead of electrical or RF, and it's short-range and directional, but data is crossing the gap.

The community's rough landing spot: "close enough" for the practical threat model this actually targets — no shared Wi-Fi, no Bluetooth, no cable, nothing broadcasting on RF that a nearby receiver could passively intercept without direct line of sight to the screen. Encrypting the payload before transmission, several commenters noted, closes most of the realistic gap between "colloquially airgapped" and "actually isolated." It's a meaningfully narrower attack surface than a network connection — just not a true airgap in the way a security researcher would use the term.

The bigger thread: AI makes reinvention cheap — check first

The most substantive subthread wasn't about QR codes at all. It was about what happens when building something no longer requires days of research and setup — just an idea and an overnight Claude Code session.

One commenter's framing stuck: LLMs "exhaust and repeat their own ideas from the same generic start points" by design — that's what gradient descent optimizes for. A broad "build me a file transfer tool" prompt is statistically likely to land near the most common prior solution in that space, not a novel one. The burden of picking a genuinely novel angle stays on the human; the model won't naturally wander there on its own.

A second commenter described a fix already living in their own workflow: a standing custom instruction telling Claude to search for existing open-source libraries and projects before starting any large feature, added specifically after noticing how often the model built things from scratch that already existed as a well-tested library one search away. That's a cheap, durable habit — closer to PaulMakesThings1's framing of "of course I review the results before having it go on" than a blanket ban on building anything that might already exist.

The sharpest one-liner in the thread, upvoted heavily: "It's almost as if it would be cool to have some way to see if an idea has already been done before." Dry, but it names the actual gap — the tooling to check (search, patents.google.com, GitHub code search) has existed the whole time; what's changed is that the cost of skipping that step and building anyway dropped to nearly zero.

And the workplace-scale version, from a different commenter: as more people build their own AI-assisted tools, organizations increasingly end up with "50 versions of the same tool" — simultaneously the appeal of AI coding (a tool that fits your exact use case, at zero marginal cost) and a real duplication problem once it happens at team or company scale. This is the same tension explainx.ai covered in the "2x, not 10x" coding productivity debate — the work that "wouldn't have happened otherwise" is genuinely valuable, but it isn't automatically novel, and conflating the two is exactly how a team accumulates five internal Slack-bot clones nobody remembers building.

Practical takeaway: search before you vibe-code

If you're about to ask Claude Code or another agent to build something nontrivial, borrow the fix from the thread — make prior-art search a required first step, not an afterthought:

Before implementing this feature, search GitHub and the web for existing
open-source projects or libraries that already solve this problem. Report
what you find, including rough performance/maturity, before writing any code.

That single instruction would have surfaced mohankumarelec/airgapped-qr-code-transfer, divan/txqr, and libcimbar before Decimen's first commit — not to stop the project (the execution here genuinely improved on the ~4 KB/s prior art by an order of magnitude), but to make the "is this novel or just well-built" question a deliberate choice instead of a Reddit comment section finding out for you.

Summary

Decimen Optical Transfer sends files phone-to-phone using nothing but a screen flashing animated QR codes and a camera reading them — no network, no app, no pairing. The creator, u/Alstroph, built it with Claude Code overnight as an offshoot of a cached MP3-player project, and it demoed at up to 180 kb/s, roughly 30x faster than the closest two-year-old prior-art repo, thanks to fountain codes (LT coding) solving the fundamental one-way-channel problem: no retransmission needed, dropped frames just cost time, not correctness. The Reddit thread it triggered split cleanly between admiration for the execution and a immediate, correct chorus of "this already exists" — six-plus prior implementations going back to 1994. The most useful outcome wasn't the code; it was the reminder that AI coding tools make building fast, but they don't make searching for prior art automatic — that step still has to be deliberately asked for.

Related on explainx.ai

• "2x, not 10x" — what coding with LLMs actually delivers in 2026
• "Programming is low-intelligence work" — kache's X debate explained
• Vibecoding — Who is JSON? meme explained
• Gibberlink — the AI acoustic protocol, myth vs. engineering
• Agentic fatigue — the vibe-coding productivity paradox
• Claude Code commands — complete reference guide
• The AI Aesthetic — why AI apps look the same

Source: bashalarmistalt/decimen-optical-transfer on GitHub · r/ClaudeAI discussion

Performance figures, quotes, and prior-art references reflect the GitHub README and Reddit thread as of July 31, 2026. Throughput numbers are self-reported by the project creator — benchmark your own hardware before relying on any single figure.