activitypub.rocks 暂未发现付费内容

ActivityPub Rocks! 汇总了多个开发者讨论入口和标准化工作渠道。如果你要讨论实现细节、跟进协议演进或关注社区动态，可以从下面几类渠道入手：支持 ActivityPub 的 Discourse 与 NodeBB 论坛、Matrix 聊天室、IRC 的 #social 频道，以及负责持续标准化工作的 W3C 社区组 SocialCG。想先了解协议本身，可参考站上列出的《ActivityPub 实现者指南》和 ActivityPub.academy 交互式探索环境。

开发者讨论渠道

ActivityPub Rocks! 列出了以下开发者讨论场所：

论坛和聊天各有分工：需要留下记录、方便后来者检索的问题，发在 Discourse 或 NodeBB 更合适；需要即时来回确认的细节，用 Matrix 或 IRC 更快。

标准化工作：SocialCG

Ongoing standardization work 部分指向 SocialCG——W3C 社区组（W3C Community Group），负责推进联邦社交网络（federated social web）相关标准，包括 ActivityPub 的持续演进。

ActivityPub 本身是 W3C 推荐标准（W3C recommended standard），由 W3C Social Web Working Group 发布，基于 ActivityStreams 2.0 数据格式，提供客户端到服务器的 API（创建、更新、删除内容）以及联邦服务器到服务器的 API（投递通知、订阅内容）。SocialCG 是这一标准后续工作的社区组入口，关注协议修订和生态推进的开发者应从这里跟进。

活动与新闻

• Open Social Web Events：由 FediForum 整理的活动列表，用于关注开放社交网络相关的会议与聚会。
• Connected Places：关于开放社交网络的新闻通讯（newsletter）。

这两类渠道适合不想参与日常讨论、但希望定期了解社区动向的开发者。

先补基础再参与讨论

如果还没读过协议本身，直接进讨论渠道容易跟不上上下文。ActivityPub Rocks! 建议先读：

• 最新发布版本与最新编辑草案（Latest published version / Latest editor's draft）
• ActivityPub 实现者指南（Guide for new ActivityPub implementers）：社区编辑、非官方，但实用
• ActivityPub.academy：一个改造过的 Mastodon 实例，用于交互式探索协议
• 理解完整技术栈还需了解 WebFinger、HTTP Signatures 和 ActivityPub 中的数据可移植性（Data Portability）

另外，Evan Prodromou 的 O'Reilly 书籍、Sebastian Jambor 的博客《Understanding ActivityPub》、Eugen Rochko（Mastodon 项目）关于实现 ActivityPub inbox 的博客，以及 FediDevs.org 的开发者文档，都是站上列出的入门材料。

实现与测试资源

参与讨论时经常需要对照实际实现和数据：

• FediDB、Fediverse Observer、The Federation：Fediverse 网络统计数据
• Fedify：TypeScript 的 ActivityPub 服务器框架
• activitypub-testing：实现指南
• FediTest：测试分布式、异构系统与复杂协议（如 Fediverse）
• BrowserPub：浏览 ActivityPub 与 fediverse 的工具
• httpsig.org：交互式试验 HTTP 签名（RFC 9421）

这些资源可以帮助你在提问或提交标准化意见前，先验证自己的实现行为是否符合预期。

ActivityPub Rocks! 在“Implementations and usage”与“Testing”两个板块中，分别列出了用于观察联邦宇宙网络规模的统计站点，以及用于验证 ActivityPub 实现兼容性的测试工具。如果你想知道整个联邦宇宙现在有多大，看 FediDB、Fediverse Observer 或 The Federation；如果你想确认自己写的 ActivityPub 实现能不能和别人互通，用 activitypub-testing 的实现指南、FediTest 或 BrowserPub。两类工具的用途不同，下面按“看规模”和“验实现”分开说明。

联邦宇宙网络统计：三个可用的入口

这三个站点都被 ActivityPub Rocks! 归在“Implementations and usage”下，定位是 Fediverse Network Stats，也就是联邦宇宙的网络统计数据。

它们的共同点是提供联邦宇宙层面的规模数据，而不是针对某一个软件或某一个实例。实际使用时，建议把三者当作互相参照的来源：不同统计站点的采集方式和覆盖范围可能不同，单看一个数字容易产生偏差，交叉比对更稳妥。

需要说明的是，ActivityPub Rocks! 只给出了这些站点的名称和“Fediverse Network Stats”这一功能定位，并未列出具体指标口径或更新频率。如果你需要精确到某个时间点的数据，应直接访问对应站点确认。

ActivityPub 实现测试：验证兼容性的工具

ActivityPub Rocks! 的“Testing”板块列出三项，用途各有侧重。

activitypub-testing：实现指南

被标注为“Implementation Guide”，即面向实现者的指南。它适合在开发 ActivityPub 实现的过程中对照检查，确认自己的行为是否符合规范预期。如果你刚开始写一个 ActivityPub 服务端或客户端，可以把它当作实现阶段的参考清单。

FediTest：测试分布式异构系统

ActivityPub Rocks! 对它的描述是“Testing distributed, heterogeneous systems with complex protocols such as the Fediverse”。关键词是分布式、异构、复杂协议——联邦宇宙里不同软件、不同实例之间要互通，正是这种场景。FediTest 面向的是这类跨实现的兼容性测试，适合在实现基本可用之后，用来检验与其他实现的互操作表现。

BrowserPub：浏览与探索

被描述为“A browser for exploring ActivityPub and the fediverse”。它的作用偏向观察和探索：用浏览的方式查看 ActivityPub 内容和联邦宇宙中的对象。对于调试和理解协议实际传输了什么，这类浏览工具比纯读规范更直观。

怎么选：看规模还是验实现

判断标准很简单：

• 想了解网络整体情况 → 用 FediDB、Fediverse Observer、The Federation，三者互为参照。
• 正在写实现，想对照规范 → 用 activitypub-testing 的实现指南。
• 实现已能跑，想验证跨实现互通 → 用 FediTest。
• 想直观查看 ActivityPub 内容和联邦宇宙对象 → 用 BrowserPub。

统计工具回答“网络有多大”，测试工具回答“我的实现对不对、能不能互通”。两者不互相替代，按当前任务选即可。

这些工具之外，同一页面还提供了什么

ActivityPub Rocks! 在测试与统计之外，还列出了开发者讨论渠道（Discourse、NodeBB 论坛、Matrix、IRC #social）、实现与使用资源、文档（如新实现者指南、Evan Prodromou 的 O'Reilly 书籍、Eugen Rochko 关于实现 ActivityPub inbox 的博客）、交互式探索（ActivityPub.academy、httpsig.org）、库（Fedify，TypeScript）、新闻通讯（Connected Places）以及标准化工作（SocialCG）。如果你的目标从“看规模”或“测实现”扩展到参与讨论或系统学习，可以从这些入口继续。

ActivityPub Rocks! 是 ActivityPub 协议的官方信息聚合与导航站点，主要面向想了解或实现该协议的开发者与爱好者。它本身不是社交平台，也不提供托管服务，而是把规范文档、实现指南、开发者社区、测试工具、新闻与活动等资源集中在一处，方便你按需跳转。如果你刚接触 ActivityPub，想弄清它是什么、从哪里读规范、去哪里找人讨论，这个站点适合作为起点。

网站定位：围绕 ActivityPub 的资源导航

站点的核心作用是“指路”，而不是“造轮子”。它把分散在 W3C、社区论坛、代码仓库和博客里的资料整理成几类入口，覆盖从入门到实现的全过程。页面开篇就点明了动机：怀念 Web 曾经作为去中心化网络的日子，希望打破少数“围墙花园”对社交内容的锁定，而 ActivityPub 正是为此而生。

ActivityPub 协议本身是什么

ActivityPub 是一个基于 ActivityStreams 2.0 数据格式的去中心化社交网络协议，由 W3C Social Web Working Group 发布，属于 W3C 正式推荐标准。它提供两套 API：

• 客户端到服务器 API：用于创建、更新和删除内容。
• 联邦服务器到服务器 API：用于投递通知和订阅内容。

这两套 API 是理解整个协议栈的基础。站点还特别提醒，要理解常见实现中的完整 ActivityPub 栈，还应一并阅读 WebFinger、HTTP Signatures 以及 ActivityPub 中的数据可移植性（Data Portability）相关内容。

站点涵盖哪些内容

适合谁用

• 刚入门的开发者：从“新实现者指南”和交互探索工具入手，先建立直观认识。
• 正在实现协议的人：查规范、找库（如 Fedify）、用测试工具验证互操作性。
• 关注联邦宇宙生态的人：通过 FediDB 等查看网络统计，通过通讯和活动跟进社区动态。
• 想参与标准化的人：加入 SocialCG 社区组和相关讨论频道。

使用建议

站点本身不收费，也未提及登录限制，但其中的外部资源（如书籍、部分工具）可能有各自的使用条件，需以对应页面说明为准。建议的阅读顺序是：先看规范与协议栈相关文章建立概念，再用 ActivityPub.academy 之类工具动手体验，最后根据开发语言选择库并借助测试工具验证。遇到实现细节问题，直接去论坛或聊天频道提问，通常比独自摸索更快。

ActivityPub 是一个去中心化社交网络协议，基于 ActivityStreams 2.0 数据格式，由 W3C 社交 Web 工作组发布，是 W3C 官方推荐标准。它要解决的问题是：让社交网络重新变成可互通的开放网络，而不是各自封闭的“围墙花园”。如果你在做联邦宇宙（Fediverse）相关的开发、选型或内容迁移，理解它的两套 API 和联邦机制是前提。

它由哪两部分组成

ActivityPub 定义了两套 API，分别解决不同层面的问题：

前者面向“用户与自己的服务器”，后者面向“服务器与服务器”。正是后者让不同站点之间可以互相关注、互相看到内容，而不需要共用同一个中心平台。

为什么说它是“去中心化”的

传统中心化平台的模式是：所有账号、内容和关系都锁在同一个平台内，跨平台互通几乎不可能。ActivityPub 的做法是让每个服务器都能独立运行，再通过联邦 API 互相投递和订阅。

这意味着：

• 内容不依赖单一公司或单一服务器存活；
• 不同实现之间可以互通，只要都遵循同一协议；
• 用户可以选择不同的服务器，同时仍能关注其他服务器上的账号。

网站原文用“围墙花园”来描述中心化平台，并明确提出 ActivityPub 的目标是让 Web 重新成为“世界上最伟大的去中心化网络”。这不是营销口号，而是协议设计层面的取向。

它和 Mastodon、联邦宇宙是什么关系

ActivityPub 是协议，Mastodon 等平台是它的实现之一。联邦宇宙（Fediverse）指的是所有通过这类协议互联的服务器网络。也就是说，Mastodon 只是众多实现中的一个，ActivityPub 本身不绑定任何特定产品。

网站还列出了与 ActivityPub 常一起实现的配套技术，理解完整技术栈时需要一并阅读：

• ActivityPub 与 WebFinger
• ActivityPub 与 HTTP Signatures
• ActivityPub 中的数据可移植性

想深入可以看哪些入口

网站为不同角色提供了资源：

• 开发者讨论：Discourse、NodeBB 论坛，Matrix 聊天，IRC 频道 #social
• 实现与网络数据：FediDB、Fediverse Observer、The Federation
• 文档：新实现者指南（社区编辑、非官方但实用）、Evan Prodromou 的 O'Reilly 书籍、ActivityPub Primer Wiki、Sebastian Jambor 的博客、Eugen Rochko 关于实现 ActivityPub inbox 的文章、FediDevs.org
• 交互探索：ActivityPub.academy（改造过的 Mastodon 实例，用于交互式协议探索）、httpsig.org（交互式试验 HTTP 签名 RFC 9421）
• 库与测试：Fedify（TypeScript 的 ActivityPub 服务器框架）、activitypub-testing 实现指南、FediTest、BrowserPub
• 动态与活动：Connected Places 通讯、FediForum 整理的 Open Social Web Events
• 标准化工作：SocialCG，W3C 社区组，推进联邦社交 Web

一句话判断是否适合你

如果你希望内容、账号和社交关系不被单一平台锁定，并且愿意接受“多服务器互通”的模型，ActivityPub 就是这套模型背后的协议标准。如果你的场景只需要单平台内的功能，不涉及跨站互通，那么直接使用中心化方案可能更简单。

ActivityPub Rocks! 是 ActivityPub 协议的官方信息聚合站，面向正在或准备实现该协议的开发者，把规范入口、配套主题、社区讨论渠道、文档、交互式探索工具、开发库和测试资源集中在一处。如果你要动手实现一个 ActivityPub 服务端或客户端，可以从这个站点出发，按“先读规范与配套主题 → 再看社区文档 → 用交互工具验证 → 选库与测试”的顺序推进。它本身不提供托管服务或付费产品，价值在于索引和指路。

先理解协议本身

ActivityPub 是一个基于 ActivityStreams 2.0 数据格式的去中心化社交网络协议，由 W3C Social Web Working Group 发布，属于 W3C 正式推荐标准。它包含两套 API：

• 客户端到服务端 API：用于创建、更新和删除内容。
• 联邦式服务端到服务端 API：用于投递通知和订阅内容。

站点直接给出两个规范入口：最新发布版本（Latest published version）和最新编辑草案（Latest editor's draft）。实现时以发布版本为准，草案用于了解演进方向。

配套主题：实现前必须补齐的三块

站点明确提示，要理解通常实现中的完整 ActivityPub 技术栈，还需要读以下内容：

这三项不是可选项。只读协议主体而跳过它们，联邦通信往往在“找不到对方账号”或“请求验签失败”处卡住。

面向新实现者的文档

站点列出的文档资源包括：

• Guide for new ActivityPub implementers：社区编辑的非官方指南，面向新实现者，实用性强。
• Evan Prodromou: ActivityPub：O'Reilly 出版的书籍，作者是协议相关工作的核心参与者之一。
• ActivityPub Primer：社区编辑的 Wiki 入门材料。
• Understanding ActivityPub：Sebastian Jambor 的博客文章。
• How to make friends and verify requests. Implementing an ActivityPub inbox：Mastodon 项目 Eugen Rochko 的博客文章，聚焦 inbox 实现与请求验证。
• FediDevs.org：开发者文档与社区。

建议顺序：先用 Primer 或 Understanding ActivityPub 建立整体模型，再读新实现者指南补齐工程细节，inbox 那篇放在动手写接收端之前读。

交互式探索与测试

理解协议状态机最有效的方式之一是观察真实实例的行为：

• ActivityPub.academy：一个改造过的 Mastodon 实例，用于交互式探索协议。
• httpsig.org：交互式试用 HTTP 签名（RFC 9421）。
• BrowserPub：浏览 ActivityPub 与 fediverse 内容的浏览器工具。
• activitypub-testing：实现指南性质的测试资源。
• FediTest：面向 Fediverse 这类分布式异构系统的测试工具。

例如需要确认自己发出的活动对象是否符合预期时，可以先用 ActivityPub.academy 观察一个成熟实现的行为，再用 FediTest 或 activitypub-testing 对照检查。

开发库

站点列出的库中，Fedify 是一个 ActivityPub 服务端框架，提供 TypeScript 库。如果你的技术栈是 TypeScript，可以从它入手，避免从零实现签名、投递和 inbox 处理等重复工作。

社区与动态

实现过程中遇到问题，站点给出这些渠道：

• 讨论论坛：基于 Discourse 和 NodeBB 的论坛，两者都支持 ActivityPub。
• 开发者聊天：Matrix。
• 开发者与标准化聊天：IRC 频道 #social。
• Fediverse 网络统计：FediDB、Fediverse Observer、The Federation，可用于了解生态规模与实例分布。
• 新闻：Connected Places 通讯，关注开放社交网络。
• 活动：Open Social Web Events，由 FediForum 整理。
• 标准化工作：SocialCG，W3C 社区组，推进联邦社交网络相关工作。

一条可执行的入门路径

1. 读 W3C 发布版规范，建立客户端到服务端、服务端到服务端两套 API 的基本认识。
2. 补齐 WebFinger、HTTP Signatures、数据可移植性三个配套主题。
3. 读新实现者指南与 inbox 实现文章，明确接收端要处理哪些验证与状态。
4. 用 ActivityPub.academy 和 httpsig.org 做交互式验证。
5. 选择 Fedify 等库搭建骨架，用 FediTest、activitypub-testing 做测试。
6. 遇到具体问题到 Discourse、NodeBB 论坛或 Matrix 频道提问。

站点内容以索引和链接为主，具体实现细节需要进入对应规范、文档或工具页面获取。