工作尾部的长尾：直到ActivityPub具备E2EE

与我提出的 Fediverse 的关键透明度 提案（我早已在博客中多次提及）不同，W3C 目前正在开发的是 致力于为 ActivityPub 构建端到端加密 (E2EE)。

这两个项目大多独立开发，尽管两者之间仍存在相互连接的潜在可能性——通过 应该很简单 实现联动。

在准备收尾工作、将我这边的工作称为“功能完备”，并考虑为该规范及参考实现标记一个主要版本 1.0.0 时，我意识到，有必要先梳理清楚为了将这一项目顺利推进至终点所必须完成的各项任务——部分原因在于， 大多数技术从业者都可以在此阶段开展有意义的贡献，而无需具备安全或密码学方面的专业知识。

与我大多数博客文章（这些文章本意是成为某些博主口中所谓的“常青”内容）不同， 我完全打算让这篇博文随着时间的推移逐渐失去实用价值，因为随着工作的不断推进， 其意义也会随之逐步显现。

为了更清晰地说明问题，我将从期望的最终状态出发，反向推进，逐层深入探讨每项工作所需的前提条件， 随后再制定一份路线图。只要阅读过前面的文字，这份路线图应该不会带来任何意外。

艺术：CMYKat

逆向工程

这是一项复杂的工作，因此我认为，最好先将期望的最终状态提炼为三个截然不同的目标。

根本目标：Fediverse 用户应能够彼此发送端到端加密的消息，消息中可包含附件。 同时，该系统必须高效支持群组消息，而不仅仅是单对单通信。 目前，这一功能正通过使者与篝火 实现，其基于一种名为 消息层安全（MLS、 RFC 9420） 的协议构建而成。

安全目标：用户应能够确信，端到端加密过程已正确执行，并且使用了正确的封装密钥。

为此，每个封装密钥（以 MLS 所称的 密钥包 形式交付）都必须由用户在客户端进行签名……