ActivityPub协议现可在ATProto上运行

背景

开放社交媒体领域正陷入一种类似政治派系争斗的局面：人们感觉必须选边站队，激烈捍卫自己的阵营，甚至宁愿互相攻击也不愿共同抵御更大的威胁（比如大型平台垄断）。这种氛围既典型于社交媒体生态，也十分愚蠢。作者认为，与其陷入无谓的站队，不如关注有趣的技术架构细节，或许能打开更广阔的讨论空间。本文正是以此为出发点，提出一个看似离奇但实际可行的设计构想：在 AT Protocol 的个人数据服务器（PDS）之上运行 ActivityPub。

核心内容

问题的提出：能否融合两大协议？

ActivityPub（AP）是 Mastodon 等联邦式社交网络的基础协议，采用类似电子邮件的联邦模型（服务器间交互）；AT Protocol（ATProto）是 Bluesky 的底层协议，设计为构建社交应用的通用工具箱，核心是一个个人数据服务器（PDS），支持可插拔身份和签名数据仓库。目前两派经常对立，作者认为二者并非不可调和。

ATProto ≠ Bluesky

需要明确区分：ATProto 是底层协议集，Bluesky 是构建其上的一个具体应用。ATProto 的架构明确围绕 PDS 定义，PDS 充当用户代理。Bluesky 团队虽然控制 app.bsky API 路由（实现 Bluesky 功能），但声明 com.atproto 路由应作为开放标准。因此，任何人都可以在 ATProto 之上实现其他协议。

关键桥梁：ActivityPub 的 Actor 文档

ActivityPub 的核心概念是 Actor（活动主体），其文档以 JSON 形式公开，包含 inbox、outbox、following、followers 等端点的 URL。这些 URL 可以指向任意位置——这个间接层正是融合的关键。

作者设想：将 Actor 文档中的端点 URL 指向自己的 ATProto PDS 上的 XRPC 方法，例如：

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://mastodon.social/users/robin",
  "type": "Person",
  "following": "https://pds.berjon.com/xrpc/org.w3.activitypub.following",
  "followers": "https://pds.berjon.com/xrpc/org.w3.activitypub.followers",
  "inbox": "https://pds.berjon.com/xrpc/org.w3.activitypub.inbox",
  "outbox": "https://pds.berjon.com/xrpc/org.w3.activitypub.outbox",
  "preferredUsername": "robin.berjon.com",
  "name": "Robin Berjon"
}

这样理论上 ActivityPub 的客户端就可以通过 ATProto PDS 来收发活动。

遇到的两个主要障碍

1. XRPC 方法类型限制：XRPC 的 nsid（如 org.w3.activitypub.inbox）要么是查询（GET）要么是过程（POST），但不能同时支持两种方法。而 ActivityPub 的 inbox 端点需要同时支持 GET（获取收件箱内容）和 POST（接收活动）。解决方法：可以在 Actor 文档中为不同方法分别指定属性（如 inbox-get、inbox-post），或修改 XRPC Lexicon 以支持方法重载。这不是根本性问题，只是社区需要达成一致。

2. 身份与句柄系统不完全对齐：ATProto 使用 DID（去中心化标识符）和句柄（如 robin.berjon.com），ActivityPub 使用 @user@domain 格式。作者认为这可以通过让 ATProto 的 com.atproto.identity.resolveHandle 方法也解析 @[email protected]（去掉 @ 并将分隔符改为 .）来实现。这与 IndieWeb 风格的 ActivityPub（Actor 拥有自己的域名）兼容。另外，Actor 文档可以指向 DID，DID 文档也可以反向链接回来。

结论：可行但需协作

尽管作者因工作繁忙未能完整实现原型，但初步判断这些障碍并非不可逾越，甚至比网络争论所暗示的要容易解决。关键在于社区愿意放下宗教式的争论，务实调整。

关键要点

• 核心构想：在 ATProto 的 PDS 上实现 ActivityPub 端点，利用 Actor 文档的 URL 间接层将两者衔接。
• 技术可行性：主要问题仅有两个（方法类型限制和身份对齐），均可在不改变两大协议核心规范的前提下通过小改动解决。
• ATProto 的优势：提供可插拔身份（不绑定服务器）和签名数据仓库，用户拥有真正的可退出权，不会被锁定，优于传统联邦模型（如电子邮件被 Gmail 垄断）。
• ActivityPub 的优势：基于 URL 设计，能与 Web 上任意内容进行社交化互动，但底层依赖服务器管理，用户受管理员控制。
• 融合价值：结合两者特性——利用 ATProto 的用户主权（身份和数据可迁移）来增强 ActivityPub 的联邦模型，同时保持 ActivityPub 的广泛兼容性。
• 当前状态：仅为设计挑衅（design provocation），尚未有完整实现，但作者认为值得尝试和讨论。

意义与影响

如果该构想得以实现，将打破开放社交媒体领域目前“二选一”的僵局。用户无需在 ActivityPub 体系（如 Mastodon）和 ATProto 体系（如 Bluesky）之间做出牺牲选择，而是可以同时享受两者的优点：既能与整个 ActivityPub 生态互操作，又能拥有 ATProto 带来的身份可移植性和数据自主权。这有助于真正打破社交媒体的孤岛效应——当前各大平台（包括联邦式服务器）都倾向于将用户困在内部，而结合两种协议有望创建一个更开放、更去中心化的社交网络基础设施。

此外，这种融合思路也为未来其他协议提供了范式：不必追求大一统的标准，而是通过精心设计的间接层和妥协来实现互联互通。作者强调，阻碍融合的往往不是技术难度，而是社区的“宗教式”立场。如果大家能放下偏见，集中精力解决实际细节，开放社交媒体将迎来更健康的生态。