Magical Share sends files between nearby devices with nothing but light. One screen plays a stream of QR codes, and a phone camera reads them back into the file. There is no Wi-Fi, Bluetooth or internet anywhere in the path. The product walkthrough shows it from the user's side, and the web app lets you try sending from a browser.

This post is about the engineering. A camera pointed at a screen is a noisy, one-way channel, and four problems decide whether it works:

1. The receiver misses frames: motion blur, glare, autofocus, a hand that wobbles.
2. The sender has to draw about 60 large QR codes a second, including in a browser on a single thread.
3. The phone has to decode them at camera speed.
4. Anyone in the room can film the screen.

Everything below is Dart and Flutter, running on Android, iPhone, macOS and the web from one codebase.

Why a fountain code

The obvious design is a carousel: number the chunks, loop through them, and let the receiver collect what it missed on the next lap. It works, but the tail is slow. Once you have 95% of the chunks, you wait for exactly the missing ones to come around again, and missing one of those costs another full lap.

A fountain code removes the "exactly". We use a Luby transform (LT) code. The file is split into K source blocks, and every frame carries the XOR of a few of them. Any set of slightly more than K frames rebuilds the file, no matter which ones you caught. The receiver can join halfway through the stream, and a missed frame costs one frame of time, not a lap.

We chose the design by simulation. A systematic carousel needed 1.43 K frames at 2,000 blocks, even with no loss at all. The LT code needed about 1.15 K frames for a receiver joining mid-stream, whatever the loss rate.

The degree of each frame, meaning how many blocks it mixes, comes from a robust soliton distribution with c = 0.1 and δ = 0.5. Most frames mix a handful of blocks, a few mix many, and some carry a single block. The receiver runs a peeling decoder. Each single-block frame reveals a block, and XORing that block out of the waiting frames turns some of them into new single-block frames. That repeats until all K blocks are known.

Both sides must pick the same blocks

A frame doesn't list the blocks it mixed. Its header carries the session id, the sequence number and the degree, and both sides derive the block indices from those three numbers with a small integer-only random number generator:

List<int> blockIndicesFor({sessionId, seq, k, degree}) {
  if (degree == 1) return [seq % k];
  final rng = Xorshift32(mix32(sessionId ^ mix32(seq)));
  // ...then pick `degree` distinct indices below k
}

Integer-only matters because the same derivation runs as native code on phones and as JavaScript or WebAssembly in the browser. Floating point appears in one place only: the sender samples the degree from the soliton distribution and writes it into the header, so a rounding difference there can't put the two sides out of step. Golden tests pin the derivation, and changing it would need a new wire version.

Each frame starts with a 28-byte header:

The receiver checks the CRC and the header's limits before it allocates anything, so a hostile code can't make it reserve gigabytes.

Drawing 60 QR codes a second

Each frame goes into a version 40 QR code, the largest there is: 177 × 177 modules holding up to 2,953 bytes at error correction level L. L is the weakest level, and that's fine here. The fountain code already treats a code that fails to decode as one lost frame.

We also skip the mask search. A normal QR encoder tries all eight masks and scores each one, which is most of the work for a large symbol. Every mask is valid for a decoder, so the stream always uses mask 4. In our experiments a fixed mask decoded as reliably as the search for dense frames.

With the mask fixed, almost everything about a version 40 symbol is constant: the finder and timing patterns, the order data bits are placed in, which bits the mask flips, and the Reed-Solomon generator polynomials. Our encoder computes those once and caches them. Each new frame only builds its codewords, computes error correction with log tables and drops the bits into place. It produces exactly the same symbols as package:qr, about 30 times faster. That is what makes the web app possible, where the whole stream runs on one browser thread.

The sender offers three speeds:

The ceiling assumes every code is caught. Real transfers catch a fraction of them, which is where the fountain code earns its keep.

Reading at camera speed

On the phone, camera frames go to background isolates that decode with zxing-cpp through FFI. We run one worker for every two CPU cores, up to three, so decoding never blocks the camera or the interface. In field tests a frame took 4 to 45 ms to decode, and no frame was dropped for lack of a free worker.

The surprise was the camera, not the decoder. Our first Android build used the CameraX implementation of Flutter's camera plugin. It fetched each frame's image planes over extra platform-channel round trips and waited for them before delivering the next frame. We asked for 60 fps and got 6 to 12. With a Mac sending to a Galaxy A53, 650 KB took 45 to 50 seconds, about 13 KB/s.

Switching to camera_android, the Camera2 implementation, fixed it, because it sends each frame in one message. At 720p and 30 fps, the same phone received 1.9 MB in 39.5 seconds: 48 KB/s. It caught only 32% of the frames over the run and still finished. With a carousel, a 32% catch rate would have meant lap after lap.

Safe even if someone films the screen

A screen is a broadcast medium, so the file is sealed before it becomes codes. The envelope holds the file name, type, size and SHA-256 hash. The body is compressed with Deflate when that makes it smaller, and then encrypted.

• Key mode. The receiving phone makes a fresh X25519 key pair every time its Receive screen opens, and shows the public key as a QR code. The sender scans it, derives a key with HKDF-SHA256 and encrypts with ChaCha20-Poly1305. Both screens show an eight-digit check number taken from the SHA-256 of the public key, so two people can confirm they locked onto the same phone. Receive keys are never stored.
• Passphrase mode. For when scanning isn't practical. The key comes from Argon2id with 19 MiB of memory and 2 iterations, the OWASP minimum. The cost settings travel in the envelope, and the receiver refuses settings outside safe limits, so a hostile sender can't make it burn gigabytes of memory.
• Open mode. No encryption, with a warning before sending.

The envelope's protection header is authenticated as associated data, so it can't be swapped. The receiver refuses compression bombs and cleans file names so they can't escape the save folder. After decrypting, it checks the SHA-256 of the whole file before showing it.

Testing a channel made of light

Most of this is testable without a camera:

• The codec, crypto and fountain tests run as plain Dart.
• A pipeline test renders the sender's stream to pixels, decodes the codes from those pixels with an independent decoder, and rebuilds the file.
• Golden tests pin the block-index derivation, so a harmless-looking refactor can't break compatibility with apps already installed.

Field tests cover the rest: real screens, real cameras and real hands. While it works, the receiver shows the camera frame rate, decode time, codes per second, the share of frames caught, and the speed. That is how we found the CameraX bottleneck.

No internet, really

The Android release build doesn't declare the INTERNET permission, so the app cannot open a network socket at all. We also strip the network-state, audio and storage permissions that plugins add. The Mac build is sandboxed with no network entitlement. Google Play Billing still works, because the purchase runs inside the Play Store app; we confirmed it with a test purchase on a release build.

If you build one

• Use a fountain code from day one. It makes every other problem cheaper.
• Measure the camera's frame rate before you optimize the decoder. Ours was the bottleneck by a factor of three.
• Keep everything both sides compute in integers, and pin it with golden tests.
• Expect 50 to 100 KB/s with ordinary phones. That is right for documents, photos, keys and boarding passes, not for videos.

You can try the sender in your browser at apps.zincirx.com/magicalshare/web and catch the file with Magical Share for Android. Questions about the design are welcome at info@zincirx.com.

The two-foot problem

Your phone and your laptop sit two feet apart on the same desk. Yet moving one photo between them usually means a round trip through a server on another continent.

We email files to ourselves. We message them to our own chats. We upload a PDF to a cloud drive just to download it again a minute later. Each of those copies lands on someone else's computer, tied to an account, and often stays there long after we forget about it.

And when there is no Wi-Fi at all, on a plane, in a basement office, or on a locked-down work network, most of those tricks stop working entirely.

We wanted something simpler: point one screen at another, and the file just moves. No internet, no account, no copy left behind anywhere. That idea became Magical Share.

Meet Magical Share

Magical Share moves files between nearby devices using light. The sending device shows a stream of moving codes on its screen. The receiving phone reads them with its camera and rebuilds the file.

Nothing goes over the internet, Wi-Fi or Bluetooth. There is nothing to pair and no account to create. It works between an iPhone and an Android phone, from a computer to a phone, and anywhere there is no signal.

It comes in three forms:

• A free web app that sends from any computer's browser, at apps.zincirx.com/magicalshare/web.
• An Android app that sends and receives, on Google Play.
• A Mac app that sends, on the Mac App Store. The iPhone and iPad version is on its way.

How it works, in plain English

Every transfer goes through three steps.

1. Packed and sealed. The app wraps the file with its name, size and a SHA-256 fingerprint. It can compress the file and encrypt it.
2. Turned into a fountain of codes. The file is split into blocks, and each frame mixes a few blocks together. The screen shows two large QR codes at a time, 30 times a second.
3. Caught and checked. The receiver decodes camera frames in the background and works out the original blocks. Once it has them all, it checks every byte against the fingerprint before showing the file.

The clever part is the fountain code. Think of filling a glass under a fountain: it doesn't matter which drops you catch, only that you catch enough. The receiver can start scanning at any moment, and a missed or blurry frame costs only a fraction of a second.

In simulation, a receiver joining mid-stream needed only about 15% more frames than the minimum, however many frames it missed along the way.

Locked to one phone, even if someone films your screen

A screen full of codes is visible to anyone in the room. So Magical Share encrypts the file before it ever reaches the screen. You choose one of three protection modes:

• Key. The receiving phone shows a code holding a fresh public key. The sender scans it, and from then on only that phone can open the file. Both screens show the same eight-digit number, so you can confirm you locked onto the right phone.
• Passphrase. Say a word out loud instead of scanning a code. The encryption key is derived from it with Argon2id.
• Open. No protection, for things like a public flyer. The app warns you before sending.

Under the hood, Key mode uses X25519 key agreement, HKDF-SHA256 and ChaCha20-Poly1305. Receive keys are created fresh every time you open the Receive screen, and they are never stored.

Send from any browser: the web app

The quickest way to try Magical Share is the web app at apps.zincirx.com/magicalshare/web. It runs in a modern browser on any computer, and sending from it is free.

How to use it:

1. Open apps.zincirx.com/magicalshare/web on your laptop or desktop.
2. Click Choose a file to send, and set a passphrase so only someone who knows it can open the file.
3. On your phone, open Magical Share and tap Receive, then Start scanning.
4. Point the phone's camera at the computer screen. Make the codes big and bright. Missed codes don't matter.

Nothing is uploaded. The page turns the file into codes right in your browser, so the file never leaves your computer. Opening a file sent from the web uses Magical Share Pro or its free 7-day trial on the phone.

Send and receive on your phone

The phone app does both jobs. Get it on Google Play for Android. The iPhone version is coming to the App Store.

To receive a file:

1. Open Magical Share and tap Receive. The screen shows your one-time key and an eight-digit number.
2. Tap Start scanning and point the camera at the sender's screen.
3. The file appears as soon as every byte checks out, and it is kept in the app's private Received list.

To send a file:

1. Tap Send and pick a file.
2. Choose a protection mode. With Key, scan the receiver's code and check that both screens show the same number.
3. Pick a speed: Fast for phones held close and steady, Balanced for a comfortable distance.
4. Tap Start sending and hold your screen toward the other camera.

Received files stay inside the app, on that device only, until you delete them. If you would rather keep nothing, switch off Keep received files and each file is discarded when you leave it. App lock can require Face ID, a fingerprint or your device PIN, and relocks the app after 30 seconds away.

The app speaks 30 languages and follows your device language.

Send from your Mac

The Mac app is a sender. A large display makes an excellent transmitter, because bigger codes are easier for a phone camera to read. Pick a file, set a passphrase, and click Start sending.

Private by design

Privacy in Magical Share is how the app is built, not a setting you have to find:

• The Android app has no internet permission at all, so it cannot open a network connection.
• The Mac app runs in Apple's sandbox with no network access.
• There are no accounts, analytics, crash reporters, ads or trackers. The App Store privacy label reads "Data Not Collected".
• File names from senders are cleaned so they can't escape the save folder, and malformed input is rejected before it is processed.

Where it shines, and what it isn't for

Magical Share works where other sharing doesn't:

• On a plane, in a basement, or abroad without mobile data.
• Between an iPhone and an Android phone.
• On hotel or office Wi-Fi that blocks devices from seeing each other.
• On managed devices where Bluetooth or Wi-Fi is switched off.

It is built for documents, photos, contacts, notes, boarding passes and Wi-Fi passwords. Typical speeds are 50 to 100 KB per second, so a 500 KB PDF takes about 5 to 10 seconds. A large video is better sent another way.

One caution: the sending screen flashes rapidly at full brightness. If you are sensitive to flashing lights, don't look at the sending screen.

Pricing

• Free to download.
• Receiving from other phones is always free.
• Sending is free for 7 days, then a one-time Pro unlock of US$3.99. No subscription and no account.
• Sending from the web app is free. Opening web files on a phone needs Pro or the trial.

If you try it, we'd love to hear what you sent and where. Write to us at info@zincirx.com.