DEEP DIVE: ACTIVITYPUB

ActivityPub 详解：支撑联邦式社交网络的 W3C 标准协议

Mastodon、Misskey 等「联邦式社交网络」（俗称 Fediverse）并非运行在单一中心服务器之上，而是由无数彼此独立的服务器相互交换消息，共同组成一张巨大的社交网络。规定这套投递机制的标准就是 ActivityPub。本文详细介绍其 Actor 模型、基于 inbox/outbox 的投递方式、依靠 HTTP Signatures 与 WebFinger 实现的信任与发现机制，以及不同实现之间互操作的真实情况。

ActivityPub 是什么：支撑联邦式社交网络的 W3C 推荐标准

ActivityPub 于 2018 年 1 月正式成为 W3C 推荐标准（Recommendation），由 W3C Social Web Working Group 制定，是一套用于实现社交网络功能的开放联邦协议，把发帖、关注、点赞、转发等常见的社交行为，定义成可以在服务器之间交换的标准化消息。ActivityPub 本身规定的是消息「如何投递」以及「actor 之间如何互动」，至于帖子、个人资料这类数据本身的词汇表，则建立在另一份以 JSON-LD 表达的 W3C 推荐标准 ActivityStreams 2.0 之上。

「联邦（federation）」这一思路与电子邮件颇为相似：运行 Mastodon 等软件的无数服务器（实例，instance）各自独立运营，却又彼此通信，共同构成一张远比单一站点庞大的网络。用户可以在自己喜欢的实例上注册账号，同时依然能够关注、回复、引用其他实例上的用户，这与联邦协议整体的设计理念是相通的。

Actor 模型：inbox / outbox 与 Activity / Object

ActivityPub 的核心概念是 Actor。Actor 包括 Person（个人）、Group（群组）、Organization（组织）、Application（应用程序）、Service（自动化服务）等类型，每一个 Actor 除了自身的个人资料信息外，还拥有两个特殊的端点（URL）：inbox 与 outbox。当某个 Actor 发布内容时，该内容会被加入自己的 outbox，同时投递到关注者们的 inbox；反过来，其他 Actor 发来的关注请求、互动反应等，则会送达自己的 inbox。

Actor 之间的一切互动，都通过一种称为 Activity 的对象来完成，它是描述「谁对什么做了什么」的「动词」型数据，常见的有创建帖子的 Create、更新的 Update、删除的 Delete、关注的 Follow 及其对应的接受 Accept / 拒绝 Reject、点赞的 Like、把他人帖子转发给自己关注者的 Announce（即通常所说的转发/转推），以及用于撤销先前 Activity 的 Undo。Activity 所包裹的对象称为 Object，短文帖子对应 Note，篇幅更长的文章对应 Article，此外还有 Image、Video、代表活动信息的 Event 等类型。

Actor: 网络中的行为主体，类型包括 Person、Group、Organization、Application、Service 等。由专属 URL 唯一标识，以携带公钥、inbox、outbox 等信息的个人资料形式呈现。
Activity: Create、Follow、Like、Announce、Undo 等「动词」型数据，描述某个 actor 对某个 object 执行了什么操作。
Object: Activity 所作用的「名词」型数据，如代表帖子的 Note、Article、Image、Video、Event 等，由 ActivityStreams 2.0 词汇表定义。
inbox: 接收其他 Actor 发来的 Activity 的端点，关注请求、他人帖子的投递都会 POST 到这里。
outbox: 罗列该 Actor 自己发布过的 Activity 的端点。客户端向此端点发布新的 Activity，即会被处理为该 Actor 的一次活动。
Collection: 用于打包多个对象的有序或无序集合，例如关注者列表、outbox 的内容等，通常以带分页的 OrderedCollection 形式呈现。

投递机制：服务器间联合、HTTP Signatures 与 WebFinger

ActivityPub 规范定义了两套协议：客户端与服务器之间交换 Activity 的 C2S（Client-to-Server），以及服务器之间相互投递 Activity 的 S2S（Server-to-Server，即联合／federation）。但实际广泛使用的只有 S2S 一侧，以 Mastodon 为代表的大多数主流实现并未实现 C2S 部分，而是各自使用自定义的 REST API 或流式 API 与客户端通信。

当某个用户发布内容时，其所在服务器会从该用户的关注者列表中解析出对应的 inbox URL，把 Activity 序列化为 JSON-LD，并以 HTTP POST 的方式逐一投递到各个 inbox。如果同一台远端服务器上有多个关注者，逐条单独投递会造成浪费，因此常见的优化做法是只向 Actor 对象 endpoints.sharedInbox 所指向的共享 inbox 投递一次，再由接收方服务器在本地转发给自己的多个关注者。

HTTP Signatures：发送方服务器使用与 Actor 个人资料中公钥配对的私钥，对 POST 请求的请求头进行签名；接收方获取该公钥并验证签名，从而防止伪造并确认发送方 Actor 的真实性。该机制基于一份 IETF 草案（draft-cavage-http-signatures），并未被纳入 ActivityPub 规范本身，但由于 Mastodon 等主流实现采取「拒绝接受未签名 Activity」的策略（即所谓的 authorized fetch／安全模式），它在实践中已成为事实上的必备要素。
WebFinger（RFC 7033）：从形似邮箱地址、大家熟悉的 @user@example.com 这种 handle 出发，向 example.com 的 /.well-known/webfinger 端点发起查询，即可解析出对应用户的 ActivityPub 个人资料 URL（Actor 对象）。这是跨服务器发现用户的标准入口。

实现生态：不同服务之间也能相互关注

只要各服务共用 ActivityPub 这套语言，用途各异的产品便能彼此联合，让用户跨越服务边界进行关注与互动。

实现	领域	特点
Mastodon	微博客	fediverse 中使用最广泛、体验接近 Twitter/X 的服务；未实现 C2S，而是提供自有 API
Misskey	微博客	发源于日本，以自定义表情反应等丰富扩展功能著称，衍生实现众多
Pixelfed	图片分享	界面接近 Instagram 的图片为主的社交网络
PeerTube	视频分享	通过 ActivityPub 联合视频元数据与评论，视频本身的分发则与 WebTorrent 等 P2P 技术结合
Lemmy	论坛／链接分享	接近 Reddit 的社区型论坛服务
WordPress（ActivityPub 插件）	博客	让现有博客文章可以通过 ActivityPub 被关注与订阅
Threads（Meta）	微博客	一家大型服务，自 2024 年起逐步在部分地区与账号上推进对 ActivityPub 联合的支持

只要一项服务实现了共通的 Actor/Activity/Object 词汇表以及 inbox/outbox 这套通用投递路径，原则上就能实现跨异构服务的互动，例如论坛用户为视频分享服务上的帖子发表评论。

面临的挑战与局限

投递的扇出成本：拥有数万乃至数十万关注者的热门账号一旦发帖，其服务器就必须向关注者分布所在的、可能多达数千台不同的远端服务器分别发送 HTTP POST。共享 inbox 能合并投往同一服务器的重复投递，但随着服务器多样性的增加，投递处理的负担依然会不断上升。
垃圾内容与内容审核：任何人都可以架设服务器加入联合网络，这种开放性也可能成为垃圾信息与有害内容的来源。许多实例的管理员会采用断开联合（defederation，即整体拒绝来自特定服务器的流量）或黑名单来应对，但这种做法也带来了割裂整个网络的副作用。
不同实现之间的方言与兼容性问题：由于 ActivityStreams 2.0 词汇表本身设计为可扩展，各实现常常各自加入自定义扩展（如独特的表情反应、引用转发等），做法互不统一，导致某个实现中的功能在另一实现里经常无法正确显示。
删除与隐私的传播没有保证：即便发送了 Delete Activity，接收方的远端服务器是否真的清除了数据，完全取决于对方的实现与运营策略，协议层面并无任何强制手段。仅关注者可见等可见性控制，同样依赖接收方服务器实现上的善意配合。
账号迁移能力较弱：通过 Move activity 配合 alsoKnownAs／movedTo 属性，确实提供了把关注者从旧账号迁移到新账号的机制，但在大多数实现中，过往的帖子历史本身并不会随之迁移，仍会遗留在旧服务器上。

与其他联邦协议的比较

与 ActivityPub 目标相近的协议还包括 Bluesky 采用的 AT Protocol，以及依托中继服务器、设计更为简洁的 Nostr。AT Protocol 把每个用户的数据保存在其自有 PDS（Personal Data Server）的仓库中，因而在账号迁移与数据可携性上比 ActivityPub 更具优势，但代价是整体架构更为复杂。Nostr 则以接近去中心化身份标识的思路，把 Actor 的同一性直接绑定在公钥之上，用轻量级的中继（relay）取代服务器来承担消息转发角色，整体设计更趋极简。两者的详细对比可参阅各自的专题页面。