联合式分布详解：既非中心化，也非纯粹 P2P 的第三条路
社交网络和聊天服务常被简单地归为两类：要么是「由一家公司运营全部服务器」的中心化模式，要么是「设备之间直接通信、完全没有服务器」的 P2P 模式。而在两者之间，其实存在一条历史几乎和电子邮件一样悠久的第三条路，也就是「联合式（Federation）」：由多个独立运营的服务器通过共同协议松散地互联在一起。本文详细介绍联合式架构的运作方式、Fediverse 的真实面貌，以及它的优势与困境。
中心化、联合式、纯分布式：联合并非新鲜事物
互联网服务按运营方式大致可分为三类。中心化（Centralized）由单一组织运营单一的服务器集群，全体用户都连接到这里，绝大多数 Web 服务都属于这一类。纯分布式（P2P）完全没有中心服务器，用户设备之间直接交换数据。联合式（Federated）则介于两者之间：任何人都可以独立运营自己的「服务器（实例，instance）」，这些实例通过共同协议相互通信，共同构成一个整体网络。用户在某个特定实例上注册账号，但只要该实例与其他实例保持联合关系，就能与不同实例上的用户互动。
联合式的要点，既不是「单一的巨型服务器」，也不是「没有服务器的设备间通信」，而是多个自治的服务器以对等身份、通过协议相互连接。每个实例的管理员可以自行制定本服务器的政策、使用条款与内容审核方针，但要与外部实例交换消息或内容，就必须遵循彼此共通的「语言」：协议。
联合式架构绝非什么新鲜发明。运行时间最长的联合式系统，正是电子邮件本身。自 1982 年 SMTP（Simple Mail Transfer Protocol，RFC 821）标准化以来，无论是 Gmail、ProtonMail 还是自建邮件服务器，只要知道形如 user@domain 的收件地址，不同组织运营的邮件服务器之间就能通过 SMTP 相互转发邮件。用户可以自由选择自己喜欢的服务商注册账号，但电子邮件这项服务本身并不属于任何一家公司。
另一个原型是 XMPP（Extensible Messaging and Presence Protocol，前身为 Jabber）。这一基于 XML 的消息协议从 1999 年开始开发，2004 年由 IETF 完成标准化。2000 年代中期，包括 Google Talk 在内的多个聊天服务都曾通过 XMPP 实现联合，让不同服务的用户可以直接互发消息；但 Google 在 2013 年终止了 Google Talk（后来的 Google Hangouts）的开放联合。这一事件常被引用作为一个先例：联合式系统即便在技术上完全可行，也可能因为运营方的一个商业决定而被关闭。
Fediverse：选择一个实例，松散地联合起来
近些年与「联合式」一词相伴出现的是 Fediverse（「Federation」与「Universe」的合成词）。其核心是 ActivityPub 协议，由 W3C 的 Social Web Working Group 制定，并于 2018 年发布为 W3C 推荐标准。任何支持 ActivityPub 的软件，无论开发者或运营方是谁，都能相互交换关注、发帖与互动，Mastodon、Misskey、Lemmy 等多种多样的服务正是借此构成了一张松散连接的网络。
用户加入 Fediverse 时，首先要选择一个实例（instance，即服务器）并在其上注册账号。账号的形式是 @user@instance.example，与电子邮件地址一样把所属实例包含在内，因此任何实例上的用户都可以被找到并联系上。用户可以根据兴趣、语言或内容审核方针来选择实例，如果日后想换到另一个实例，也可以借助账号迁移功能。
- 本地时间线（local timeline）：只显示本实例内用户发布的帖子。
- 联合时间线（federated timeline）：在本实例用户的帖子之外，还会显示从已联合的其他实例传入的帖子。但这终究只是本实例「能看到」的那一部分帖子的集合，并不等同于可以横跨整个 Fediverse 进行全局搜索。
- defederation（断开联合）：实例管理员可以针对性地切断与某个充斥垃圾信息或有害内容的实例之间的通信。这让社区得以集体拒绝不受欢迎的对象，但被切断的一方的用户也会因此被排除在这部分联合网络之外。
联合式的优势
- 分摊运营成本：不必由单一组织承担全体用户的服务器费用与运维负担，众多由志愿者或社区运营的小型实例并存，使整体基础设施成本得以分摊。
- 以社区为单位的自治式内容审核：每个实例的管理员都可以制定符合自身社区特点的规则与审核方针，这与向全体用户强加统一政策的中心化平台形成鲜明对比。
- 缓解单点故障与单点审查：即便某个实例宕机、关闭，或在某个国家被封锁，其他实例及其用户依然能不受影响地继续存在。相比中心化服务，单一企业或政府想要关闭或审查整个网络要困难得多。
联合式的困境
- 依赖实例管理员：实例能否存续，很大程度上取决于志愿管理员的意愿与资金能力。一旦管理员停止运营，该实例上的账号与帖子往往会随之全部消失，这与大公司运营的中心化服务所能提供的高可用性之间存在明显的取舍。
- 因 defederation 造成的割裂：前面提到的 defederation 本是排除有害实例的自治手段，但如果被过度使用，也可能让特定实例之间事实上分裂成互不相通的「孤岛」，让用户在不知情的情况下被隔绝在部分社区之外。
- 账号与数据可迁移性有限：不少实现都支持迁移关注关系，但要把历史帖子、私信等内容一并完整迁移通常十分困难，更换实例的成本不容小觑。
- 向大型实例再度集中：尽管理论上任何人都能架设实例，但实际上用户账号往往会集中到少数几个用户众多的大型实例上，网络效应使整个系统呈现出「名为联合、实为集中」的倾向。针对同一个问题，还有一些不同的应对思路，例如基于 DHT、由全体参与者共同持有数据的纯 P2P 设计，通过中继（relay）实现联合的 Nostr，以及使用带签名仓库、强调数据自主权的 AT Protocol。
实例与对比：Mastodon、Misskey、Lemmy、Matrix 与电子邮件
Fediverse 中最具代表性的 Mastodon（2016 年发布，开发者为 Eugen Rochko）提供类似 Twitter 的微博客服务；日本出品的 Misskey 以独特的界面与表情回应文化著称；Lemmy 则提供类似 Reddit 的链接聚合与论坛服务，三者都通过 ActivityPub 实现联合。在文字聊天领域，Matrix 使用一套不同于 ActivityPub 的独立联合协议（各个 homeserver 之间同步一份仅追加的事件图，并通过一种与分布式共识思路相通的状态解决算法来消解分歧），实现了跨多种客户端与服务器实现的互通。而电子邮件，则始终是所有这些系统之前、运行时间最长的联合式系统。
| 系统 | 联合的对象 | 联合协议 |
|---|---|---|
| 电子邮件 | 消息（一对一、一对多） | SMTP（1982 年起） |
| XMPP / Jabber | 聊天与在线状态 | XMPP（2004 年 IETF 标准化） |
| Mastodon | 微博客 | ActivityPub |
| Misskey | 微博客 | ActivityPub |
| Lemmy | 链接聚合与论坛 | ActivityPub |
| Matrix | 聊天、语音/视频 | Matrix 自有的 server-to-server API |
抛开这些具体实现，单从架构本身来比较，中心化、联合式与纯分布式（P2P）三者的差异可以归纳如下。
| 维度 | 中心化 | 联合式 | 纯分布式（P2P） |
|---|---|---|---|
| 身份管理 | 由单一运营方签发与管理 | 按实例签发，形如 user@instance | 多为公钥等自主身份 |
| 数据存放位置 | 集中存放在运营公司的数据中心 | 分散存放在各个实例的服务器上 | 分散存放在各个节点（设备）上 |
| 抗审查能力 | 容易受单一运营方的决定左右 | 按实例各异，整体上中等偏高 | 没有单一的可关闭点，原理上很高 |
| 典型体验 | 单一 App、单一体验，高度一致 | 不同实例的功能与外观略有差异 | 专用客户端的学习成本相对较高 |
| 运营成本 | 集中由运营公司承担 | 分摊到各个实例管理员身上 | 分摊到各个用户（节点运营者）身上 |
相关页面
联合式架构的思路，与本站介绍的其他技术也有诸多交集。作为 Fediverse 共通语言的 ActivityPub 详解，把本文所说的「通过共同协议互联」落实成了具体的消息格式。面对联合式所面临的再集中问题，AT Protocol 详解 用带签名的仓库与可自由更换的中继给出了自己的答案，而 Nostr 详解 则干脆舍弃了「服务器」这一单位，仅由一组中继构成整个网络。若想了解更彻底的分布式形态，可参阅 DHT 详解：那里没有任何中心服务器，数据完全由全体参与者共同持有。此外，让多个实例之间的状态无矛盾地趋于一致，这一机制也与分布式共识的思路一脉相承。