【译】How decentralized is Bluesky really?

由ChatGPT-4o 翻译，原文链接：https://dustycloud.org/blog/how-decentralized-is-bluesky/

最近，由于各种事件（尤其是许多人离开了 X-Twitter），Bluesky 变得更加流行，对其底层协议 ATProto 的关注和兴趣也在增长。由于我曾参与开发 ActivityPub，这一协议将 Mastodon、Sharkey、Peertube、GotoSocial 等等连接到当今的联邦宇宙（Fediverse）中，我经常被问及对 ATProto 与 ActivityPub 的看法。对此，我的确有一些观点，但由于我通常专注于开发下一代去中心化（社交）网络技术，所以我通常对这些问题保持沉默，仅在私下渠道中讨论。

然而，这场关于 ATProto 和 ActivityPub 的争论变得越来越难以忽视。一方面，有文章批评称“Bluesky 只是在扮演去中心化的角色”；另一方面，也有文章支持 ATProto，认为“去中心化只有在需要时才会被重视”。（后者最近引起了很大的关注，但现在似乎变成了仅限订阅的内容，之前并非如此。）尽管如此，我一直认为自己对此主题的任何评论都可能无法产生积极的效果，因此选择将这些想法留给自己或与身边亲近的人分享。然而，最近一位核心的 Bluesky 开发人员直接鼓励我，他们表示我的文章很有洞见和价值，希望我能够就此主题发表看法。所以，现在我决定分享我的一些想法。

我们从一个框架开始讨论。去中心化是指一个系统将权力分散到其结构中，使得没有任何节点在中心拥有特殊的权力。“联邦化”（Federation），作为一个技术术语，自“联邦宇宙”（Fediverse）概念出现以来被广泛使用（目前主要与 ActivityPub 相关，但我认为 XMPP 和电子邮件也属于联邦化的范畴），是一种通信架构的技术方法。通过许多独立节点的协作和通信，联邦化实现了去中心化，使整体成为一个统一的系统，同时没有任何节点拥有超越其职责或通信范围的权力。

基于这些定义，Bluesky 和 ATProto 实际上并不是真正意义上的去中心化，也不是联邦化的。然而，这并不意味着 Bluesky 没有达成一些有价值的成果。虽然 Bluesky 并没有构建一个目前意义上的去中心化 Twitter，但它确实打造了一个出色的 Twitter 替代品。Bluesky 的主要目标是实现另一件事：提供一个可以替代 Twitter 的平台，同时具有“可信退出”的可能性。

Bluesky's strengths

我相信在读到上一段时，有些人可能已经感到不快了，但请容我稍后再解释我的理由，这将是一个技术性分析。不过，让我们从积极的一面开始，因为我认为 Bluesky 确实有值得称道的地方。

Bluesky 在适应当前局势方面表现得非常出色。眼下，由于马斯克接管 X-Twitter（特别是在特朗普竞选连任之后），Bluesky 面临着大量用户的涌入，他们正在寻找 X-Twitter 的替代品。换句话说，那些对“X 已经变成白人至上主义者的平台”持同情态度的用户，现在正在寻找新的平台。而 X-Twitter 的未来可能是一个只有极右翼人士会感到舒适的地方，其他人则会急于寻找替代品，而 Bluesky 无疑是最快捷、最容易的选择。

在许多方面，Bluesky 正是为这种情况而生的。它的用户体验几乎就是 Twitter 的一对一替代，完整还原了许多人曾喜爱的 Twitter 的功能。而最初推动 Bluesky 项目的指令，是由 Jack Dorsey 和 Parag Agrawal 共同发起的（据我所知，这主要是 Jack 的愿景，但由 Parag 主导）。他们希望启动一个 Twitter 可以采用的去中心化协议。这一目标影响了 Bluesky 的许多初始架构决策，包括其扩展需求。最终，Bluesky 意外地成为了一个优秀的“离场”平台，因为许多 X-Twitter 用户发现自己已无法在这个平台上感到舒适。怀念老版 Twitter 吗？Bluesky 已经为你构建了一个替代品：加入进来吧，它就像过去的 Twitter 一样！

Jack Dorsey 启动了 Bluesky 并为其提供资金的事实，经常在联邦宇宙中引发尖酸刻薄的评论，说 Bluesky 是 Jack Dorsey 的产业。然而，这并不属实：Jack Dorsey 已经退出了 Bluesky，转而专注于 Nostr（我可以简单描述为“比 Secure Scuttlebutt 更令人不适的版本，专供比特币用户讨论比特币”）。因此，我认为这种特定的批评并不成立。此外，Bluesky 也完全独立于 Twitter。我印象中，这一切都归功于 Jay Graber（Bluesky 的 CEO）的精心谈判。她确保 Bluesky 在获得资金时，不会让 Twitter 对其拥有控制权，这展现了她的远见卓识。

谈到这一点，我个人最尊敬 Bluesky 的部分可能就是 Jay Graber。当她被任命为 Bluesky 的领导者时，我一点也不感到意外；考虑到她在项目中的领导能力，她是最显而易见的选择。我与 Jay 的每次交流都非常积极，我相信她以真诚和关怀领导她的团队。此外，尽管接下来会有技术性批评和重新框架的讨论，我知道 Jay 的团队中还有其他许多人，他们真心关心 Bluesky 和其既定目标。

还有一点是 Bluesky 做得对的，而当前的联邦宇宙没有做到。这就是 Bluesky 使用了基于内容的内容寻址（content-addressed content），使得即使某个节点宕机，内容也能被保留下来。通过这种方式（以及据说与身份相关的功能，不过我会批评这部分，因为它有几个问题），Bluesky 实现了其所谓的“可信退出”（这是 Bluesky 自己的术语）。即使主节点或个人主机宕机，帖子仍可以被引用。这种功能在联邦宇宙中也是可以实现的，但目前并没有实现。如今，联邦宇宙的用户必须非常担心节点宕机的问题。实际上，我在设计 ActivityPub 时，特意为内容寻址的帖子保留了可能性，并在几年前写了一个演示，展示如何将内容寻址与 ActivityPub 结合。然而，尽管这种功能与 ActivityPub 是兼容的，但今天的 ActivityPub 并没有实现内容寻址，而 Bluesky 做到了。

Bluesky's architecture and centralization

On blogs, search engines, and Google Reader

当你构建一种理论上任何人都可以参与的架构，但参与的门槛高到只有拥有最多资源的人才能参与时，你实际上还是建立了一个围墙花园。\ ——摩根·莱默-韦伯（Morgan Lemmer-Webber），（在早餐时简明扼要总结道）

“把我们的应用想象成一个谷歌。”\ ——ATProto 快速入门指南

我相信，到今天为止，网络和博客仍然被认为是一个去中心化且开放的出版平台。然而，我不知道有谁会认为谷歌是去中心化的。从理论上讲，任何人都可以构建自己的搜索引擎：网络内容正在被消费和索引，解析和聚合这些内容相对简单。然而，实际上很少有人能做到。在实践中，我们现在只有两个（也许三个）搜索引擎：谷歌、必应，也许还有 DuckDuckGo（据我了解，它整合了多个来源，但主要依赖于必应）。

由此可见，Bluesky 的开发者在很多方面将 Bluesky 描述为一堆博客，被 Bluesky 作为一个搜索引擎进行聚合。虽然这不完全正确，但这是理解其挑战的一个良好起点。（要更详细地了解文档中涉及的其他术语，Bluesky 的架构文档是一个不错的参考。）

同样地，正如理论上网络和博客并不属于谷歌，ATProto 的个人数据存储（Personal Data Stores）也并不一定属于 Bluesky 公司。由于目前只有少数人运行个人数据存储，这仍然是可行的，因此 Bluesky 看起来可能是去中心化的。而在目前实践中，Relay 和类似 Twitter 的 AppView 组件实际上只有一个实例在使用，但未来这些可能会发生变化，Bluesky 的架构也提供了允许这种变化的设计。因此，也许事情看起来还没那么糟糕。

然而，如果我们回顾博客和谷歌的隐喻，就会注意到，在当前形式的社交网络出现之前，博客和“博客圈”是互联网通信的主要机制，由 RSS 和 Atom 提要聚合起来。而 RSS 和 Atom 提要阅读器起初拥有丰富的“多样性”，大多运行在用户的桌面上。然后，谷歌阅读器（Google Reader）出现了……朋友们，如果你处于某个年龄段，看到“谷歌阅读器”这个词，你可能会产生一些情绪。谷歌阅读器在提供 RSS 和 Atom 提要阅读器方面做得非常好，虽然不是提供所有功能，但足够了。当谷歌关闭它时，博客（以及我最喜欢的博客衍生形式，独立网络漫画）作为主要媒介迅速崩溃了。博客依然存在，但博客提要聚合迅速被抛弃。浏览器移除了提要图标，大约在同一时间，当前形态的社交网络取而代之。直到今天，博客主要通过社交网络分享。

这就是说：博客加上提要阅读器起初比 Bluesky 的去中心化程度要高得多，而当一个大玩家进入然后退出时，这种系统就被有效地破坏了。

而这还是在提要阅读器作为独立软件运行并不昂贵或困难的情况下发生的。我对联邦宇宙（fediverse）也有这种担忧（如果你认为这篇文章对 Bluesky 很苛刻，而我是联邦宇宙的狂热粉丝，因为我参与撰写了它使用的规范，请继续关注；我计划在这里发布一篇对联邦宇宙现状的批判性分析）。mastodon.social 当然是一个“大节点”，至于 Threads……我们还是不要开始这个长话题了。而且运行你自己的服务器比我希望的要更具挑战性。不过，即使如此，如果你查看一些联邦宇宙聚合器，例如 FediDB 或 Fediverse Observer，你会发现有成千上万个服务器，跨越许多实现彼此互操作。

Self-hosting resources: ActivityPub and ATProto comparison

托管一个联邦宇宙（fediverse）服务器成本很低，尤其是如果你使用类似 GotoSocial 这样的轻量级工具，它足够轻便，可以让你在类似树莓派（Raspberry Pi）这样的轻量级设备上托管一个面向家庭或朋友的服务器。虽然这可能需要一定的技术专长，并且我对其运行方式有诸多批评，但确实可以非常低成本地托管一个完全参与联邦宇宙的节点。

现在，你可能会听到有人说，“运行一个 ATProto 节点也相当便宜！” 这是因为相较而言，运行一个个人数据存储（Personal Data Store）确实相对便宜，因为运行一个个人数据存储更类似于运行一个博客。然而，社交网络比博客要互动性强得多。从这个角度来看，Bluesky 的架构远比一个搜索引擎复杂得多：用户期望能够收到实时通知并与其他用户进行互动。而这正是 Bluesky/ATProto 的核心架构所在：Relay 和 AppView。

那么运行这些组件的挑战有多大呢？截至 2024 年 7 月，在 ATProto 上运行一个 Relay 需要 1 TB 的存储空间。但更令人担忧的是，仅仅四个月后，到 2024 年 11 月，运行一个 Relay 现在大约需要 5 TB 的存储空间。这在短短四个月内增加了近 5 倍。根据我的猜测，到下个月（2024 年 12 月），这个需求可能会至少翻倍至 10 TB，因为大选后的大规模用户转移导致了 Bluesky 的快速增长。随着 Bluesky 的受欢迎程度不断提高，托管一个有意义的参与节点所需的资源增长速度也在加快。

"Message passing" vs "shared heap" architectures

要理解这些系统之间托管需求差异的根本原因，最好的方式是理解它们的底层架构。ActivityPub 遵循消息传递架构（主要利用发布-订阅架构用于大多数“订阅”相关的用途），与电子邮件、XMPP 等相似。消息被指定收件人后送达（实际上，更完全的点对点系统会更直接地传递消息；不过所有电子邮件、XMPP、ActivityPub 等都使用客户端-服务器架构，所以通常会有一个特定的服务器代表特定用户运行。稍后关于联邦宇宙的评论中会讲到如何将这些系统转变为更具点对点特性的架构）。这种架构非常高效；如果只有五台服务器上的用户需要接收到一条消息，在成千上万的服务器中，只有这五台服务器会被联系到。直到最近，我所知的每个被称为联邦化的系统都使用了消息传递架构，以至于我和其他人曾假设“联邦化”意味着消息传递架构，因为实现多个独立节点协作生成统一体的架构目标似乎暗示着这种架构对于大规模网络的效率至关重要。举个例子，如果 Alyssa 想给 Ben 写封信，她可以直接发送给 Ben，Ben 会收到信件。如果 Ben 想要回复，他可以直接回复 Alyssa。这就像我们对电子邮件的直觉一样，因为本质上，这个设计就像是电子邮件。

然而，Bluesky 并不使用消息传递架构，而是采用了我所称的共享堆栈架构。在共享堆栈架构中，消息并不是直接送到某个人的家（或者在客户端-服务器架构下，至少送到他们公寓的邮件室），而是所有可能感兴趣的信件都被直接丢到一个邮局（称为“中继”）。然后，相关方必须亲自前来筛选邮件，看看哪些对他们来说是有趣的。这意味着没有定向投递；如果你想看到与你的消息相关的回复，你（或者为你运营的人）最好能够筛选并了解所有可能的消息，以找到哪些可能是回复。

有趣的是，Bluesky 和 ATProto 并不采用像 ActivityPub 这样的消息传递架构，原因之一通常被描述为希望用户不会经历看到回复线程中遗漏消息的体验。来自 AT Protocol 论文的描述：

Mastodon 中服务器之间的区别为用户带来了在集中式服务中不存在的复杂性。例如，用户在一个服务器的网页界面上查看回复线程时，可能会看到与在另一个服务器上查看同一线程时不同的回复，因为服务器只会显示它已知的回复。

这特别值得注意，因为错过消息的体验是其他共享堆栈架构设计（如 Secure Scuttlebutt 和 Nostr）中的一个常见问题，甚至比在 ActivityPub 和其他消息传递联邦架构中更为常见。（Secure Scuttlebutt 和 Nostr 都采取了措施避免你必须获取所有内容；在 SSB 中，你从你使用的中心节点获取朋友及其朋友的内容，其他的你根本看不到；在 Nostr 中，你只是“拥抱混乱”，只从你使用的中心节点获取信息，而中心节点也不会试图获取所有信息。）举例来说，如果 Ben 在这些系统中回复了 Alyssa 的消息，但没有把回复放到 Alyssa 拉取的中继节点中，Alyssa 将永远看不到 Ben 的回复。如果 Bluesky 存在多个中继节点，估计同样的问题也会出现，那么 Bluesky 是如何解决这个问题的呢？

答案是：Bluesky 通过集中化解决了这个问题。由于实际上只有一个非常大的中继节点，所有人都被期望参与其中，这个中继节点具有“上帝视角”的知识库。对用户来说，筛选邮件和相关回复的任务由 AppViews 执行，AppViews 从中继节点拉取信息，也拥有“上帝视角”的知识库，并进行筛选。同样，所有参与该网络的其他服务也必须以“上帝”的身份操作，而非“凡人”。

如今联邦宇宙的现状是，由于托管一个实例的复杂性，许多用户加入了由朋友或更大组织托管的节点，但网络上仍然有很多节点。如前所述，这更接近于公寓楼而非独立住宅，但去中心化的理想版本是每个人都自行托管，从资源角度看，这完全是可能的。每个人花上几十美元就能买到便宜的计算机并自行托管像 GotoSocial 这样的服务，（虽然目前面临着防火墙和 ISP 对家庭托管的反感问题）从架构角度来看，这是完全可行的。当前阻碍这一未来的主要挑战是托管这些服务的技术难度（以及互联网整体上对家庭托管的敌对态度，尽管对于这种级别的服务，个人共享托管仍然相对便宜）。从消息传输的角度来看，去中心化的理想版本是完全可能的。

那么，完全去中心化的联邦宇宙在物理世界中的等效情况是什么呢？那就是每个用户根据需要将邮件发送到每个其他用户的家，就像在物理世界中发送信件一样。与此不同的是，完全去中心化的 ATProto 的物理世界等效情况将是每个用户都拥有自己的房子，且每个用户的房子里都存放着所有其他用户送来的每一封信件。

如果这在我们的比喻中听起来不可行，那是因为它确实不可行。完全自托管的世界在 Bluesky 中是不可能的。实际上，这比存储要求更糟，因为消息投递的要求在完全去中心化的规模下呈二次方增长：要给一个用户发送消息，就相当于给所有人发送消息。写一封信不再是写一封信，而是必须制作这封信的副本并送达给地球上的每个人。

The costs of decentralizing ATProto

<!--StartFragment-->

Bluesky的架构文档在某种程度上承认了这一点：

联邦架构允许任何人托管中继节点，尽管这是一项资源需求较大的服务。很可能会有几个大型的全网提供商，然后是大量的小型网络提供商。小型定制的中继节点也可以为网络中的某些特定新应用或小型社区提供服务。——《联邦架构概述》（Bluesky博客）

然而，文档并未提到的是，任何较小的定制中继节点在消息回复丢失问题上会比基于定向消息传递架构的系统面临更大的挑战。如果较大的节点是“神”，那么可以说较小的节点是“半神”，从这个角度来看，只有真正完全的“神”才能在网络中发挥实质性的作用。

与此同时，Bluesky的许多用户似乎认为它的去中心化程度比实际情况要高：

一位用户似乎认为Bluesky的搜索是以去中心化的方式进行的对话。

我目前对Bluesky的一个担忧是，很多人正获得一种误解，认为它是一个去中心化的系统，但实际上并非如此。这种误解可能在去中心化的世界中引发问题；一种令人恼火的方式是，人们可能认为Bluesky发现了一种“简单的去中心化方式”，但实际上并非如此。另一个问题是，Bluesky可能在某个时刻崩溃，人们可能因此得出结论：“哦，我们尝试了去中心化，但没成功……记得Bluesky吗？”

但也许我们应该通过再次增加更多真正全面参与的节点来使Bluesky变得更去中心化。那么今天这样做的成本是多少，将来会是多少呢？

再次回到前面提到的Alice的博客文章，最近一次计算Bluesky中继节点运行成本时（不包括运行AppView节点或任何其他关键组件的成本），仅存储方面所需的量为5TB。首先，我做了一个简单的查找，看看如果你要购买一个配置了这些存储量的完整共享主机，它在Linode（作为共享主机提供商的一个例子）上的费用大概是多少？从初步估算来看，这大约是每年55,000美元，仅仅是托管当前中继节点的最新估算：

我查看了Linode上的共享主机费用估算，发现大约是每年55,000美元。

Bryan Newbold指出，这个费用相当昂贵，并且即使在Linode上使用其块存储选项，也有更便宜的选择（尽管这仍然需要一个数据库来配合使用）：

Bryan Newbold拉出Linode块存储的费用估算，约为每月512美元用于磁盘文件托管。

但正如Alice和Bryan Newbold都指出的那样，使用专用服务器会便宜得多。不幸的是，这种解决方案只能在一段时间内有效。在Bryan之前关于运行中继节点的文章中，针对1TB的计算，服务器费用大约为每月152美元，加上一次性设置费用92美元。便宜！然而，网络显然在增长，已经超过了这个规模，因此我们来看一下同样的裸金属服务器，看看我们能添加多少存储，以及这会变得多么昂贵：

添加更多存储的费用：每月414.20美元，获取4块7.68TB SSD NVMe软RAID。

这几乎是将存储费用增加5倍，预计很快运行中继节点的费用就会达到这个水平。而且，这还仅仅是一个没有真正用户基础的单台服务器的费用，我们现在已经达到了专用服务器的极限，因此必须转向更抽象化和集群化的存储和索引机制，以继续支持网络（除非硬盘制造商在短期内惊人地突破存储容量）。

而且，这仅仅是存储的费用，还没有包括备份、带宽、CPU周期等其他维持系统运行的必要条件。单台服务器看起来在很长时间内都不能成为一个可行的解决方案，因此仅仅依赖可以托管整个中继节点的专用服务器（当没有任何用户使用时）并不具有说服力。

此外，还有法律责任问题，实际上等同于托管所有Twitter内容！虽然Bluesky/ATProto提供了多种有趣的过滤技术，但中继节点仍然需要对不安全的内容进行识别：

[...] 中继节点执行一些初步的数据清理（丢弃格式错误的更新，过滤非法内容和高频垃圾邮件）——Bluesky和AT协议：可用的去中心化社交媒体。

对此的可能回答是，Bluesky/ATProto的核心将始终是一个大型公司，网络将依赖该公司来执行滥用缓解工作，特别是在非法内容和垃圾邮件方面。这可能是Bluesky的一个足够好的解决方案，但从经济学角度来看，这将是一个去中心化的系统，但仍然依赖于信任中心化的机构。

Everything is public, including who you block

您可能读到这里时会想：到目前为止，我只从公共内容的角度分析了 Bluesky。那么私人或半私人的内容呢？在这样的环境中，Bluesky 如何提供各种过滤、标记等服务？Bluesky 如何知道哪些消息是回复您的、带有限制或完全私密的消息？

答案是，目前 Bluesky 和 ATProto 并没有为此设计任何方案，而且其大多数架构假设仅针对公共消息。当然，这种情况可能会改变，但目前 Bluesky 的文档和架构中所提到的一切都是基于仅支持公共内容的假设。实际上，即使是“屏蔽”功能也是公开信息：

[...] 例如，如果一个用户屏蔽了另一个用户，而其中一方的存储库中包含了因屏蔽本应被禁止的交互记录，那么 App View 会删除该交互记录，以确保客户端应用中看不到。这种行为与 Twitter/X 上的屏蔽功能一致，也是屏蔽记录在 Bluesky 中成为公共记录的原因：每个符合协议的 App View 都需要知道谁屏蔽了谁，以便执行屏蔽操作。——《Bluesky 和 AT 协议：可用的去中心化社交媒体》

不过，我并不确定这种行为真的与 Twitter/X 的屏蔽功能一致。我的理解是，屏蔽某人并不是公开信息。但在 Bluesky 上，屏蔽记录确实是公开信息，任何人都可以查询谁屏蔽了谁或谁被谁屏蔽。确实，在大多数社交媒体系统中，从被屏蔽账户的视角看屏蔽账户的帖子或观察交互结果可能会透露屏蔽信息，但这与信息可以被公开查询并不相同。从“你可以查看某人的帖子以看到屏蔽了谁”到“你可以查询网络中每一个屏蔽或被屏蔽的用户”，这之间有很大的区别。

我对此非常惊讶。在 ActivityPub 的开发过程中，我记得与 Amy Guy 进行过一场讨论，我们认为不应在服务器之间传递屏蔽活动信息。这一点被明确写入了 ActivityPub 的规范中：

屏蔽活动用于表明发布屏蔽活动的主体不希望另一个主体（在 object 属性中定义）能够与其发布的对象进行交互。服务器应阻止被屏蔽的用户与发布屏蔽活动的主体的任何对象交互。

服务器不应将屏蔽活动传递给被屏蔽的对象。——《ActivityPub》

原因非常简单：我们见过因使用屏蔽列表而被报复的情况。例如，屏蔽某些对被屏蔽行为感到愤怒的人，可能导致屏蔽用户受到骚扰。我们认为共享此类信息可能引发骚扰问题。（据我所知，Mastodon 允许用户选择是否向问题实例发送屏蔽“报告”，以便该服务器的管理员可以注意到问题用户并采取行动，但发送此类信息并非强制。）

话虽如此，值得肯定的是 Bluesky 对此问题进行了公开讨论。目前有一个公开问题正在考虑是否可能实现私密屏蔽。这确实说明了一点：尽管我在这里提出了许多批评，许多问题在未来仍有可能被更改和重新评估。不过，我仍然认为将屏蔽记录设为可公开查询是早期决策带来的结果——早期的架构决策可能会产生长期的架构影响，尽管许多事情可以改变，但有些事情从一开始的设计就很难再做重大调整。

Direct messages are fully centralized

但是，你可能会注意到！Bluesky 提供了私信功能！所以肯定不是所有信息都是公开的，否则私信功能就根本无法运作！那么，Bluesky 的私信是如何实现的呢？

答案是，如果你猜到了，那就是中心化。无论你的个人数据存储（Personal Data Store）是什么，无论你的中继（relay）是什么，所有的私信都要通过 Bluesky 公司。

如果你对此感到震惊，我也是，但话说回来，这个信息在宣布私信功能时就是公开的。Bluesky 的私信既不是端到端加密的，也没有使用任何支持去中心化或联邦化的协议。

或许我们该退一步思考……我是不是太苛刻了？毕竟，虽然联邦宇宙（fediverse）的运作方式类似于电子邮件（实际上，ActivityPub 的架构，尽管许多用户认为 Mastodon 是 Twitter 的一个克隆并因此将联邦宇宙体验视为公开广播平台，但它的设计初衷首先是为直接通信服务的……公开通信显然是支持的，但默认和最简单的情况是直接的个人或群组消息通信），但它的隐私性也“和电子邮件差不多”。也就是说，对于当今许多类型的安全需求而言，这样的隐私性已经不够了：你的管理员可以读取你的私信，但在一般情况下希望不会这么做。然而，我可以亲自认识我的管理员，因此信任的动态关系往往并不相同。

A feature complete Twitter ASAP

因此，Bluesky 的私信功能是中心化的。虽然 Bluesky 确实在博客中提到了这一点（但大多数人在阅读时不会看到这一部分），但我和许多用户交流后发现，他们普遍以为私信功能的运作方式与 ATProto 的其他部分相同。那么，为什么 Bluesky 会推出一个他们自己也承认并非长期目标的私信系统呢？（不过我还是很困惑……为什么他们至少不使用 XMPP 呢？）

合理的解释是：Bluesky 希望从用户的角度提供一个功能完整的平台，满足那些希望立即脱离 Twitter 的用户需求。坦白说，这在很多方面是一个合理的决定。正如我之前所说，虽然我并不认为 Bluesky 是一个非常好的去中心化 Twitter，但我确实认为它是一个很好的 Twitter 替代品，这正是大多数用户眼下迫切需要的。然而，对于像我这样真正关注并在意去中心化的人来说，看到许多用户和媒体对这些细节缺乏了解，确实让人有些抓狂，我知道联邦宇宙（fediverse）的很多人对此也感到困惑。

不过，再次强调：对许多用户来说，这并不重要。目前逃离 X-Twitter 的用户最关心的是找到一个 Twitter 的替代品。从这个角度来看，无论 Bluesky 是否真正去中心化，它显然看起来比 Twitter 更加去中心化——就像 Twitter 看起来比有线新闻更去中心化一样。去中心化有时是一个程度问题，我确实认为联邦宇宙可以比现在更加去中心化（稍后会对此再展开讨论）。然而，就权力的分布方式而言，Bluesky 的技术在很大程度上显著低于目前已部署的主流去中心化技术的分布水平。

Bluesky is centralized, but "credible exit" is a worthy pursuit

在许多地方，Bluesky 在其官方文档中承认自己比其他替代方案更加中心化。正如其白皮书中提到的：

即使目前大多数 Bluesky 服务由单一公司运营，我们仍然认为这个系统是去中心化的，因为它提供了可信的退出机制：如果 Bluesky Social PBC 倒闭或失去用户的信任，其他服务提供商可以使用相同的数据集和协议接手，提供等效的服务。\ ——《Bluesky 和 AT 协议：可用的去中心化社交媒体》

Bluesky 专注于为怀念过去 Twitter 的用户提供 X-Twitter 替代品，以及为那些急需脱离不良环境的用户提供解决方案，这并不是一个坏选择。我理解并支持这一努力！Bluesky 确实采用了一些去中心化的技巧，这些技巧可能有助于实现其“可信退出”的自我定位目标。然而，这并不意味着 Bluesky 是去中心化的——按照当今现有的去中心化协议的权力动态标准，它显然不是。而且，它在任何意义上都没有使用与去中心化社交网络努力中“联邦化”（federation）这一技术术语相符的方式。（我听说有人用“联邦洗白”（federation-washing）来形容这种概念的偷换，我个人对此表示认同。）

在我看来，这其实应该是 Bluesky 对自己的品牌定位，这样会更加诚实：一个拥有开放架构（这点可以接受！）并提供可信退出可能性的系统。这种表述会更准确，也更符合 Bluesky 实际为用户提供的功能和价值。

ATProto's portable identity challenges

Bluesky 所谓的“可信退出”主张依赖于内容寻址以及去中心化标识符（DID）用于账户迁移。这确实是一个好的目标，账户迁移的支持应该在更广泛的系统中得到应用（包括联邦宇宙 Fediverse）。

然而，这其中存在几个主要问题：

1. ATProto 支持两种 DID 方法：did:web 和 did:plc。尽管“DID”中的“D”代表“去中心化”（Decentralized），但这两种方法实际上都是中心化的。
2. ATProto 的 DID 方法与 DNS 之间的循环依赖关系会导致问题，从而削弱 DID 的效用（这一问题是可以解决的，但我不确定是否会有人对此感兴趣）。
3. 即使用户希望脱离 Bluesky 的基础设施，Bluesky 很可能对该用户的身份拥有实际上的永久控制，这就削弱了“用户长期不必信任 Bluesky 作为一家企业”的承诺。
4. 关于通过 did:plc 生成的 DID，还有一些其他令人担忧的细节。

Some history: Decentralized Identifiers (including the centralized ones)

首先，介绍一些背景知识。DID 核心规范（DID Core spec）实际上更像是一个抽象接口，基于此可以实现具体的“DID 方法”。DID 方法主要提供一种机制，用于注册、检索和轮换加密公钥（尽管轮换并不是严格的要求，例如 did:key 就无法轮换）。

令人惊讶的是，尽管“DID”这个名称和最初设计者的意图表明其应该是去中心化的，但 DID 方法并不要求是去中心化的。

我提到“令人惊讶”，你是否感到惊讶？我曾经在这一领域非常活跃（虽然我没有直接参与 DID 规范的工作，但在 Digital Bazaar 工作时，我有时会参与可验证凭证的会议，并且与他人共同撰写了一份在该领域开发的规范，用于链接数据能力 zcap-ld）。之所以提到这些，是为了提供一些背景信息：允许去中心化标识符方法完全不去中心化这一点曾是一个有争议的话题。

我想当时我已经离开了这个小组，但我记得和同事们讨论过 did:web，它是第一个明确支持中心化的 DID 方法。但等等，我之前不是说过 Web 是开放且去中心化的吗？是的，但 Web 所依赖的命名+加密系统却不是：DNS+TLS 依赖于从 ICANN 向下的信任，以及 TLS 证书颁发机构，这两者都是中心化的方式。据我所知，did:web 的主要论点是提供一种简单的 DID 方法，使所有符合规范的实现都可以轻松通过 DID 测试套件。我属于认为将中心化的 DIDs 认定为“去中心化标识符”这一阵营，这样做会导致“去中心化洗白（decentralization-washing）”，而这正是现在发生的事情。

关于 did:web 还有一件很可笑的事：did:web 并没有真正存在的必要，因为它的实际作用只是通过一个简单的正则表达式将其重写为一个 https: 链接。在任何相关的上下文中，你都可以直接使用这个 https: 链接并提供相同的信息。问题在于，人们听说 did:web 是一个去中心化标识符，就认为它一定是去中心化的，但实际上 did:web 并没有解决 DNS+TLS 固有的中心化挑战，它只是直接使用了这些系统！遗憾的是，由于这个名称，许多人以为 did:web 比简单地通过 https: 检索密钥提供了更强的安全层。我在这里告诉你，这并没有，因为这恰恰就是 did:web 实际在做的事情。

did:plc, the "placeholder" DID

但是，Bluesky 开发了其自己的 DID 方法，称为 did:plc。目前，did:plc 代表“公共凭证账本”（Public Ledger of Credentials），但最初它的含义是“占位符 DID”（Placeholder DIDs），希望在未来用其他方法替代它。did:plc 的运作方式是由 Bluesky 托管一个网络服务，用于注册、检索和轮换密钥（以及其他关联的 DID 文档信息）。然而，这个账本是由 Bluesky 集中控制的。

这种中心化的特点本身并没有像读者可能想象的那样让我感到困扰！一方面，如果一切运作正常，Bluesky 只能拒绝轮换或检索 did:plc 文档，但由于文档的未来更新是由原始 DID 文档的密钥签名的，Bluesky 不应该（嗯，我们稍后会回到“应该”这一点）能够伪造这些文档的未来更新。而且，Bluesky 的开发人员非常坦诚地承认 did:plc 是中心化的，并且表示有兴趣将其替换为其他方法，或者通过改进治理方式将该组织交给一个更中立的机构控制（Paul Frazee 尤其建议，可以将其移交给类似 ICANN 的组织）。

然而，did:plc 的一些其他方面显得有些奇怪。例如，did:plc 文档的标识符据我所知是 DID 文档的 SHA256 哈希值，截断为 15 字节（120 比特）的熵。这在我看来是一个奇怪的决定；确实，did:plc URI 可以适配为 32 个字符（8 个字符用于 did:plc:, 20 个字符用于截断的哈希），这可能是一个“计算机风”的整洁数字，但为什么要放弃这么有价值的熵？是为了美观吗？DID 标识符本来就不是给人类阅读的，而是封装用的，所以在我看来这是一个奇怪的决定。（我承认自己在密码学方面是个业余爱好者，但我年纪够大，还记得 Debian 因使用 PGP 短 ID 而陷入麻烦的事情。）（此外，选择 SHA256 而不是 SHA256D 也可能引发长度扩展攻击的问题，不过我想由于文档的解析，这可能不是个问题，我不确定。）总之，这些都是奇怪的决策。但是再次强调，did:plc 原本就是个占位符。问题在于，这个占位符如今已经成为许多现有用户的标识符基础。

我自己没有花太多时间审查 did:plc，只是阅读了一些高层次的细节并提出疑问。不过，一篇名为 Hijacking Bluesky Identities with a Malleable Deputy 的博文提到了一些其他奇怪的细节。其中最令人担忧的一点是：

然而，有一个因素将此问题从“一个好奇点”提升为“一个大问题”：bsky.social 为每个账户使用相同的 rotationKeys。单凭这一点就是一个令人惊讶的决定；显然他们使用的云 HSM 产品按密钥计费，因此给每个用户分配一个密钥的成本会非常高昂。（我听说他们计划从“云托管”转向“本地托管”，或许到时候他们能给每个用户分配自己的密钥对？）

我没有核实，但我假设现在情况已经改变了。然而，我发现重复使用相同的密钥这一点曾经存在的事实令人惊讶且令人担忧。这似乎与构建 DID 系统时的基本目标背道而驰，我难以理解为何会做出这样的决定。

不过，关于 did:plc 和中心化，还有一个更大的问题：

原则上，用于签署存储库更新和 DID 文档更新的加密密钥可以直接保存在用户的设备上，例如使用加密货币钱包，从而最大限度地减少对服务器的信任。然而，我们认为，这种手动密钥管理方式对大多数用户来说并不适合，因为密钥被泄露或丢失的风险很大。

因此，Bluesky 的 PDS（Personal Data Servers）为用户托管这些签署密钥，而用户通过用户名和密码登录其本地 PDS。这为用户提供了一种熟悉的使用体验，并启用了例如通过电子邮件重置密码等标准功能。AT 协议对 PDS 如何验证用户没有任何假设；其他 PDS 运营商可以自由使用其他方法，包括用户自主管理的密钥。

-- Bluesky 和 AT 协议：可用的去中心化社交媒体

我对此表示理解：的确，用户密钥管理是一个非常复杂的用户体验和协调问题，因此这个决策可能并非完全错误。但更令人担忧的是，用户被告知，如果他们想离开 Bluesky 这家公司，可以随时离开！毕竟，用户可以在未来更改自己的密钥以及指向的位置。然而，对于今天信任 Bluesky 而明天不信任 Bluesky 的用户来说，这实际上意味着什么？事实是：**Bluesky 控制着用户的密钥，因此，即使用户“离开”，他们仍需信任 Bluesky 代表他们完成这一操作。**即使 Bluesky 在未来将这种权力授权给用户，允许他们控制自己的身份信息，问题仍然在于，Bluesky 始终掌握着用户的密钥，从而对用户的身份未来拥有控制权。

Zooko's triangle, petnames, and a cyclic dependency between DNS and DIDs on Bluesky

唉，身份问题并未因此结束，因为在 Bluesky 中，将用户的 DID 绑定到用户可见的用户名（handle）存在一个根本性的问题（或一系列问题）。Zooko's Triangle（祖科三角）告诉我们，一个去中心化且全球唯一的名称无法同时具有对人类友好的含义，而真正去中心化的分布式标识符（DID）确实无法做到这一点。尽管 did:plc 并非真正去中心化，但它本身是一个对人类而言无意义的标识符。那么，解决方案是什么？我们如何提供一个对人类有意义且用户能够理解的名称？

我坚信，正确的答案是 Petname System（宠物名系统），它可以为全局非人类友好的名称提供本地化的人类友好含义。然而，为什么我认为这是正确的方法以及如何实现它，这些讨论超出了本文的范围。我只能提到 Ink and Switch 曾经展示过一个很棒的宠物名系统 demo（尽管不够完善），而且可以在 Spritely 的一个原型中找到更多可以阅读的想法。但坦白说，到目前为止，宠物名系统尚未被广泛部署，因此其用户体验问题尚未完全解决。

或许正因为如此，Bluesky 没有为用户的用户名采用宠物名系统，而是选择了今天用户更熟悉的东西：域名！Bluesky 中的每个用户名实际上都相当于一个域名。而且用户还可以通过关联到另一个域名来更改他们的用户名！

从某种意义上说，Bluesky 采用人类友好的名称并将其映射到不那么人类友好的标识符，这是一个正确的做法。如果他们使用的是一个真正去中心化的分布式标识符，这似乎是一个好的未来信号。但是，等等……我们深入看一下，情况似乎有点复杂。

ATProto 使用 DID 文档中的 alsoKnownAs 字段，让 DID 声明它与哪些 URL 相关联。然而，DID 文档本身无法真正验证这些信息，因为验证此类信息是一种“实时”操作，而 did:plc 方法的文档正确地指出了这一点：

PLC 服务器不会在操作中交叉验证 alsoKnownAs 或 service 条目。这意味着任何 DID 都可以“声称”拥有任何身份，或拥有任何服务（由 URL 标识）的活跃账户。在没有双向验证的情况下，例如通过 handle 解析，此数据不应被信任。

因此，验证 DID 是否确实映射到它声称的用户名（handle）的任务，实际上落在了 ATProto 的其他基础设施上（如果我们要足够健壮，应该在流程的每个步骤中进行验证，但如果选择不够健壮的方法，也可以信任某个数据来源）。

但这令人困惑。考虑一下：DID 的初衷是提供去中心化的身份路径，而 DNS+TLS 显然不是。然而，即使在 did:plc 的情况下，仍然必须依赖网络的实时性来确保用户名和 DID 文档之间是双向映射的。因此，did:web 的问题实际上也存在于 did:plc 中。

此外，还有其他棘手的问题：如果我们曾经验证过 did:plc:<blah> 双向映射到 alyssa.example，但后来 https://alyssa.example 暂时或永久不可用，怎么办？如果一个新用户声称代表 alyssa.example 出现，并且似乎“通过了验证”，那该怎么办？我们如何向用户呈现之前 alyssa.example 发布的帖子？又如何呈现现在的呢？我不知道这些问题该如何回答……你知道吗？

对于用户来说，DID 实际上并未真正起作用：如果 Bluesky 公司倒闭，导致 bsky.app 下线，用户将很难判断 alyssa.bsky.app 是否仍然代表 Alyssa。对于用户来说，alyssa.bsky.app 的 DNS 记录就是 Alyssa 的身份记录，而不是 DID。一个宠物名系统可以解决这些问题，而 Bluesky 的用户体验不能。

Can you credibly exit with your identity from a Bluesky takeover?

但总的来说，如果一家敌对公司接管了 Bluesky，did:plc 的表现似乎并不理想：

• Bluesky 本身已经掌握了大多数用户的密钥，因此无论如何都可以控制用户的身份未来，包括签名更新的控制权。
• *大多数用户的身份都映射到由 Bluesky 控制的 .bsky.app 子域名**，因此 Bluesky 可以将这些子域名重新分配给不同的用户。即使使用其他“个人数据存储”服务提供商，这种情况也依然适用。
• 如果 Alyssa 从 alyssa.bsky.app 迁移到她自己的域名 alyssa.example，Ben 如何知道她的身份变更？除非 Ben 主动查看之前的互动记录，但通常情况下，用户名的“突然变更”已经是常态，而任何域名更新看起来都会成为钓鱼攻击的良机。
• Bluesky 可以阻止未来的 did:plc 文档更新，而目前提出的解决方案似乎是再创建一个类似 ICANN 的组织。
• 无论是 did:plc 还是 did:web，本质上都需要信任 ICANN，因为用户依赖的就是域名。而如果 did:plc 的解决方案需要一个类似 ICANN 的实体，那么用户实际上需要同时信任两个 ICANN。

目前来看，Bluesky 的身份系统并没有真正实现去中心化，但这只是问题的一部分，如上所述。然而，Bluesky 使用分布式标识符（DID）接口的事实表明，或许未来可以在此基础上叠加真正去中心化的身份解决方案。

与此同时，几乎所有问题都归结为信任域名系统以及信任 Bluesky。用户实际上是信任域名的，因此最终我们还不如直接从特定域名检索密钥。从理论上讲，身份的延续性是可能的，从一个域名转移到另一个域名可以保留身份。然而，这并没有以一种用户能够理解的方式进行实现；从一个域名转移到另一个域名，实际上等于彻底更换了用户所熟知的用户名，甚至可能打开钓鱼攻击的入口。

宠物名系统可以解决这个问题，但在当前阶段整合宠物名系统将显著改变用户对网络的认知。而且，考虑到 Bluesky 作为一个组织，目前依赖出售域名作为其商业策略，淡化域名的重要性似乎不太可能成为其动机。

What should the fediverse do?

我曾承诺对联邦宇宙（fediverse）进行批评，实际上自从 ActivityPub 发布以来，我一直在批评联邦宇宙。并不是说我认为当前 ActivityPub 的部署是一个终极解决方案，恰恰相反。

我对联邦宇宙/ActivityPub 的最简明观点实际上可以在“ActivityPub + OCaps”中找到。这是我与 Jay Graber 一起联合提交的关于 Bluesky 的一个提案，当时 Twitter 还在评估 Bluesky 提案。我提及这一点并不是因为我认为这是应该被选中的提案；实际上，我认为 Bluesky 当时需要快速扩展，而最终选择 Jay Graber 领导 Bluesky 是正确的。同时，我也认为将 Spritely 独立出来作为一个单独的组织最有意义，因为 Spritely 的首要任务是在头几年专注于基础研究。然而，我认为这个提案是我所知的关于如何将联邦宇宙从现状转变为理想状态的最佳写作：

1. 通过全面整合能力安全性（capability security），解决 ActivityPub 规范中缺失的授权部分。关于其重要性的详细说明（包括对联邦宇宙的显著批评）可以在我的 OCapPub 写作中找到。
2. 集成去中心化/内容寻址存储（理想情况下包含类似 Tahoe LAFS 的加密层），以便在服务器关闭时，帖子仍然可以存活（类似于我在 Golem 演示中实现的功能）。
3. 使用可变文件（例如 Tahoe 和 IPFS 是不可变系统的例子，但可以在其上构建可变文件层）以支持便携身份。当用户希望切换服务器时，可以将 inbox 属性指向新端点。
4. 使用“宠物名”系统，使便携的/去中心化的标识符（不一定是 DIDs）更具人类可读性，并使系统在对抗钓鱼攻击方面更具韧性。
5. 基于能力安全的基础设施构建更强的反垃圾邮件/反骚扰工具。
6. 通过引入端到端加密（E2EE）提升隐私（尽管已经有一些工作，但我并未深入关注）。

上述部分任务目前对联邦宇宙来说是可以实现的，例如内容寻址存储和便携身份的引入将是一个重大改进。这些功能的实现将使联邦宇宙在节点故障时更具生存能力。

而其余部分可能更具挑战性，但这些方向对我而言并非新领域。几年前，我撰写了名为 OCapPub 的文档，试图提出一个关于联邦宇宙应如何发展的替代愿景。然而，当时我发现许多联邦宇宙的开发者并未真正理解我所推动的方向，也不清楚如何在诸如 Ruby on Rails 等 Web 2.0 框架上实现这些功能。这可以理解，而我们在 Spritely 的工作实际上就是答案之一：我们正在设计的技术，使得基于能力安全的分布式系统成为构建应用时的自然结果。

Blaine Cook 曾说，ActivityPub 和 ATProto 的正确版本“实际上是同一张图”。这点是正确的，因为解决两者的严重问题最终都会收敛到一个共同方向：联邦宇宙需要采用内容寻址和便携身份（暂且不谈 Bluesky 在便携身份方面的方法问题），而 Bluesky 需要支持一种消息架构，使得参与去中心化的用户无需承担全部托管负担（采用类似 ActivityPub 的解决方案可能是最终方向）。此外，我认为两者都需要朝着支持隐私和更强协作工具的方向发展，基于能力安全的设计。虽然有人认为这是“不同的路径”，但对我来说，这更像是两者都未能实现应有的潜力。我更倾向于认为这是一个需要解决的“固定点”（fixed point），我们需要不断迭代以解决这些问题。

也许对两边来说，这样的建议过于雄心勃勃。而且，根据“越差越好”（Worse is Better）的理念，快速而流行的解决方案往往会占据先机，超越更正确且稳健的解决方案，并最终巩固一个不理想的系统。对于一个已经存在的系统来说，改变其现状可能非常困难，这有点令人沮丧。

上述观点对 Bluesky 和联邦宇宙都适用。然而，目前联邦宇宙实际上是去中心化的，而从我的分析来看，如果有意愿去推进工作，至少在解决内容寻址和便携身份的问题上，架构上的差距并不算大。但我不确定是否存在这种兴趣，也许现在会有更多兴趣。

对我而言，目前我更感兴趣的是“安全协作”（secure collaboration），这也是 Spritely 目前的主要研究方向。我们正在努力寻找社交系统的答案，但尚未完全到达终点。因此，在此期间，我对上述所有内容的评论可能显得非常挑剔。然而，这并非因为我对这些问题不满，而是因为我认为这些确实是需要认真解决的重要问题。“康威定律”（Conway's Law）在双向上都适用：技术系统反映了构建它的人们的沟通和社会结构，而我们的沟通和社会结构也受到可用技术的影响。

无论如何，这些是我关于联邦宇宙以及相关问题的“卡桑德拉情结”（Cassandra Complex）。或许，我的这些批评会让我显得愤世嫉俗和满腹牢骚（希望不是如此，我通常只是专注于构建我认为正确的方向）。但有一点是真实的：联邦宇宙确实是去中心化且联邦化的。我对 Bluesky 尚未实现这两点的批评依然成立。那么问题是：这些问题是否能及时解决？或者，至少，是否能实现一种“可信的退出”（credible exit）？

Preparing for the organization as a future adversary

Bluesky 的一个有趣之处在于其团队使用了一个非常自我反思的短语：“组织是未来的对手”（这里有一些例子）。这是一个非常自觉的短语，通常在组织中很少看到，因此值得称赞。在许多方面，它让我想起了 Google 曾经说过的“不要作恶”，这是一种内部号召，虽然可能从未完全真诚，但它给了内部和外部挑战决策的机会，并在一定程度上使 Google 需要承担责任。尽管在这个短语存在期间发生了很多值得质疑的事情，但当这一术语被废除时，Google 的状况似乎真的变得更糟了。

Bluesky 是一家公益公司，这意味着它的动机不仅仅是盈利；Bluesky 还宣布其工作的目的是为了公众利益，而不仅仅是追求盈利。我可以自信地说，Bluesky 的许多人真正相信这一点，正如我在文章中之前强调的，我认为在 Bluesky 工作的人是善良和真诚的，致力于 Bluesky 的目标。

所以“组织是未来的对手”这个短语确实是当下的先见之言。除了从 Twitter 获得的启动资金（据我了解，Bluesky 获得了这些资金，几乎没有附加任何条件，除了执行其声明的工作），Bluesky 还筹集了两轮风险投资资金。就这一点而言，我对这一点表示尊重，因为我曾在自由和开源软件组织中担任过几乎所有可能的角色，而筹款无疑是其中最艰难和最具压力的工作之一。当你建立一个组织并吸引优秀人才时，他们未来的生计会让你倍感压力。因此，我很高兴看到 Bluesky 获得了资金支持。

但风险资本不是捐赠；投资者希望获得回报。我有很多朋友接受过风险投资，包括一些经营去中心化社交网络组织的朋友，我看到过他们在初期经历了激动人心和积极的时光，但随后他们的组织被寻求回报的投资者从他们手中夺走了。我并不是在负面评价接受风险资本的选择，只是承认：这是当前的状况，我们应该认识到这一点。

通过使用“组织是未来的对手”这一短语，Bluesky 已经认识到这一点。接下来正确的步骤就是开始规划所有工作，以便能够在这种情况下生存下来。

我之前在文中分析了 Bluesky 在实现有意义的去中心化或联邦化方面所面临的挑战。Bluesky 现在面临着比去中心化更大的压力，主要是满足现在愿意涌向该平台的大量用户，满足投资者日益关心的回报问题，以及实现足够的收入来维持员工和服务器的运营。为了向有意义的去中心化转型，Bluesky 将进行重大调整，并可能引入许多其他去中心化平台没有的问题，而这些问题正是 Bluesky 之前声称自己平台没有的。

目前有迹象表明，Bluesky 公司已经开始考虑或探索一些仅在中心化背景下才有意义的功能。之前文中讨论过的私信功能，再加上高级账户的宣布，未来会发生什么令人十分期待。完全去中心化的系统也可以处理高级账户：更高质量的视频上传是合理的。但当自托管的 PDS 用户上传更高质量的视频时，这些视频是否会在 Bluesky 的 CDN 上以更高质量进行镜像？同样，广告似乎也可能会进入 Bluesky：

why.bsky.team 说：“在今天的世界里，想要像这样维持一个公司，广告是不可或缺的，但你始终可以选择不看广告。”

一种常见的方式是使高级账户更加有价值，就是让它们没有广告。但如果 Bluesky 足够去中心化，并且其过滤和标签工具按预期工作，那么用户将能够轻松设置过滤器来去除流中的广告。传统上，当投资者意识到用户正在移除广告并剥夺收入来源时，往往是他们开始强烈施压，推动“恶化”，并移除像公共 API 访问这样的功能。在 Bluesky 的情况下会发生什么呢？

在这里，“可信退出”确实是 Bluesky 架构目标的正确术语。为了实现有意义的去中心化和联邦化，Bluesky 的基础设施将进行大规模的重构，但提供“可信退出”并不需要如此庞大的调整。我的观点是，倾向于“可信退出”是 Bluesky 可以做的最好的事情：也许一两家大公司总是需要坐落于 Bluesky 的中心，但或许也有可能让人们能够离开。

Conclusions

Bluesky 是由关心的人们建设的，它提供了人们迫切需要的东西。如果你在寻找 Twitter 的替代品，今天你可以在 Bluesky 找到它。

然而，我坚持我的观点，即 Bluesky 并没有实现真正的去中心化，并且根据我们以往在去中心化社交网络背景下对联邦化的任何技术定义，它显然也不是联邦化的。声称 Bluesky 目前是去中心化或联邦化的，是在改变这两个术语的原意，我认为这是不可接受的。

然而，“可信退出”是一个合理的术语来描述 Bluesky 的目标。这是 Bluesky 提出的术语，我认为 Bluesky 应该在所有可以的上下文和工作中完全接受这一术语。