2026 年 6 月 19 日，React 核心团队成员、现任 Bluesky 开发者的 Dan Abramov 在其个人博客 overreacted.io 上发布了一篇文章：《There Are No Instances in atproto》。文章开篇直指一个反复出现的现象：每当 atproto 相关内容登上 Hacker News，评论区总有人追问”Bluesky 的实例在哪里”。Abramov 给出的回答是——这个问题本身就是一个范畴错误，atproto 里根本没有”实例”这个东西。
“实例”是 Mastodon 塑造的思维模型
Abramov 用一组渐进式的图示展开他的论证。他首先回溯到 RSS 的时代：每个作者拥有自己的博客（自托管或平台托管），Google Reader、Feedly 等聚合器从分散的博客中拉取内容，呈现为统一的阅读界面。在这个模型中，托管与聚合是两件彼此独立的事——博客数据存放在各自的服务器上，阅读器只是整个”博客圈”的一种投影。
随后他描述传统社交媒体的做法：把所有人装进同一个”盒子”里，由一个公司同时控制托管和应用。Facebook 既存你的帖子，也提供唯一的信息流。然后他剖析 Mastodon/ActivityPub 生态的去中心化路径：将那个”盒子”复制多份，每份称为一个”实例”。用户”属于”某个实例，身份形如 [email protected]；跨实例通信依赖实例之间的消息转发，即所谓”联邦”。实例既是托管方也是应用方，二者在架构层面被捆绑在一起。
atproto 采取了一条不同的路线。它回到 RSS 式分离逻辑：个人数据服务器（Personal Data Server，PDS）负责托管用户的签名仓库和密钥，独立的 AppView（应用视图）从所有 PDS 和 Relay（中继）中聚合数据并呈现给客户端。托管可以随时更换——Abramov 称自己在写文章当天就完成了托管迁移，全程仅遇到三四个 UX 瑕疵。应用同样可以自由选择或自行开发，Tangled、Semble 等第三方客户端完全不依赖 Bluesky 官方代码。
“如果 Bluesky 消失，网络还在吗？”
文章在 Lobsters 上引发了 59 条评论。获得 42 票的最高赞评论来自用户 orib，提出了一项核心质疑：“当人们问’实例在哪儿’时，他们实际上问的是：是否存在独立运营者？如果 Bluesky 这家公司消失了，网络还在不在？”
这条评论直指讨论的真正焦点。Abramov 的文章解释了 atproto 架构上为何不产生 Mastodon 式的实例概念，却回避了网络能否脱离 Bluesky PBC 独立存续的问题。
用户 ubernostrum（7 票）从设计意图的角度回应：Bluesky 从一开始追求的并非技术上的完全去中心化，而是”可信用退出”（credible exit）。他的分析指出，Mastodon 的 mastodon.social 拥有约 20% 的 Fediverse 用户，如果该实例被恶意接管，大量用户可能直接放弃 Mastodon，而非经历繁琐的迁移流程。Bluesky 的设计目标更具野心——如果公司变质，具备足够资源的一方可以在新域名上重建整个网络，携带完整的帖子历史与社交图谱，用户无需手动导入关注列表或逐一设置迁移。
但这一设想面临实际的追问。quasi_qua_quasi 指出，使用 foo.bsky.social 句柄的用户，其身份验证信息随着 Bluesky LLC 的消失而消失，无法完成迁移。ubernostrum 回应称，替换方可以将用户自动迁移至 myusername.bluesky2.whatever，使用自有域名的用户迁移更加顺畅。这一回应并未说服反对者——acquiescent 的质疑停留在”如何阻止他人冒领身份”这一层面，而讨论并未产生可操作的具体方案。
用户 goldstein 给出了一个量化观察：“99.99% 以上的用户仍然在 Bluesky Social PBC 的基础设施上。有人用多个段落讨论 mastodon.social 仅 20% 的 Fediverse 占比作为锚点，却不提 atproto 的这个数字是 99.99%。“即使第三方基础设施如 Blacksky 和 Northsky 在逐步发展，atproto 在系统性意义上仍然是 Bluesky。
PLC 目录：单一中心化瓶颈
技术讨论中最尖锐的争议围绕 PLC 目录服务展开。PLC（Public Ledger of Credentials）是 atproto 身份系统的支柱，以 did:plc 格式的标识符作为账户的真实身份——用户可更换的句柄只是附着于 DID 之上的别名。PLC 目录记录了每个 DID 的创建操作、密钥轮换、PDS 端点变更等完整历史。
用户 notjack 在评论中承认网络可以在 Bluesky 消失后存活，但补充了关键限制：“PLC 目录服务在切换上会比其他组件更复杂。“mort（33 票）对此的回击直接：“‘可以，除了这个难以切换的中心化服务’的同义词就是’不可以’。”
随后一系列评论揭示了 PLC 争议的层次：
- jcalabro 指出 PLC 目录正在移交给一家独立的瑞士协会，脱离 Bluesky PBC 的直接控制。
- mort 回复：移交并不能改变其中心化的本质——“如果有一个权威机构，所有人必须同意信任它，那就不叫去中心化。”
- easrng 补充了技术细节：任何人都可以镜像 PLC 目录，现有镜像如 plc.wtf 已经运行；操作本身经过密码学签名，目录无法伪造身份变更。唯一需要中心化协调的是 72 小时回滚窗口——在此期间目录运营方可以撤销操作。
- mort 的最终立场：即便目录的权限被刻意限制，“如果目标是构建去中心化社交平台，那它就是失败的。”
- easrng 的回应颇具意味：“那恰好不是 Bluesky 的目标。“这实际上将问题从”是否实现了去中心化”拉回到”去中心化是否是其目标”——两个不同的判断维度。
关于 PLC 目录安全性的更详细分析，Agent IO 在 2026 年 3 月发布的《Risks of DID:PLC》中进行了完整梳理。文章指出，任何人都可以验证 PLC 操作链的签名有效性，不需要中心化服务器来完成这项检查；但目录之所以具有权威性，是因为它提供了每个操作被接受时的时间戳——这是唯一需要信任目录的部分。如果目录运营方在 72 小时回滚窗口内恶意操作，理论上可以重写某段时间内的身份变更记录。
atproto 与 ActivityPub 的架构分歧
Lobsters 讨论中多次出现的另一个线索是 atproto 与 ActivityPub 的架构对比。User boramalper 推荐了两篇由 ActivityPub 联合作者 Christine Lemmer-Webber 撰写的经典分析文章，其中《How decentralized is Bluesky really?》对两种协议的差异做了系统阐述。
Lemmer-Webber 将二者分别描述为”消息传递”（message passing）架构与”共享堆”（shared heap）架构。ActivityPub 沿袭电子邮件和 XMPP 的传统：每个实例独立运行，跨实例交互通过定向消息传递完成，节点之间不存在共享的全局状态。这一模型使得实例自托管成本较低——GoToSocial 等轻量实现可以在低配 VPS 上运行——但在网络层面产生二次方复杂度的连接开销。
atproto 反其道而行：所有公开内容汇总到 Relay 层，形成全网的单一数据流；AppView 从 Relay 消费数据并为客户端构建定制化的信息视图。Lemmer-Webber 的分析指出这一架构在实际操作中对自托管者设置了极高的门槛。运行一个 Relay 需要数 TB 存储，AppView 同样需要复制其关注的全部 Lexicon 数据。这意味着在 atproto 中做”完整参与者”而非”仅运行 PDS”的成本远高于 ActivityPub 的实例自托管。
Abramov 的 RSS 类比也在 Lobsters 上受到审视。评论者 SpindleyQ（38 票）指出：“‘就像 RSS 一样，只不过中间有几个我没在示意图里画出来的巨型昂贵服务器’——这种说法有误导之嫌。ATProto 没有像桌面 RSS 阅读器那样直接与 PDS 通信的应用。如果它真像 RSS 那样工作，你直接用 RSS 就行了。“gcupc 进一步指出，示意图中的 “app” 实际指的是 AppView——它强制性地扮演了 Google Reader 的角色。
但 Lemmer-Webber 的分析也承认 Bluesky 取得了切实的成就：它在一个特定时间窗口内成功承接了大规模从 X/Twitter 出走的用户，完成了 Mastodon 未曾做到的规模化过渡，并提供了接近旧 Twitter 的体验。
事件的延续
Dan Abramov 的文章引发了持续发酵的讨论，暴露出一个根本性的分歧：用 Mastodon 的”实例数量”指标去衡量 atproto 的”去中心化程度”确实存在范畴错误，但 atproto 当前的网络拓扑——一个 PBC 运营的 PLC 目录、一个几乎全网依赖的 Relay 集群、一个占据绝大多数用户的官方 AppView——其中心化程度也无法被架构上的分离设计所抹消。
PLC 目录移交给瑞士协会是实体层面的去风险操作，但目录作为逻辑单点的事实并未改变。围绕 72 小时回滚窗口的设计选择反映出团队对一致性的优先考量高于去中心化，而这恰好与 Bluesky 追求的”可信用退出”目标一脉相承——让网络可以在必要时整体迁移，而非从一开始就以完全分布的方式运行。