ActivityPub 赢在了无聊之处

# ActivityPub因枯燥而胜出 来源：https://o.ee/blog/activitypub-won-by-being-boring/ 在FediForum 2026大会上，Evan Prodromou（https://evanp.me/）的演讲标题带有只有协议合著者才能驾驭的调侃意味：“如何在ActivityPub对话中胡侃一通”。 这个笑话之所以奏效，是因为演讲者根本无需掩饰。Prodromou是W3C ActivityPub规范（https://www.w3.org/TR/activitypub/）五位署名作者之一，也是O'Reilly出版社《ActivityPub》（https://www.oreilly.com/library/view/activitypub/9781098162733/）一书的作者。这种自嘲式的开场，实则是对联邦宇宙为何能运作的坦诚技术架构解析。 他贯穿全场的幽默是将每个术语都当作合成词来解读。Fediverse（联邦宇宙）是federated（联邦）加universe（宇宙）。ActivityPub是activity（活动）加publishing（发布）。而他令人莞尔的版本中，RESTful是rest（休息）加full（完全）。好吧，协议设计者也有权拥有自己的幽默感。 笑话背后隐含着严肃的论断：ActivityPub之所以成功，核心在于它刻意保持平庸。它的卓越如同一个高效装卸平台般令人印象深刻——卡车抵达，货物流转，无人会为叉车谱写诗篇。 任何2010年代中期的合格Web工程师看到ActivityPub都会认为，这大致就是他们也会采用的方式。 若想在争论前先了解基础，请阅读《什么是ActivityPub？》（https://o.ee/blog/what-is-activitypub/）。本文旨在探讨这些熟悉设计的重要性。 ## 协议部分刻意平淡无奇 联邦化始于一个朴素的约定。独立网络之间约定交换活动数据。它们无需在数据库、审核模型、准入策略、用户界面、排名系统或产品品类上达成一致。 这种最小化共识才是关键。Mastodon（https://o.ee/blog/what-is-mastodon/）、PeerTube、Lemmy、WriteFreely、Pixelfed、WordPress以及小型单用户服务器都保持着自身形态。这正是为什么我们C.IM上的Mastodon服务（https://o.ee/services/mastodon/）、P.LU上的PeerTube服务（https://o.ee/services/peertube/）以及R.NF上的Lemmy服务（https://o.ee/services/lemmy/）能够共享社交图谱而不沦为同一产品。 ActivityPub规范（https://www.w3.org/TR/activitypub/）描述了两层架构：客户端到服务器API，以及服务器到服务器联邦协议。实际上，服务器对服务器部分才是多数联邦宇宙运营者感知到的核心机制。行为体拥有收件箱与发件箱。服务器将活动投递至远程收件箱。其他服务器通过URL获取行为体文档、对象和集合。 这个模型几乎朴素得令人发指。活动就是一个句子：主语、动词、宾语。爱丽丝点赞了文章。鲍勃关注了爱丽丝。某台服务器创建了一条笔记。有人转发了一条帖子。网络中传输的往往是描述内容的语句，而不仅仅是内容本身。 这种区分使ActivityPub具备社交属性。内容同步协议可以传输文章和图片，而社交协议还必须传输回应、关注、屏蔽、分享、撤销操作，以及赋予这些行为意义的语境。 Prodromou最有趣的历史插曲是：活动概念可追溯至1930年代苏联活动理论，与心理学家阿列克谢·列昂季耶夫相关，后来经过用户体验研究领域徘徊，最终融入Activity Streams。让联邦宇宙运行在改造过的马克思主义心理学基础上，听起来像是委员会集体创作的讽刺文学。协议概念很少纯粹源于第一性原理，它们往往是从前人留下的工具库中拖拽而来。 传输层甚至更缺乏新意。ActivityPub使用HTTP协议。通过GET行为体URL了解该行为体。向收件箱POST活动以实现投递。规范概述（https://www.w3.org/TR/activitypub/#Overview）直言不讳地指出：收件箱和发件箱就是URL，联邦化通常通过服务器向其他服务器的收件箱发送消息实现。 即便是我们熟悉的`用户@域名`句柄也非ActivityPub核心特性。它通过WebFinger（一种现代互联网身份查询机制）实现。协议需要标识符，人类偏爱句柄是因为`[email protected]`比完整的行为体URL更适合放入搜索框。 这就是ActivityPub得以普及的原因。类JSON对象、HTTP GET、HTTP POST、URL、集合、行为体、收件箱、发件箱。这些技术毫无炫目之处。枯燥意味着可实现。 ## 技术债务不那么迷人 枯燥的协议同样会积累奇怪的债务。ActivityPub在认证方面就存在典型问题。 联邦宇宙普遍使用HTTP Signatures进行服务器间请求认证。尴尬之处在于具体使用哪种HTTP Signatures。现有联邦宇宙生态围绕旧版draft-cavage-http-signatures-12（https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12）发展起来，这份互联网草案现已过期归档。IETF后续发布的RFC 9421 HTTP Message Signatures（https://www.rfc-editor.org/rfc/rfc9421.html）（2024年2月发布）采用了不同设计。 最小共识演进在实践中往往如此：某份草案已足够实用，开发者开始实施，网络不断扩张，而最终标准发布时却采用不同形态。任何人无法通过对着服务器日志高喊“规范如此”来解决这个问题。 安全性存在另一个短板。ActivityPub具有寻址功能。`to`字段可指定活动目标的行为体或集合。服务器仅向指定接收者投递内容，并可在用户获取私密对象时验证授权。ActivityPub规范明确允许服务器要求授权，当请求不应访问目标对象时返回403或404状态码。 这赋予了联邦宇宙访问控制模型，但并未提供端到端加密。 内容通常以明文形式存储在托管服务器上。拥有数据库或文件系统访问权限的管理员可以读取服务器存储的所有内容。若运营者疏忽大意，备份、对象存储、日志、全文索引和搜索管道都可能扩大实际的信任边界。 对于服务器管理员和自托管者而言，这条运营真理值得刻在墙上：服务器实例就是信任边界。 运行自己的服务器可以将该边界缩小到你能控制的基础设施。选择他人的服务器意味着选择其运营者、安全实践、备份习惯、事件响应能力及其判断力。这正是缺乏端到端加密的联邦发布系统所带来的直接后果。 ## 治理是协议的重要维度 默认开放听起来很美好，直到滥用者带着可用DNS记录登场。 ActivityPub允许任何人将兼容服务器接入网络。联邦宇宙没有专门部门需要新实例申请许可证。这种开放性至关重要，这也是断开连接（defederation）机制存在的原因。 断开连接是粗糙世界中的粗糙防御机制：一台服务器屏蔽另一台服务器。联邦宇宙没有总统。屏蔽行为发生在本地，有时通过共享屏蔽列表、公开警告、私密管理频道和社区记忆进行协调。明显的滥用可能引发快速级联反应。模糊案例则变得缓慢、政治化且充满人性温度。 这正是最小可行共识不再足够的时刻。协议可以定义如何投递`Create`活动，却无法决定哪个社区应该接纳一个审核薄弱、存在敌对用户、垃圾信息泛滥或持有不同言论观念的服务器。 标准制定过程也存在类似张力。W3C共识推进缓慢，因为其要求共同前进。当目标是互操作性而非速度时这很有效，但当既有用户规模已具规模时，难度就会增加。 Prodromou在问答环节清晰阐述了这个问题：ActivityPub仍有创新空间，但已有数百个实现和数千万用户，其社交图谱不应因彻底重写而被破坏。每一项改进都必须与现有软件协商。 甚至网络相关术语都承载着治理历史。“社交网络”与“联邦宇宙”在技术层面关系密切，有时近乎同义词。“联邦宇宙”还承载着2017至2022年浪潮的身份认同：自由软件、开放标准、LGBTQ社群、注重安全的社群、左翼政治、无政府主义政治，以及为对抗大型平台背叛而形成的强烈“我们”意识。 这种文化记忆影响着协议采纳。Bluesky可通过Bridgy Fed桥接。从某个视角看，桥接的Bluesky账号可能被视为联邦宇宙的一部分；从另一视角看，同样的桥接可能被视为出现在大气层中的ActivityPub账号。 ## 胜利条件令人不适 当被问及“ActivityPub何时才算胜利”时，Prodromou的答案故意让联邦宇宙部分群体感到不安。 胜利不仅仅是千个温馨的小实例——每个都具备良好的本地规范和勉强覆盖对象存储费用的捐赠页面。那样的世界固然有价值，却无法改变互联网的默认假设。 他的胜利条件是两到三个亿级用户商业网络通过ActivityPub实现联邦。想象Threads加上另一个大型网络如LinkedIn或Snap。届时，小型独立服务器仍能作为对等节点参与巨人同在的网络。 大型商业平台加入ActivityPub既是对标准的验证，也是对维系该标准文化的威胁。如果开放协议足够强大，大型平台将成为参与者；如果它很脆弱，这些平台就会变成引力阱。 Prodromou还指出中国大型社交网络的机遇：数亿用户大多与全球社交网络隔绝，可能通过开放协议以自身方式实现互联。ActivityPub的抱负不仅是成为更友好的微博客俱乐部，而是社交软件的连接组织。 历史警示来自1990年代末的互联网。动态网页内容本可能走向Java小程序（受Sun公司控制）或ActiveX（受Microsoft控制）。枯燥的外围路径则是JavaScript。经过多年阵痛与标准制定，开放选项才成为默认选择。 联邦宇宙不应假定自己能自动获得同样圆满结局。大型平台可能带来专有“解决方案”涵盖身份认证、可迁移性、搜索、排名、支付、审核、信任或引用帖子，然后试图将部署规模转化为标准话语权。开放方案必须先行实现。 ## ActivityPub的下一次修订应波澜不惊 2026年1月15日，W3C组建新的社交网络工作组（https://www.w3.org/groups/wg/social/），由Darius Kazemi担任主席。现行章程（https://www.w3.org/2026/01/social-web-wg-charter.html）持续至2028年1月31日，涵盖ActivityPub、Activity Streams、Activity Vocabulary、WebSub、Micropub、Linked Data Notifications、Webmention及相关注释的维护工作。 对ActivityPub运营者而言，最近的里程碑目标被刻意设定得非常基础。章程列出2026年第三季度将完成ActivityPub、Activity Streams和Activity Vocabulary文档的更新。Prodromou将ActivityPub工作描述为向后兼容且主要属于编辑性质：澄清未充分规范的领域，记录现有实现已依赖的特性，使标准更易于实施且不破坏现有网络。 当前ActivityPub推荐标准虽稳定，但毕竟是2018年文档，带有那个时代的假设与缺失。常见的联邦宇宙内容类型和行为模式常分散于ActivityStreams词汇表、实施实践、FEP项目（功能增强提案）、项目特定扩展及管理员经验中。将部分实践转化为更清晰文本的维护性修订，正是运营者通常在更少出现莫名故障后才会注意到的同类工作。 同一章程将LOLA（https://swicg.github.io/activitypub-data-portability/lola）列为暂定交付成果，工作组可能将其采纳为推荐轨道规范，具体取决于孵化进度、实施者兴趣和小组共识。LOLA是一项允许用户按需在ActivityPub服务器间迁移在线账户的提案。草案涵盖内容复制、关注关系迁移、关注者通知、重定向，以及当服务器请求用户账户数据时涉及的信任决策。 可迁移性是枯燥协议必须保护用户免受枯燥锁定的领域。若离开服务器意味着丢失帖子、关注者、互动、媒体资源和社交语境，联邦宇宙不过是用更多域名重现了同样的陷阱。 维护性修订完成后，讨论可转向最终的ActivityPub 2.0。合适的模式可能更像HTTP演进而非颠覆性更新：旧版本持续运行，同时能力对等的节点协商更佳行为。向后兼容性正是社交网络避免将自身图谱一分为二的方式。 前方艰巨的工程任务并非让ActivityPub变得更聪明。聪明的协议容易令人赞赏却难以部署。ActivityPub之所以成功，是因为它让联邦化感觉像普通的Web管道作业。现在网络正扩展到那些更不平凡的领域：签名、隐私、审核、可迁移性、商业规模以及负载下的标准治理。 下一阶段应保持机制枯燥，而政治、经济和用户数量则不再微不足道。 ## 观看演讲 FediForum的录像值得观看，因为那些笑话让架构更易铭记。