事件概述

GitHub 上出现了一个名为 QT 的开源项目（作者 moral666），定位为”一个端到端加密（E2EE）即时通讯内核的技术原型”：X3DH、后量子版本的 PQXDH、Double Ratchet、Sealed Sender、Noise Protocol 全部用 Rust 实现，并要求代码”真的能编译、能跑、有自动化测试验证它确实做到了它声称的事”。

该项目在 Hacker News 首页出现时的标题提到了一个性能数字——“124MB 内存支撑 1 万连接”。需要说明的是：原文正文并未给出这个数字的测试环境、连接类型或复现方法，仓库 README 中也没有对应的压测章节，因此这个数据目前只能视为标题层面的宣称，工程上不应直接引用。

同样需要强调的是作者自己的态度。README 里专门有一节叫”Sê honesto comigo: isto já funciona?”（对我诚实点：这玩意儿现在能用吗？），答案是”能，也不能”：加密、网络层、服务器、Android App 都已经有真实测试；但完整聊天界面、公网部署、TLS、联邦、外部安全审计全部缺失，作者明确写道”这不是成品，也不适合进行真实的对话”。

关键技术点

项目的模块划分相当清晰，每一块都对应密码学或系统工程中的一个明确职责：

模块 职责 README 声称的验证程度
core/ 会话建立（X3DH + 后量子变体）与持续加密（Double Ratchet） 14+ 自动化测试，含刻意应当失败的用例
transport/ 基于 WebSocket 的 Noise Protocol 链路保护 使用真实 WebSocket 连接测试，非模拟
server/ 消息投递，服务器无法读取内容 测试包含 kill -9 强制终止后数据存活
storage/ 身份与本地会话的加密落盘 测试包含”错误密码无法解密”
cli/ 终端客户端 使用完全独立的进程互相通信进行测试
ffi/ 面向 Kotlin / Swift / Python 的绑定层 已从 Python 侧验证
Android App 通过 FFI 证明整体可用 已在真实 Android 模拟器上运行过

值得注意的是设计取向上的两个细节：

身份不使用账号体系。 每个人的标识符由公钥派生，”没有人可以自己挑一个用户名”——这是刻意为之。README 的动机部分直言，绝大多数流行通讯软件都要求手机号注册，即便消息内容加密，注册行为本身仍然留下了”谁在何时和谁通信、频率多高”的元数据轨迹。项目试图用密码学身份（无手机号、无邮箱）来处理这个问题。

无后门是架构属性而非政策承诺。 README 提到欧盟正在讨论的 “Chat Control” 类立法，作者希望通信基础设施”按设计抵抗后门，而不只是靠政策声明”。因此代码全部开源，供任何人核验。

工程上还有一些容易被忽略但很务实的信息：

  • 依赖 redis-server 与 libsqlcipher-dev，说明消息中转和本地加密数据库分别选用了 Redis 与 SQLCipher 路线。
  • 后量子变体需要 Rust 1.81 或更新版本；普通测试用 cargo test --workspace，含后量子的测试需要单独用 cargo test -p qt_core --features pq 触发。
  • 仓库中包含 LICENSE-COMMERCIAL.md 与 QT-COMMERCIAL-LICENSE-AGREEMENT.md，即采用开源 + 商业授权双轨模式（具体条款原文未展开说明）。
  • 文档位于 docs/protocol-spec.md，README 称其为”分节说明的完整技术规范”。

作者列出的待办清单同样具体，没有粉饰：真正的聊天界面、公网可访问的服务器、wss://（当前仍为明文 ws://，仅适合测试）、多服务器联邦、数据库口令改由 Keystore / Secure Enclave 提供、以及由他人执行的独立安全审计。

对数据科学或 AI Agent 落地的意义

如果把视角从”聊天软件”切换到”Agent 通信基础设施”，这个项目有几处值得留意——以下是从项目特性出发的推论，并非原文结论：

  1. Agent 身份可以脱离平台账号体系。 当 Agent 数量膨胀到成千上万时，给每个 Agent 分配手机号或邮箱是不现实的。以公钥派生标识、服务端不可读内容、Sealed Sender 隐藏发送方的组合，恰好对应”机器对机器通信中最小化元数据”这个需求。

  2. 有状态的前向保密会话与长连接 Agent 存在张力。 Double Ratchet 为每条消息推进密钥链，而 Agent 的会话往往需要长期存活、跨进程恢复，甚至需要重放历史上下文。QT 把会话状态加密落盘并用口令解锁的做法，是这一问题的工程化尝试之一（当前口令来自命令行参数，这一点作者自己列为待改进项）。

  3. 内存与连接密度直接决定成本。 若”124MB / 1 万连接”这类密度数字成立，意味着单台节点可以承载的常驻 Agent 连接数相当可观，这对以百万级 Agent 为单位计费或调度的系统而言是实打实的成本变量。但如前所述，该数字缺乏公开的测试条件，不能作为容量规划的输入。

  4. 后量子与长期数据存档。 对于需要长周期留存的数据管道，PQXDH 这类混合方案的意义在于：今天被截获并存储的密文，不应在未来被量子计算能力追溯破解。这是数据合规与长期存档场景中正在被认真对待的威胁模型。

我的技术点评

先说优点。这个项目最值得称道的地方不是它实现了哪些密码学协议——X3DH、Double Ratchet、Sealed Sender 都是 Signal 系协议族中公开、成熟的设计，照做并不构成创新——而是它对验证的态度。README 里列的测试不是”跑通了 happy path”，而是刻意包含应当失败的用例、包含 kill -9 之后的持久化验证、包含用真实 WebSocket 而非 mock、包含用完全独立的进程测试 CLI 互通。一个个人原型项目愿意写这类测试，说明作者清楚”加密代码的正确性不能用演示视频证明”。

同样值得肯定的是诚实。作者在 README 第二段就把读者拦下来：”这不是成品，别浪费时间。”这份”哪些能用、哪些不能用、哪些要外部审计”的分段清单，比很多宣称”军用级加密”的商业产品要专业得多。而且作者把”由别人来做的独立安全审计”明确写进了缺口列表——一个自己实现的密码学库在未审计之前，应当被视为不可信，这是社区共识，作者没有回避。

再说需要泼冷水的地方。

第一，自制密码学实现本身就是风险。 即便协议选自成熟设计，Rust 实现中的侧信道、随机数来源、序列化边界、内存清零、错误处理路径等，都是极易出错的地方。在没有外部审计之前，这个内核的安全性只能算”作者自认为正确”。这恰恰是作者自己的立场，值得再强调一遍。

第二，README 中大量”✅ 已测试”的标签需要读者自行甄别其含义。 “测试通过”证明的是”在作者构造的用例下行为符合预期”，与”密码学安全”是两回事。二者之间隔着形式化验证、模糊测试、审计和大规模对抗性实践。

第三，性能宣称与代码现状之间存在明显落差。 HN 标题中的”1 万连接 / 124MB”是吸引点击的核心卖点，但正文完全没有支撑材料，当前传输层跑的还是明文 ws://。在缺少 TLS、缺少压测脚本、缺少资源画像的情况下，这个数字不宜被任何工程决策采纳。这也提醒我们：标题里的数字和仓库里的代码，永远是两件事。

第四，产品化路径比密码学部分更难。 待办清单里剩下的五项——UI、公网部署、TLS、联邦、Keystore 集成——每一项都比写加密内核更琐碎、更容易劝退个人开发者。联邦尤其如此，这是 Signal 至今没有做、Matrix 做了十年仍在磨合的难题。作者把它写成一句待办，实际上是一个独立的研究方向。

最后一点观察：HN 上的反馈是 7 分、1 条评论。这个热度对于一个有实质内容的开源项目来说偏低，可能与 README 主体使用葡萄牙语有关——虽然有 README.en.md，但默认入口的语言选择会显著影响传播半径。对想获得审计者、贡献者和安全研究者关注的隐私项目而言，这是一个可以低成本改善的环节。

总的判断：这是一个地基打得扎实、但离可用还有相当距离的技术原型。它适合作为学习 E2EE 协议栈在 Rust 中如何落地的参考实现，也适合作为讨论”AI Agent 通信该不该有自己的加密层”的一个具体锚点。但它不适合在现在这个阶段被任何真实通信场景采用。

原文链接