「我们对这类平台没有任何对冲手段」
「如果 Signal 明天关掉服务器或停止欧盟业务，开源保护不了你。」Conversations 开发者、XMPP 社区核心人物 Daniel Gultsch 在 Jabber/XMPP 诞生 25 周年之际写下这句话时，针对的是欧洲机构在「数字化主权」采购中反复复现的一个错误认知框架。
Gultsch 把问题拆成两层：开源软件解决的是代码可信问题（可以审计、可以自行编译），开放标准解决的是供应商可替换问题（标准由多方博弈形成，任何一家公司倒闭都不带走生态）。这两件事在逻辑上相互独立——软件可以既开源又是围墙花园，协议可以既封闭又有替代实现。政府采购清单上「必须开源」这一条，解决的只是前者。
开源可以是围墙花园
Signal 的代码库公开可查，CEO 年薪接近一百万美元，服务器跑在 AWS 上。Gultsch 用这组数据说明的是「伦理稍好」和「基础设施达标」是两个不同的评估维度。Signal 的协议层无法被第三方服务器实现——代码可读，但无法在用户不知情的前提下运行一个兼容服务器接管通信。开源代码的可读性和互操作性之间，有一道真实存在的鸿沟。
Matrix 的情况更微妙。Element（前身 Riot/NewVector）发布的 API 以「Matrix」命名，但对规范修改保持严密控制；Matrix Foundation 关键职位主要由现任及前任 Element 员工担任；外部贡献进入规范被社区描述为「出了名的难」。Gultsch 的批评需要加一个背景标注：他本人是 XMPP 生态的利益相关方，这一立场影响其对 Matrix 的判断力度。对照组是 JMAP：Fastmail 发起后将协议带入 IETF 工作组流程，现有至少 3 个独立服务端实现和众多独立客户端——这才是「开放标准」在治理结构上的典型形态。
XMPP 解决了哪个问题
1999 年前后 Jabber 社区项目启动，2004 年 10 月原始 RFC 3920 正式发布，核心协议层在此后四分之一个世纪里维持稳定。这个数字有其具体含义：一个 2004 年的 XMPP 客户端，在协议核心层面与 2026 年的服务器仍然可以握手——没有几家商业即时通讯服务能做到这一点。稳定性在这里是可替换性的另一种表述：协议核心没动过，意味着切换服务商无需迁移数据格式。
功能演进通过 XEP（XMPP Extension Protocol）机制推进，而非修改协议核心。Stream Management（XEP-0198，防移动端丢消息）2009 年提案，2014-2015 年才获广泛实现——彼时 iPhone 已问世 8 年，首部 Android 手机 HTC Dream 已上市 7 年，移动化适配明显滞后。OMEMO（XEP-0384，端到端加密标准）自 2016 年起获得关注，背景是 2013 年斯诺登曝光 NSA 全球监控整整三年之后。这种节奏坦率地说不算快。支持者的论点是：迟但可查，每一步都有标准文档，任何实现都可以追溯到同一规范。
jabber.ru 事件：channel binding 的现实背景
2023 年发现的 jabber.ru MITM 事件为这场讨论提供了一个具体的技术参照点。俄罗斯最大 XMPP 服务在 Hetzner 与 Linode 的服务器遭到 TLS 中间人拦截，攻击者通过 Let’s Encrypt 正常签发流程取得恶意证书，在托管商网络层重定向 5222 端口流量做透明代理，持续时间估计长达 6 个月。
图：未被劫持的 5223 端口流量 dump，数据完好。来源：ValdikSS 事件分析
图：被劫持的 5222 端口流量 dump，应用层 ClientHello 已被替换。来源：ValdikSS 事件分析
事件的发现方式颇具戏剧性：一张 MITM 证书过期未续，客户端报「证书过期」，而服务器端证书全部正常——这个矛盾触发了调查。channel binding 机制此后成为自托管即时通讯方案中防 MitM 的技术手段之一。这个事件说明的问题在于：任何依赖托管商网络层的通信服务都面临同样的威胁面——差别在于协议层有没有工具可用。
Matrix vs XMPP：架构哲学之争，没有简单答案
HN 讨论中的技术争议值得单独呈现。质疑方（用户 lxgr）的论点有具体的工程依据：Matrix 对 IRC/Slack 类场景概念契合更好，房间与服务端历史是一等公民；XMPP 起家是消息路由协议，服务端历史是事后附加的；扩展支持混杂导致「你永远不知道会得到 plain old Jabber 还是类 Matrix 的体验」。另一位用户 tcfhgj 指出，加密聊天历史在新会话中不可恢复、存储时长取决于别人的服务器，这些是协议层差异，客户端设计层面无法绕过。
实战派的回应同样有具体数据支撑。一位声称日用 XMPP 十年的用户（ezst）指出，体验差异主要源于客户端设计选择，XMPP 消息传递核心 25 年未变是稳定性优势；真正的风险是大批用户滞留在失修客户端上——Pidgin 八年前的版本至今仍有人跑在生产环境里。现代客户端 Dino（Linux）和 Conversations（Android）在 emoji 反应、跨设备已读同步、时区指示器等功能层面已与专有协议产品持平。
两种立场的分歧本质上是场景差异：Matrix 在群组协作场景的设计优先级更高，XMPP 在点对点消息和联合分布式部署场景积累更深。把其中一个说成全面胜出，需要先说清楚用在什么场景。
25 年后，强条件是什么
XMPP 的 25 年真正值得追问的问题是：为什么 IETF 标准化流程下产出的协议，供应商可替换性比同样声称「开放」的替代品要高？答案在治理结构上：标准组织迫使不同利益方在同一文档上达成一致，外部实现有明确的规范可以对照，任何一家公司的退出都不会让其他实现失去参照系。这个机制和代码是否开源逻辑上是独立的。
欧洲政府机构在数字化主权采购中混淆两者，把验收「代码可审计」当成验收「供应商可替换」，是一个有工程代价的认知错误。2026 年进行中的 XMPP 社区探索——消息回复、画廊式多图分享、OAuth 支持的实验性 XEP，以及以「XMPP 2.0」名义重回 IETF 的讨论——可以理解为对这个认知错误的持续纠偏努力。「代码开不开源」是弱条件，「出了事能不能换供应商」才是强条件。这句话在 25 年后和 25 年前一样难以在采购清单上落地。
参考链接：
- Daniel Gultsch：Jabber/XMPP — 25 Years of Digital Independence
- ValdikSS：jabber.ru MITM 事件完整分析
- HN 讨论
