ActivityPub 首先是收件箱/发件箱协议，然后才是社交网络

一张真实会议照片适合 ActivityPub，因为这个协议最困难的工作在于社会性与运行层面的互操作：许多独立实现者要让 actor、activity、inbox、服务器策略在没有中央产品所有者的情况下彼此对接。[8]

ActivityPub 经常被压扁成“Fediverse 协议”这个说法，它的工程形状也随之变得模糊。更有用、也更耐用的理解范围要窄一些：ActivityPub 是面向 actor 的收件箱/发件箱协议，这些 actor 通过 HTTP 交换 ActivityStreams 对象。[1][2][3] 这个说法没有“去中心化社交网络”那么醒目，却是在其上开发之前应当先理解的层次。一台服务器加入的并非某个巨型应用。它承诺发布 actor 文档、接收 activity、把 activity 投递到其他 actor 的 inbox，并解释一套共享对象词汇，同时不能预设其他实现拥有同样的产品表面。[1][3]

这一区分对开源团队很重要，因为 ActivityPub 的优势也正是它的陷阱。这个协议为小项目提供了一条真实的互操作通道，可以连接 Mastodon、PeerTube、Pixelfed、Lemmy 风格社区、个人站点以及其他联邦系统。它提供的并不是完整的社交产品契约。Mastodon 自身文档展示了标准周围的实践黏合层：WebFinger 发现、ActivityPub actor 与对象约定、签名 HTTP 请求，都围绕着核心交换模型展开。[4][5][6] 一篇独立实现论文从另一侧得到相近结论：构建兼容 Mastodon 的服务器，面对的是 ActivityPub 加上 Mastodon 特定预期，而不只是孤立阅读 W3C recommendation。[7]

图片语境：封面图是真实照片，来自 ActivityPub Conference Prague 2019。[8] 它有意没有采用网络图。协议架构本身足够简单，可以画成图；但它的运行现实是人与项目要就足够多的共享行为达成一致，让独立运行的服务器交换社交状态，同时不坍缩成一个平台。

Actor 是联邦通信的边界

ActivityPub 中第一个真正有用的对象是 actor，位置早于帖子。W3C recommendation 把 actor 定义为能够执行 activity 的实体，actor 文档会公布 inbox、outbox、followers、following 等端点。[1] 这意味着，服务器到服务器的集成始于一个资源，它实际表达的是：这是我的身份，这是向我发送消息的位置，这是可以找到我已发布 activity stream 的位置。

这种 actor 优先模型让账户发现成为运行细节，而不是装饰性功能。Mastodon 的 WebFinger 文档展示了常见路径：通过 /.well-known/webfinger 查询一个 acct:[email protected] 资源，再用返回的链接找到 ActivityPub actor 文档。[4] ActivityPub 本身不会让每个发现步骤自动完成。生产实现仍然需要那些朴素的 Web 管道：主机名、HTTPS、内容协商、application/activity+json、稳定的 actor URL，以及足够严格的重定向纪律，让其他服务器持续找到同一个身份。[1][4][5]

采用边界由此直接展开。ActivityPub 最适合这样的产品：它可以把 actor 当成持久的公共集成表面。若身份只预期在一个数据库内部可迁移，账户 URL 不稳定，或者产品重心放在默认私密行为上，它的适配度就会下降。联邦从 actor URL 开始，因此后续再改变这条边界会付出高昂成本。

Inbox 与 outbox 不是 UI 隐喻

Inbox/outbox 这一对概念，是 ActivityPub 最清楚的架构分工。Outbox 是 actor 的 activity 被公开提供的位置；inbox 是 activity 被投递给该 actor 的位置。[1] 在规范的客户端到服务器部分，客户端可以把 activity 提交到用户的 outbox；而联邦语境通常聚焦服务器到服务器向 inbox 的投递。[1][5] 无论哪一种路径，协议建模的是作为 activity 交换的社交行为，而不是直接共享数据库。

这一点重要，是因为它把实现所有权留在本地。如果 Alice 关注 Bob、转发一篇帖子、喜欢一个对象，或者创建一条 note，接收服务器并没有执行 Alice 的代码，也没有共享 Bob 的数据库。它收到的是形状符合 ActivityStreams 的文档，例如 Follow、Create、Like、Announce、Accept 或 Delete，然后在本地策略和本地产品语义下决定这个文档意味着什么。[1][3][5]

这也是许多团队低估队列表面的位置。向远端 inbox 投递，是跨独立运行服务器的网络 I/O。有些目标会宕机、变慢、过载、解除联邦、受速率限制，或者运行在不同的软件假设之上。严肃的实现需要持久出站队列、重试策略、退避、投递日志以及按主机控制。规范定义了交换形状，却不会抹去分布式系统故障。

ActivityStreams 是共享语法，不是完整语言

ActivityPub 依赖 ActivityStreams 2.0 提供对象结构。[1][2][3] ActivityStreams Core 定义基于 JSON 的序列化模型，词汇表文档则定义 Actor、Object、Activity、Create、Follow、Note、Collection、orderedItems、to、cc、attributedTo、inReplyTo 等类型和属性。[2][3] 这是合适的标准化层级：共享语法足以让软件识别常见社交动作，同时也给每个应用保留各自的时间线设计空间。

这种取舍在互操作工作中很明显。一个兼容 Mastodon 的服务器，不只要关心通用 ActivityPub 对象，还要关心 Mastodon 在实践中如何期待个人资料、状态、附件、回复、collection、签名和投递流程运作。[5][7] 这不会让 Mastodon 成为“标准”。它意味着大型实现会围绕正式标准制造事实上的兼容压力。

对开发者来说，这里的含义很务实：从 activity 语法开始，然后诚实选择产品子集。只读发布站点可以支持 actor、Create activity、公开 Note 对象，以及用于回复或关注的 inbox 接收。社区应用会需要 Follow、Accept、Reject、Announce、Like、回复、审核对象、屏蔽与 collection 分页。媒体系统会需要更丰富的附件行为。协议允许这些形状共存，但兼容性取决于你的服务器实际发送和接收什么，并把这些边界写清楚。

签名与策略位于标准旁侧

ActivityPub 的协议层不会消除信任问题。Mastodon 的安全文档展示了实践部署中的常规做法：服务器对 HTTP 请求签名，让接收方验证一项 activity 确实由所声称 actor 的服务器发出；实现还需要 authorized fetch、重试、屏蔽域名和 activity 校验等控制。[6] 在实践中，ActivityPub 服务器把 W3C 词汇、WebFinger 发现、签名请求、本地审核以及实例级策略组合成一个运行表面。[4][5][6]

因此，对于想要“联邦”却不处理滥用问题的团队来说，这个协议适配度很低。一旦 inbox 足够公开，可以接收远端 activity，它就成了面向互联网的接口。它需要垃圾信息控制、对象大小限制、媒体抓取策略、请求验证、域名屏蔽，以及向操作人员解释投递决策的方式。载荷采用 JSON-LD 风格社交对象，并不会让这些工作变成可省略项。

安全边界也会影响产品设计。如果一个应用承诺私密群组、加密协作或严格租户隔离，ActivityPub 的公共联邦默认值会成为不合适的起点，除非团队已经准备好收窄所支持的表面。如果一个应用承诺公开发布、跨服务器关注、回复发现与本地审核自治，ActivityPub 的 actor/inbox 模型就更贴近它的纹理。

给实现者的真正教训

当团队尊重 ActivityPub 实际标准化的层次时，它最有力量。它标准化了 actor、collection、inbox、outbox、投递以及 activity 词汇。[1][2][3] 它没有标准化一个全局搜索索引、一个审核制度、一种引用帖行为、一个排序算法或一套迁移故事。这些缺席属于设计代价：许多独立治理的服务器要参与其中，同时不能变成单一产品。

因此，实际采用测试很直接。当你的应用受益于公共 actor 身份、跨服务器社交投递与本地策略自治时，可以使用 ActivityPub。当主要需求是低延迟私密协作、集中式分析、保证全局触达或完全一致的客户端行为时，就要谨慎。协议提供的是联邦原语。兼容性测试、队列健康、actor 稳定性、审核，以及社交体验中那些一旦失败就会被用户归咎于“网络”的部分，仍然由你负责。

这样理解时，ActivityPub 与其说是中心化社交软件的替代物，不如说是另一类软件的运行契约。它要求每台服务器暴露足够稳定的形状，让其他服务器能够通信，同时给每个项目留下足够空间保持自身特性。这就是核心架构持续有用的原因：actor 文档定义谁可以被寻址，inbox 与 outbox 定义社交事件在哪里移动，ActivityStreams 定义语法，实现则决定自己能够负责任地运行这个世界的多大一部分。[1][2][3][4][5][6][7]

cronfeed.work