假设现在是上午十点。你打开 Bluesky，首页一片空白。API 返回 503，PDS 连接超时，AppView 加载转圈转了五分钟。
这只是一次普通的宕机，Bluesky 团队会在几小时内修复。但把时针拨到更远——假设 Bluesky PBC 被收购了，它的新东家不喜欢开源协议，或者干脆在某个周二决定关掉服务器。
你的数据还在吗？你能带着粉丝和帖子跑去另一个地方吗？
这个问题，比「有没有实例」难回答得多。
一个框架引发的范畴错误
2026 年 6 月 19 日，React 核心团队成员 Dan Abramov 发表了一篇引发争议的文章：《There Are No Instances in atproto》。读完之后笔者的第一反应是：他的核心论点确实站得住——用 Mastodon 的「实例」框架去理解 atproto，是范畴错误。
Abramov 画了几张图。第一张是 RSS 时代：Alice 和 Bob 各自拥有博客，Google Reader 和 Feedly 从中聚合内容。托管和聚合是分离的。第二张是 Facebook：所有人都被圈进同一个「盒子」，一个公司同时控制数据和应用。第三张是 Mastodon：盒子被复制了许多份——每个实例既是托管方也是应用方，用户 @ 在「国籍」里。实例之间通过 O(n²) 的消息转发互通。atproto 走了第四条路：PDS（Personal Data Server）只管托管用户的签名数据仓库；relay 将全网公开内容汇聚为单一数据流；AppView 消费数据流并为客户端构造信息视图。用户不「属于」任何实例——你只在某个 PDS 上托管数据，可以随时迁移。
Abramov 当天就演示了一次 PDS 迁移，全程只遇到三四个 UX 瑕疵。这个演示是真实的，也确实契合 RSS 式的想象。
但 Lobsters 上 42 票的最高赞评论，问的是另一个问题。笔者觉得这个问题比 Abramov 回答的范畴错误更值得拆解：「当人们问实例在哪儿时，他们实际问的是——有没有独立运营者？如果 Bluesky 公司消失了，网络还在不在？」
PLC 目录：身份系统的中心化命门
要回答这个问题，得先理解 atproto 身份系统的设计。
每个 atproto 账户的核心标识是 DID（而非 @handle）——一个 W3C 标准的去中心化标识符。atproto 使用 did:plc（Public Ledger of Credentials）格式，由 Bluesky 内部开发。DID 是一个基于加密哈希生成的字符串，可公开解析为包含验证密钥、PDS 端点、句柄映射等信息的 DID document。
这个解析依赖 plc.directory——一个由 Bluesky PBC 运营的中心化目录服务。它记录了每个 DID 的创建操作（genesis operation）、密钥轮换、PDS 变更等全部操作历史。
Agent IO 在 2026 年 3 月发表的《Risks of DID:PLC》中，对这个目录做了深入审计。他发现 plc.directory 中存储了超过 8500 万条操作记录，其中约 20%（1700 万条）关联到一个不存在的服务器 pds.trump.com——这是目录不经身份验证、接受任何格式正确文档的直接后果。更令人不安的是，两个归属 Bluesky 的轮转密钥（rotation keys）各自被引用了约 4900 万次。这意味着 Bluesky 所有用户共享同一组轮转密钥。
这两把密钥的安全程度，直接决定了整个网络中每一个 DID 的安全。如果把密钥丢失或被攻破，攻击者可以改写任意一个 DID——将 PDS 端点指向恶意服务器、篡改验证密钥、或者变更句柄。这不是理论风险。它是一种「一发溃全身」的设计。
Lobsters 的三层争论
Lobsters 上的 59 条评论，笔者梳理出三个递进的争论层次。
第一层：PLC 目录是不是单点故障？
用户 notjack 承认「网络可以在 Bluesky 消失后存活」，但补了一句——「PLC 目录服务在切换上会比较棘手」。mort 拿到了 33 票的回击：「『可以，除了这个难以切换的中心化服务』的同义词就是『不可以』。」
jcalabro 指出 Bluesky 已经在 2025 年 9 月宣布将 PLC 目录移交给一家独立的瑞士协会运营。mort 的回应直接击中要害：「移交到另一个组织并不改变它中心化的事实。如果有一个权威机构，所有人必须同意信任它，那就不叫去中心化。」
easrng 从技术层面做了补充：任何人都可以镜像 PLC 目录（现有镜像如 plc.wtf 已在运行），操作本身就是密码学签名的，目录无法伪造身份变更记录。唯一需要中心化协调的是 72 小时回滚窗口——在此期间目录运营方可以撤销操作。mort 的最终立场没有退让：「如果目标是去中心化社交平台，那这就是失败。」easrng 的回应则从目标层面消解了这个批评：「那恰好不是 Bluesky 的目标。」
第二层：atproto 的架构到底有没有去中心化？
用户 SpindleyQ 的评论获得了 38 票：「『就像 RSS 一样，只不过中间有几个我没在示意图里画出来的巨型昂贵服务器』——这种说法有误导之嫌。ATProto 没有像桌面 RSS 阅读器那样直接与 PDS 通信的应用。」gcupc 进一步指出，Abramov 示意图中的 app 实际上指向 AppView——它强制性地扮演了 Google Reader 的角色，运行一个 AppView 需要复制全网数据。
用户 David_Gerard 提供了一个量化的视角：99.99% 以上的 atproto 用户仍然使用 Bluesky PBC 的基础设施，包括 PDS、relay 和 AppView。当人们用 mastodon.social 仅占 Fediverse 20% 来说明 Mastodon 的中心化问题时，却对 atproto 的 99.99% 视而不见，这本身就构成了信息不对称。
第三层：到底什么才是「去中心化」的标准？
用户 ubernostrum 的观点代表了一种务实派的妥协。他认为 Bluesky 追求的目标是「可信用退出」（credible exit）：如果公司变质，具备足够资源的一方可以在新域名上重建整个网络，携带完整的帖子历史和社交图谱——用户不需要手动迁移，识别、导入或逐一声明迁移。技术上的完全去中心化并非其首要目标。在理论上有意义，但在实践中面临身份验证信息随 Bluesky LLC 消失而不可迁移的问题。quasi_qua_quasi 的追问「如何阻止他人冒领 myusername.bluesky2.whatever？」没有得到可操作的方案。
密码学上更”去中心化”的替代方案
从技术层面看，plc.directory 的中心化程度并非必然。
DID:PLC 的操作链本身就是自认证的：任何人都可以用轮转密钥验证签名有效性，用 CID 确认操作链的连续性，用 SHA256 + base32 验证 DID 与创世操作的对应关系。这些都是纯密码学检查，不需要中心化服务器参与。唯一必须信任目录的，是时间戳——哪个操作先发生、哪个操作后发生，决定了 72 小时回滚窗口内哪些变更可以被撤销。
Agent IO 提出了一个改动：让 PLC 目录在每条操作记录上附加自己的签名，生成可移植的「公证」凭证。这样 DID 链可以在任何地方缓存验证，验证者只需决定信任哪些公证方。这个概念与证书颁发机构（CA）体系有相似之处——信任锚可以迁移，但迁移本身需要社会共识。
另一种选择是使用 did:web。GitHub 上的 atproto 讨论区（bluesky-social/atproto/discussions/2705）有大量关于从 did:plc 迁移到 did:web 的讨论。did:web 将 DID document 放在域名的 /.well-known/did.json 位置，用户可以用自己的域名完全控制身份。代价是失去了 PLC 的一些便利——比如无需手动管理 TLS 证书续期，无需在 DNS 层面做额外配置。对于技术用户，did:web 是一个切实可行的去中心化替代方案。
但这两条路径各有代价。PLC 签名公证需要建立新的信任锚生态，did:web 把身份绑定在 DNS 上——DNS 本身也有自己的中心化问题和缓存不一致风险。没有免费的午餐。
从架构选择到工程取舍
审视 atproto 的架构选择，会看到一组具体的取舍。
PLC 目录的 72 小时回滚窗口，是一致性优先于可用性的设计。这个窗口允许运营者在密钥泄露时撤销恶意操作，代价是引入了对目录的信任依赖。如果移除这个窗口，用户的身份在密钥泄露后永远无法恢复——前者主动放弃了完全去中心化，后者主动放弃了安全性。两者都是选择，不存在绝对正确的答案。
relay 和 AppView 的高资源门槛则是另一种取舍。atproto 提供了一种全局可查询的共享数据层——任何 AppView 都可以访问全网的公开内容，不需要与每个 PDS 单独协商联邦协议。代价是运行一个完整 AppView 需要复制整个网络的数据。ActivityPub 的反向选择同样有代价：自托管实例成本低，但跨实例查询依赖散布的消息传递，全局搜索和发现能力天生受限。
选择取决于你愿意承受哪种缺陷。没有架构在所有维度上都优于另一个。
结语
Dan Abramov 是对的：atproto 没有 Mastodon 意义上的「实例」。但他的文章回避了一个同样重要的问题——plc.directory 作为身份系统的单一权威源，是整个网络中最脆弱的中心化节点。
Bluesky 将它移交给瑞士协会，是实体层面的去中心化尝试。但逻辑单点仍然是逻辑单点。did:web 提供了个体层面的逃生舱，代价是 DNS 依赖和配置复杂度。PLC 签名公证提供了生态层面的可能性，但需要社区共识工程和长期的信任建设。
三层防御叠加起来，是否能覆盖 plc.directory 被攻破或失控的后果？目前没有一个技术方案给出确定答案，因为这个问题最终不完全是技术问题——它涉及信任、治理、以及社区在危机时刻能否协调行动。
以上分析基于目前的公开信息和社区讨论。如果有不同视角或补充信息，欢迎交流。