Trasferimento esatto di file attraverso la luce.

LuminaLink explores a different boundary for file transfer: the display carries encoded frames, the camera observes them, and the browser processes the payload locally. The application is statically hosted, but user files and camera frames are not sent through a conversation backend.

That architecture changes the engineering priorities. The protocol must be explicit enough for two browsers to agree on framing, recovery, limits and final verification without making the server responsible for the payload.

The current design uses a versioned transfer manifest, typed Control, Source, Repair and Finalisation packets, fixed optical frames, strict bounds, CRC checks, systematic Reed–Solomon recovery and a final SHA-256 gate.

Sender preparation and receiver decoding run in dedicated Web Workers. Compression is selected only when it is lossless and beneficial, while the receiver validates filename, MIME, length and digest before presenting a recovered file.

The receiver can replay naturally numbered image recordings through the same visual decoder, parser, FEC and hash gate used by the live path. That gives the software a repeatable way to test failure handling and exact recovery.

It does not establish the physical display-to-camera operating envelope. A replay has no measured distance, angle, lighting or capture-drop history unless those are supplied by an immutable physical record.

A credible physical result needs more than a successful animation or a nominal frame-rate calculation. It needs the original file, the recovered bytes, matching hashes, measured channel and device conditions, frame loss and decode telemetry, and a record that the payload was not relayed.

Keeping that requirement visible is part of the product design. It protects the distinction between a strong browser protocol and a physical communication system that has actually been measured.