从实用角度看,只有当用户能够在不丢失身份、数据和粉丝的前提下切换服务提供方时,一个社交网络才算真正去中心化。而 ActivityPub、AT Protocol 和 Solid 各自只通过了这项测试的其中一部分。
选一个服务器、关注几个账号,这是最简单的部分。但随这些网络而来的术语(PDS、relay、AppView、Pod、WebID)会迅速堆积,而在你真正想要迁移之前,这些词汇似乎都无关紧要。
本文是对当今去中心化网络中三个关键协议的现状报告。文章解释了每个协议如何建模身份、数据和受众,说明各自在采用度和规范层面所处的阶段,在统计数据中将注册账号与活跃用户分开呈现,并以一个你可以在一个下午内跑起来的服务作结。
核心要点
- 在 ActivityPub 上,诸如 @user@instance.example 这样的账号标识归属于实例(instance),因此若账号在其服务器关停前未完成迁移,就无法在任何其他地方恢复。
- 在 AT Protocol 上,身份是一个不归任何服务器所有的 DID,账号可以在不同的 Personal Data Server 之间迁移而 DID 保持不变,不过迁移目前仍以 CLI 驱动为主,而非应用内流程。
- Solid Protocol 是 W3C Community Group 草案(v0.11.0,2024 年 5 月),并非 W3C 标准,且此后未发布任何新版本。
- Bluesky 的 2025 年透明度报告统计截至 2025 年底共有 4141 万个账号,但未披露月活跃用户数;第三方追踪工具给出的 Mastodon 数据约为 1000 万注册账号,月活跃用户不足 100 万。
- Bluesky 的自定义 feed 是一个 HTTP 服务,返回一个有序的帖子 URI 列表;由 AppView 负责填充内容,因此 feed 本身从不存储帖子内容。
去中心化在实践中意味着什么?
去中心化意味着你可以离开当前托管你账号的一方,并带着三样完好无损的东西抵达别处:你的身份(别人认识你的名字以及背后的凭证)、你的数据(帖子、媒体、关注关系、设置)以及你的受众(关注你、并持续接收你所发布内容的人)。三者中任何一项丢失,这次切换就变成了一次附带额外步骤的重新开始。
下文中每个协议都是按这项测试来衡量的,而不是看存在多少台服务器或软件由谁编写。服务器数量说明的是冗余程度。这项三要素测试说明的则是锁定程度。
ActivityPub 如何在实例之间联邦?
ActivityPub 自 2018 年 1 月 23 日起成为 W3C Recommendation,其联邦方式是让每台服务器将用户的活动(activity)直接投递到托管该用户粉丝的各台服务器的收件箱(inbox)。每个用户都是一个 actor,拥有 inbox 和 outbox;发布内容即写入你的 outbox,你的服务器再将该活动 POST 到每个粉丝的 inbox。这里没有中心索引,只有服务器之间互相推送 JSON。
Mastodon、Pixelfed、Lemmy 和 PeerTube 都实现了该协议,这也是为什么一个 Mastodon 账号可以关注 PeerTube 频道或 Lemmy 社区。
身份正是这项测试失败的地方。诸如 @user@instance.example 这样的账号标识归属于实例,因此若账号在其服务器关停前未完成迁移,就无法在任何其他地方恢复。Mastodon 的账号迁移会发送一个 Move 活动,把粉丝转移到新账号上,但文档明确指出你发布过的一切内容都会留在原地,而且你可以下载的归档文件无法导入到另一个 Mastodon 账号中。按测试打分:在有计划的迁移中受众得以保留,数据以导出文件的形式部分保留,身份则完全无法保留。
AT Protocol:可携带的身份,集中化的基础设施
在 AT Protocol 上,用户身份是一个不归任何服务器所有的 DID,其帖子、关注关系和个人资料存放在 Personal Data Server(PDS)中,而 PDS 可以迁移到不同的托管方而 DID 保持不变。PDS 之上是 relay,它们爬取每一个 PDS 并输出一条 firehose;再往上是 AppView,负责将该 firehose 索引成客户端所渲染的产品。相关规范由 Bluesky Social PBC 发布和维护。
可携带性是有限度的。官方账号迁移指南将这些步骤视为协议本体之外、日后可能变化的内容,并引导你使用 goat CLI 或社区工具,而非应用内流程。Bluesky 协议工程师 Bryan Newbold 在 2025 年 10 月写道,账号迁移自 2025 年初起就已在正式网络上可用,但仍是开发者才能完成的工作,并且 Bluesky 运营的 PDS 主机不接受账号迁入。
第二个限定条件涉及运营层面。Bluesky 的 2025 年透明度报告称,公司持有的账号数量超过其他任何一方,并且大多数人都在此注册,网络的其余部分则分散在数千个 Personal Data Server 上,其中大多数由他人运行。没有官方数字量化有多大比例的网络流量经过 Bluesky 运营的 relay 和 AppView。批评者认为,独立 PDS 托管方和社区基础设施项目仍然依赖 Bluesky 运营的核心服务,部分人据此断定该网络在实践中并非去中心化;但这是一种判断,而非测量结果。按测试打分:身份和数据在设计上可在更换服务提供方后保留,粉丝也会跟随而来,因为关注记录引用的是 DID;但 PDS 之上的各层基本仍掌握在一家公司手中。
Solid:没有消费级市场的数据 Pod
Solid 将用户数据存储在由用户自己控制的 Pod 中,并要求每个应用都必须请求访问权限。WebID 用于标识个人,Pod 是持有 RDF 资源的 HTTP 服务器,应用在授权规则允许后读写这些资源。在”更换服务提供方”这项测试上,Solid 是三者中设计最干净的:身份、数据和访问规则全都随用户而在,应用只是一个客户端。
但采用度与设计并不匹配。Solid Protocol 是 W3C Community Group 草案(v0.11.0,2024 年 5 月 12 日),并非 W3C 标准,而TR 索引显示此后未发布任何新版本;此前的版本是 0.9.0(2021 年 12 月)和 0.10.0(2022 年 12 月),0.12.0 的工作仍处于编辑草案阶段。应用所依赖的扩展规范——WebID Profile、Type Indexes 和 Application Interoperability——仍然是草案,而且规范允许两套互不兼容的授权系统 WAC 和 ACP 并存,服务器可任选其一实现。工具链和文档都落后于另外两个协议。
现实中的阻碍在于”去哪儿注册”。solidproject.org 列出了约十五个托管 pod 服务,大多规模较小或属实验性质;而由 Tim Berners-Lee 联合创办的公司 Inrupt 如今主要面向企业推广企业级钱包基础设施。Solid 应用开发者 Noel De Martin 在 2024 年撰文,将缺失的消费级 pod 市场列为阻碍 Solid 发展的最大因素:要求某人”用 Solid 登录”,就等于先把他打发去寻找一个服务提供方,而大多数人正是在这一步止步。
| ActivityPub | AT Protocol | Solid | |
|---|---|---|---|
| 标准组织 | W3C Recommendation(2018) | Bluesky Social PBC | W3C Solid Community Group 草案 |
| 身份对象 | 绑定实例的 handle | DID | WebID |
| 数据存放位置 | 你的实例 | 你的 PDS | 你的 Pod |
| 更换服务提供方后保留 | 粉丝(仅限有计划的迁移) | 身份、数据、粉丝 | 身份、数据、访问规则 |
| 最大部署 | Mastodon | Bluesky | 无规模化消费级部署 |
Bluesky 和 Mastodon 各有多少用户?
Bluesky 的 2025 年透明度报告(2026 年 1 月 29 日)统计,截至 2025 年底,Bluesky 托管的 PDS 与独立 PDS 合计共有 4141 万个账号,较此前的 2594 万有所增长;公司会跟踪但不公布月活跃用户数字。该报告按每 1000 名月活跃用户对其审核数据做了归一化处理,却未说明分母是多少。
Mastodon 确实在 joinmastodon.org 的服务器页面上发布了自己的全网数字,而通过轮询实例统计 API 的第三方追踪工具也会发布各自的数据。这些数字并不一致。TechCrunch 于 2026 年 2 月报道称,Mastodon 自家站点给出的月活跃用户约为 78.5 万,而各家追踪工具给出的区间则从约 75 万到 100 万不等,取决于你问的是哪一家。这些追踪工具给出的注册账号数约为 1000 万,分布在大约 10000 台服务器上,不过各追踪工具之间的总数差异可达百万以上,具体取决于每家如何处理已经停止活动的服务器。
| 网络 | 注册账号 | 月活跃用户 | 来源与日期 |
|---|---|---|---|
| Bluesky | 4141 万(2025 年底) | 未公布 | Bluesky 2025 年透明度报告,2026 年 1 月 |
| Mastodon | 约 1000 万,因追踪工具而异 | Mastodon 自家页面约 78.5 万,各追踪工具 75 万至 100 万(2026 年 2 月) | Mastodon 服务器页面、第三方追踪工具 |
| Solid | 无公开数据 | 无公开数据 | 无 |
在 Mastodon 上,注册数与活跃数相差一个数量级,而 Bluesky 的这一比例尚不可知。把一个网络的注册数与另一个网络的活跃数放在一起比较,比较的是两种不同的量。
基于 ActivityPub、Solid 和 Bluesky 能构建什么?
这三个协议都基于纯粹的 HTTP,因此只用一个终端就足以检视它们:
# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon
# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/cardWebFinger 是 RFC 7033,属于 Mastodon 生态的约定,并非 ActivityPub 本身的一部分。Solid 服务器在收到请求时必须以 Turtle 或 JSON-LD 形式提供 RDF 资源。
最容易上手的项目是 Bluesky 自定义 feed。Bluesky 自定义 feed 是一个 HTTP 服务,返回一个有序的帖子 URI 列表;AppView 会自行抓取并渲染这些帖子,因此 feed 服务从不需要存储或提供帖子内容。需要实现两个 XRPC 路由,getFeedSkeleton lexicon 定义了参数(feed、最大为 100 的 limit、cursor)以及 UnknownFeed 错误:
// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';
const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';
// A real generator fills this from a firehose consumer or a database.
const POSTS = [
'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];
const json = (res, status, body) => {
res.writeHead(status, { 'content-type': 'application/json' });
res.end(JSON.stringify(body));
};
createServer((req, res) => {
const { pathname, searchParams } = new URL(req.url, 'http://localhost');
if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
}
if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
if (searchParams.get('feed') !== FEED_URI) {
return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
}
// Requests may carry a JWT signed by the user's key. A feed that is
// identical for every user can ignore it, as this one does.
const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
const start = Number(searchParams.get('cursor') ?? 0);
const page = POSTS.slice(start, start + limit);
const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
}
json(res, 404, { error: 'NotFound' });
}).listen(3000);cursor 对 AppView 来说是不透明的,完全由你自己定义;对固定列表而言,一个位置索引就足够了,而一旦帖子来自实时索引,官方教程则建议使用”时间戳 + CID”的复合 cursor。要正式上线,你需要通过 HTTPS 部署,发布一个指向该主机的 DID 文档(starter kit 默认将其配置为 did:web),并运行其中的 publishFeedGen.ts 脚本,在你自己的 repo 中创建 app.bsky.feed.generator 记录。此后,该 feed 就会像其他任何 feed 一样出现在 Bluesky 应用中。
现状总结
按”更换服务提供方”这项测试来衡量:ActivityPub 能带走粉丝但带不走身份;AT Protocol 在纸面上三者皆可带走,但网络的大部分流量仍然经由一家公司的 relay 和 AppView;Solid 原则上什么都能带走,却没有一个消费级市场来承载它。选择那个你能接受其失效模式的协议,然后花一个周末去做上面那个 feed 生成器:这是从”阅读关于去中心化网络的文章”到”亲手运行它的一部分”之间最短的一条路。
常见问题
Bluesky 和 Mastodon 的用户可以互相关注吗?
无法原生实现:ActivityPub 与 AT Protocol 并不互通,因此跨网络关注需要通过桥接服务。由非营利组织 A New Social 运营的 Bridgy Fed 采用选择加入机制:Bluesky 用户关注 @ap.brid.gy,fediverse 用户关注 @bsky.brid.gy@bsky.brid.gy。被桥接的账号在 Bluesky 上显示为 user.instance.ap.brid.gy,在 fediverse 中显示为 handle@bsky.brid.gy。只有完全公开的帖子才会被桥接,且超过 300 字符的 fediverse 帖子在 Bluesky 上会被截断。
AT Protocol 中 did:plc 和 did:web 有什么区别?
AT Protocol 仅支持两种 DID 方法。did:plc 由 Bluesky Social PBC 开发,在 PLC 目录中注册标识符,支持密钥轮换与恢复,也是官方 PDS 安装程序为新账号创建的方法。did:web 则从你所控制的主机名派生标识符,仅允许主机名级别的标识符而不支持路径,且一旦丢失域名便无法恢复,因此更适合 feed 生成器之类的服务。
我可以在不自建 PDS 的情况下,用自己的域名作为 Bluesky handle 吗?
可以。handle 是一个与你的 DID 双向关联的 DNS 主机名,这一关联与你的数据存放在哪个 PDS 无关。将 DID 发布在以下两处之一:一条名为 _atproto.yourdomain 的 DNS TXT 记录,取值为 did= 加上你的完整 DID;或在 https://yourdomain/.well-known/atproto-did 提供一个纯文本响应。规范建议个人使用 DNS 方法,HTTPS 方法则面向大型服务。
如果我自建 Personal Data Server,还能继续使用 Bluesky 应用吗?
可以。官方 PDS 以 Docker 镜像形式发布,需部署在具有公网 IPv4 地址、通配符 DNS 记录并开放 80 和 443 端口的 VPS 上;Bluesky 建议为 1 至 20 名用户配置 1 GB 内存和 20 GB 存储。在应用中输入你的 PDS URL 即可登录。默认配置仍指向 Bluesky 的 AppView、relay 和 PLC 目录,因此该 PDS 在数据层之上仍依赖 Bluesky 运营的服务。
