Summary

  • MIMI 协议草案第 07 版于 2026 年 11 月 2 日更新，仍在工作组阶段。第 5.10 节描述存放在消息外部的加密附件，内容对象 ExternalPart 携带 HTTPS 下载地址。
  • 客户端直连文件服务器时，后者看到客户端 IP 与请求时间。hub 代理替读者去取文件，遮住这项地址，却仍让接收方服务商有机会把 URL 与用户、群聊对应起来。
  • OHTTP 用中继和网关再次拆开观察范围。草案要求 hub 提供网关，建议其他服务商提供中继；在此场景的具体收益，是接收方服务商不再直接知道每个附件存放在哪家文件服务器。

设想一个群聊横跨三家通信服务。成员发来加密照片，消息里带着取图地址；收件人点开图片。照片内容在存储端依然密封，取图动作却留下时间、目的地和请求路径。哪家机构能把这次动作与某个人或群聊对上，取决于选用哪条路线。文件上锁，不会替系统决定谁拿访客名单。

RFC 9420为群消息提供 MLS 加密机制。MIMI 把跨服务传输接在它周围，并把附件作为独立加密对象处理。配套的群聊政策草案用 asset_policy 限制可用的附件存储域名。这项选择决定哪家服务器收到下载请求，也决定谁取得第一手访问记录。

最短的路，把读者交给文件服务器

第一条路线是客户端直接向附件服务器下载。草案指出，服务器会看到读者的 IP 地址和取件时间。同一附件被哪些客户端读取，可能暴露他们何时在线，或是否同处一个群聊。因此草案将直连，尤其是跨服务直连，列为 NOT RECOMMENDED。照片可以始终是密文，网络交易仍在叙述谁来取过它。

第二条路线由接收方服务商向 hub 请求 GET /proxyDownload/{downloadUrl}，hub 再去附件服务器取文件。存储方看到的是 hub，而非读者的地址。hub 知道哪家服务商请求了哪个 URL，但代理请求不直接写明具体用户或群聊。这实实在在收窄了存储方和 hub 在单次请求中的视野。hub 还必须核对目标域名属于已配置的伙伴附件服务器，免得附件代理变成访问任意网站的开放代理。草案要求 hub 实现这条路线。

接收方服务商的视野不同。它服务读者，也知道读者请求的 URL。草案明确指出，它可以把链接与用户对应，并推断链接出现在哪个群聊；还可能比对群聊消息到达与代理取件的时间。接收方或 hub 把文件缓存起来，会使部分时间匹配更难，因为一次上游获取可以服务多次下载。代理保护了读者不直接暴露给存储方，并没有剥夺接收方服务商的关联能力。

OHTTP 换了知情者，也增加了运营者

第三条路线把请求封装在 OHTTP 中。客户端通过接收方服务商的中继，把受保护请求交给 hub 的网关，再由网关向存储方取件。RFC 9458让中继看到客户端连接，却看不到受保护的目标请求；网关看到目标，却不直接接收原始客户端连接，前提是角色确实分开。MIMI 要求 hub 提供网关，建议其他服务商提供中继，网关的目标仍限于伙伴配置的附件域名。

草案为这条路线写下一个具体收益：接收方服务商不再直接知道用户每个附件的存储域名。网关仍须知道目标才能取件；接收方仍看得到用户何时使用中继。如果同一机构掌握两端日志，或把多个角色放在同一运营控制下，纸面分离的视野又能拼接起来。部署时应写明每个角色由谁运行、日志保留多久、谁有权限合并。

官方材料没有测量现实部署中推断群聊成员的准确率。用已知附件分别走三条路线，再打开和关闭缓存，对照各参与者可获得的日志，才能测出选定架构暴露什么。设计选择已足够清楚：加密负责照片内容；下载架构决定访客名单落在谁手里。跨服务私密附件的承诺，应从这份分工表开始。

MIMI 草案 · RFC 9458 · RFC 9420 · MIMI 群聊政策