ATProto 最吸引人的承诺，是把账号从单个平台里拆出来：你有一个 DID，一个跨应用身份，Bluesky 只是入口之一。

但一篇技术博客把问题挑明了：如果你的 PDS，也就是 Personal Data Server，默认替你保管关键密钥，那这个“属于你”的身份，控制权就没那么干净。

这不是说 Bluesky 已经作恶，也不是说 ATProto 是中心化骗局。更准确的判断是：架构在分散，密钥管理却把信任重新收回到 PDS 手里。

PDS 真正拿着的，不只是数据

ATProto 里，用户数据以 repo 形式存在。发帖、点赞、关注，都可以理解为对 repo 的一次 commit。关键点很简单：这些 commit 需要签名。

博客指出，很多用户的 PDS 默认持有 signing key。PDS 因此可以为用户 repo 的所有 commit 签名。

协议层看到的是合法签名、合法 commit。它不会区分这是用户本人操作，还是 PDS 运营方、攻击者、内部人员代用户做了动作。

更重的是 rotation key。它控制身份轮换：更换 signing key，迁移 DID 指向的 PDS。若 PDS 也持有它，理论上就能接管、迁移，甚至冻结这个 DID 身份。

PDS 可能持有的东西能做什么风险落点
signing key为用户所有 repo commit 签名代用户发帖、点赞、关注、发布内容
rotation key更换 signing key，迁移 PDS 指向控制 DID 身份，造成锁号或接管
同一身份信任链被多个 ATProto 应用复用风险从 Bluesky 扩散到其他应用

这里最容易误判的是“数据泄露”。ATProto 很多数据本来就是公开传播的，firehose 会分发公开事件，relay 主要复制公开数据。

PDS 的危险不在“看见你公开发过什么”。危险在它可能拿着能代表你行动的钥匙。

这对普通 Bluesky 用户的影响很具体：别只看账号能不能迁移，要看你是否有自己控制的高优先级 backup rotation key。没有这把后备钥匙，迁移自由就可能只是纸面自由。

对开发者也一样。接入 ATProto 身份时，不能只把 DID 当便宜登录系统用。你接入的是一条密钥信任链，用户一旦被代签或锁住，锅未必只在原始社交应用里。

传统平台管一个院子，ATProto 可能管一串门

拿 Twitter 类比更容易看清边界。

传统平台内部权限被滥用，最坏情况是你的 Twitter 账号被操作。这很糟，但边界大体还在 Twitter 里面。你的代码协作、长文发布、其他社交身份，不会因为同一个账号密钥一起倒下。

ATProto 的野心更大。Bluesky 是社交入口，Tangled、Grain、Leaflet 等应用也可以共享同一套身份和密钥信任链。应用越多，这个 DID 越像数字生活里的通行证。

这也是风险放大的地方。

统一身份确实方便。用户少注册账号，开发者少造账户系统，应用之间也更容易互通。问题是，便利会把更多东西挂到同一把钥匙上。

古人说，“利之所在，民归之。”技术系统也一样。哪里降低摩擦，流量和应用就往哪里走。ATProto 身份越好用，PDS 默认托管密钥的权力就越值得被认真审视。

我不赞成把这件事骂成“假去中心化”。ATProto 在架构层确实比传统社交平台走得更远。PDS 可以迁移，身份可以独立于单一应用，公开数据也更容易被复制和验证。

但限制也在这里：去中心化不是画在系统图上的箭头，而是落实到默认权力边界。用户默认不会管理密钥，开发者默认会沿用最省事的托管路径。默认设置，才是大多数人的真实制度。

现在该看的，不是口号，是三件小事

我不太买账“用户自己管密钥就好了”的轻巧说法。现实是，大多数用户不会碰 DID 文档，不会研究 rotation key，也不会为了一个社交账号准备硬件密钥流程。

所以改法不能只写在协议文档里。它要进入默认路径。

更合理的方向有三条：

  • 默认引导用户登记自控的高优先级 backup rotation key。PDS 即使还能用 signing key 代签，也不能轻易把用户彻底锁死。
  • 客户端提供可读审计.哪些操作由哪个 key 签名，何时签名，是否由 PDS 代签，用户至少应该能看见。
  • 应用开发者明确提示身份风险.接入 Bluesky、Tangled、Grain、Leaflet 这类 ATProto 应用时，要告诉用户这不是孤立账号，而是同一 DID 的扩展。

现在最该观察的变量也很明确。

一个是主流 PDS 和客户端会不会把 backup rotation key 做成默认流程，而不是高级用户选项。另一个是生态应用扩张时，会不会继续默认信任同一套 PDS 托管密钥。

如果这两件事不改，ATProto 走得越远，PDS 的实际权力越大。不是因为它一定会作恶，而是因为系统给了它作恶、被攻破、被内部滥用时足够大的爆炸半径。

对普通用户，我的建议很朴素：如果你只把 Bluesky 当公开社交账号，先观望也可以；如果你准备用同一个 DID 连接更多应用，就该尽快确认 rotation key 是否有自控备份。

对团队和开发者，动作更直接：别急着把 ATProto DID 当统一身份入口大规模绑定业务数据。先补密钥说明、迁移预案和客户端审计。否则你接入的不是开放身份，而是一份还没写清楚责任边界的托管合同。

门牌写着你的名字，不等于锁芯也归你。ATProto 现在最需要回答的，不是“够不够去中心化”，而是用户在默认路径里到底能不能拿回那把钥匙。