浏览器系统约 6 分钟

在浏览器里用光传文件。

LuminaLink 在浏览器里把文件编码成光信号，再从摄像头画面解码。数据留在本地处理，真实摄像头表现与软件测试分开说明。

项目范围

2026年至今 / 产品研究

协议与产品研究

主题

浏览器原生协议Web Worker + 本地处理物理链路尚未验证

不通过服务器中转完成传输

LuminaLink 探索一种不同的文件传输边界：显示器承载编码帧，摄像头观察这些帧，浏览器在本地处理数据。应用可以静态托管，但用户文件和摄像头帧不会被送入一个负责转发内容的会话后端。

这种架构把工程重点放在协议本身：两个浏览器必须明确理解分帧、恢复、限制和最终验证，而不是把 payload 的正确性交给服务器。

当前设计包含版本化传输清单、Control、Source、Repair 和 Finalisation 数据包、固定光学帧、严格边界、CRC 校验、系统化 Reed–Solomon 恢复，以及最终 SHA-256 校验。

发送端准备和接收端解码运行在独立 Web Worker 中。只有无损压缩确实有益时才使用它；接收端在展示恢复文件前，还会检查文件名、MIME、长度和摘要。

接收端可以把自然编号的图像记录送入与实时路径相同的视觉解码器、协议解析器、纠删码和哈希校验。这为软件的错误处理和精确恢复提供了可重复的测试方式。

但回放本身不能建立显示器到摄像头的物理工作范围。除非有不可变的物理记录，否则它不包含拍摄时的距离、角度、光照或丢帧历史。

可信的物理结果不能只依赖成功动画或名义帧率计算，而应包含原始文件、恢复字节、匹配哈希、设备与信道条件、帧丢失和解码遥测，以及 payload 没有经过服务器中转的记录。

把这个要求写在产品里，是为了保护“浏览器协议很强”和“物理通信系统已经被测量”之间的区别。

公开证据边界

数字协议和合成证据不能代替真实的显示器到摄像头证据。在有收据的物理试验恢复原始字节并匹配 SHA-256 之前，物理吞吐、BER、距离、角度与广泛设备支持均保持 NOT_VERIFIED。

每一页都会说明项目做了什么、公开了哪些证据，以及还有什么没有验证。

不通过服务器中转完成传输

这种架构把工程重点放在协议本身：两个浏览器必须明确理解分帧、恢复、限制和最终验证，而不是把 payload 的正确性交给服务器。

传输规则必须写得足够明确

发送端准备和接收端解码运行在独立 Web Worker 中。只有无损压缩确实有益时才使用它；接收端在展示恢复文件前，还会检查文件名、MIME、长度和摘要。

回放有价值，但不等于摄像头试验

但回放本身不能建立显示器到摄像头的物理工作范围。除非有不可变的物理记录，否则它不包含拍摄时的距离、角度、光照或丢帧历史。

下一步要做真实摄像头试验，并留下完整记录

把这个要求写在产品里，是为了保护“浏览器协议很强”和“物理通信系统已经被测量”之间的区别。