[1] https://divan.dev/posts/animatedqr/
[2] https://divan.dev/posts/fountaincodes/
Recently I rewrote it in Dart/Flutter and finally implemented RaptorQ codes (way more efficient than Luby used in original Txqr). Testing it internally now, prepareing Appstores/GooglePlay/Web deployment and new article.
I've been noodling on https://qr-send.com which is a slightly more polished version of the "erasure fountain codes + stream of QRs"-idea, inspired by divan's Txqr posts but using Wirehair FEC for the fountain code (basically: you receive ~file size bytes via QR codes and it magically assembles them into the source file regardless of missed codes).
It's an offline-first progressive web app and there are native & wasm builds for the sender. The browser-to-browser transfer falls up to WebRTC when possible because 30 MB/s over wifi beats a 100 kB/s QR stream. The QR scanner is a heavily-optimized WASM build of zbar, scanning at 60 fps on mobile & multiple QRs per frame (but it's finicky! Work in progress.)
The WebRTC "fallback" basically means the QR code is just a handshake when both devices are on the same network?
I'm cooking something faster but depends on the job situation and funding whether I have time to spend on it.
Napkin math: QR codes encode 0.75 bits per module, each module needs about 3 pixels of camera resolution, and the temporal resolution is quite dodgy as well, maybe 0.25 * min(cameraHz, screenHz). So if everything is perfect, 44 kB/s at 60Hz per a 500x500 pixel patch. I've seen ~250 kB/s when a 1920x1080@60 transfer is working well. At 4k@30, you might reach 0.5 MB/s. If you throw in the 2x subsampled UV channels to transfer data as well, you might get an extra 50%.
I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.
I've daydreamed about also buying several different hardware random noise generators. XOR all of their bits together. Save a huge one time pad to each of our devices. And then also use public key crypto on top of it.
I'm not really sure why I want this. But, it's my answer for how to reduce attack surface as much as possible, and have truly secret messages.
Really goes to show that it's very difficult to stop a motivated and informed actor.
Downloading a tiny JS from a CDN, or accessing a GitHub page is mostly noise, especially if obfuscated well.
use a 1D code variant with very high FPS to work around the rolling shutter.