Muni Blog

2025年3月12日 14 分钟阅读 AtProto

你可能并不了解的 ATProto

这篇文章将从不同的角度审视 ATProto，并探讨其中一些可能不太引人注目的部分的价值。

这篇文章关于 ATProto, Bluesky，以及某种程度上 All The Other ATProto Apps。我想借此机会从不同的角度来看待事物，并分享我对 ATProto 的看法是如何随着时间推移而改变的。

等等！！首先我想解决一个显而易见的问题：你这篇文章的标题真的太标题党了。你怎么知道我怎么看待 ATProto 的？

嗯...你好，呃... Charlie。显然我并不_真的_知道你怎么想的。只是“ATProto 可能和你所想的不一样”这句话说起来没那么顺口，所以我为了营销把它缩短了。

好吧，好吧，继续。

无论如何...如果你想进行一些非常长且可选的背景阅读，你也可以阅读 How decentralized is Bluesky really?, Reply on Bluesky and Decentralization，和 Re: Re: Bluesky and Decentralization，这篇文章并不是对这些文章的回复，而且我也没完全读完它们，但它们有助于理解这篇文章的总体情绪和想法。

它去中心化了吗？

我并不打算明确地回答这个问题，但我想要讨论这个问题本身。

有些人，我认为是正确的，说这个问题很微妙。另一些人则说“很明显 Bluesky 没有去中心化”。我认为部分问题在于，当我们问“Bluesky 是否去中心化？”时，我们实际上试图回答很多问题。

人们可能真正想要回答的一些可能的“问题中的问题”可能包括：

“去中心化程度”这个问题实际上只是我们可能提出的其他一些模糊问题的幌子。这没关系。谈论我们脑海中半成型的“威胁模型”的所有细节比说“它去中心化了吗？”要困难得多。

我们只需要意识到这个问题的局限性，并意识到它对不同的人意味着不同的事情。

同样，在这篇文章中，我不会直接提出或回答这个问题，但我会从一些不同的角度来看待它。

中心化的视图覆盖去中心化的数据

我最近看到很多不同类型的 apps 在 ATProto 周围涌现，我认为一个并不立即显而易见的事情是，它们中的大多数在很大程度上只是典型的、中心化的 Web 应用。

不，它们不是！它们在 ATProto 上，所以它们是...去中心化的，或者什么别的！

哦，你还在这里？好吧，别那么认真，听我说完。

为了使用该 app，你必须访问开发者运行的中心化 Web 服务器。每当该 app 向你显示一些数据时，它都是从自己的中心化数据库查询的。如果该中心化基础设施瘫痪了，你就无法访问该 app 或用它做任何有用的事情。

所以所有的去中心化都是没用的！？不！！

不一定。虽然 app 是中心化的，但 数据 并非完全中心化的。在 ATProto 中，你的数据被写入你自己的 PDS (Personal Data Server)，并且该 PDS 可以由任何人托管。因此，如果 app 瘫痪了，你仍然可以在你的 PDS 上拥有你的数据。

与 Twitter 或 Discord 等网站相比，这确实非常好，在这些网站上，你的数据被锁定在平台中，如果不是某些国家/地区的法律赋予你获取这些数据的权利，你可能永远无法再次获取你的数据。

是的，即使如此，他们也会让它变得非常困难。

没错。他们希望你的数据被锁定。在 ATProto 中，当涉及到让你始终可以访问你的数据时，你有很多优势，包括提供一个标准的 API 来获取这些数据。

即使 Bluesky 今天运行着大多数 PDSes，情况也不一定是这样，而且时间可能会改变这一点。

因此，PDS 为我们提供了去中心化的数据，而 apps 为我们提供了对这些数据的中心化视图。

PDS 的重要性

这是我想更多关注的一点：PDS 有多重要。

给予人们自己的 PDS 对于拥有一个自由（如自由）的互联网至关重要。这需要是我可以：

最后一点对于所有这些不同的 ATProto apps 的存在至关重要。我们正在给予人们他们自己的数据存储，然后让他们将其连接到各种不同的工具和体验。

这里的潜力是巨大的！我们需要个人数据存储。

由于它们，现在不是只有一个 app 让我们“拥有”我们的数据，而是_所有_这些 apps 都让我们拥有我们的数据。使这种基本能力（这种控制我们自己数据的权利）成为主流，对于恢复人们的互联网自由至关重要。

Bluesky 的重要性

我认为“主流”的重要性也需要引起一些关注。Bluesky 正在变得比大多数其他“去中心化” apps 最终变得更加“正常”。

Bluesky 旨在创建一个不妥协的类似 Twitter 的体验，但在其协议中内置了重要的自由。这种在用户体验上的毫不妥协对于它获得 3000 万以上的用户至关重要。

但他们不是有点谎称它是“去中心化”的吗？

我认为他们尽了最大的努力，很好地解释了他们正在做什么。再说一次，语言有点不足以表达我们想要表达的东西。

即使 Bluesky _公然_谎称它是去中心化的，我也没有说他们这样做，我认为让这么多普通人使用一个在根本上具有更多开放和自由保护技术的 app，是非常重要的。

我坚信我们可以制作出具有出色体验并且对普通人真正有用的去中心化 apps。我认为几乎没有任何类似的东西存在是一种巨大的耻辱。Bluesky，无论它是否 100% 去中心化，都已开始传播这样一种说法，即不仅好的去中心化 apps 是可能的，而且它们也很重要。

他们正在积累的网络也在引发一场开发雪崩，希望利用其潜力。这些开发工作正在继承至关重要的个人数据存储。

但是中心化！

好的，所以我们有去中心化的 PDSes，很好，但是你说 apps 是中心化的。如果我的数据在我的 PDS 上，但我无法用它做任何事情，因为 app 消失了，这有什么关系？

让我们举个例子：Omnivore app。

Omnivore 是一个开源的稍后阅读 app。他们运行了一段时间的免费云服务，在 GitHub 上有 14.4k 颗星，很多人喜欢并使用该 app。

但最终，它背后的团队被收购了，用户收到了一份简短的通知，称该服务将永久关闭。该项目将保留在 GitHub 上的开源，但是所有不会自己托管该 app 的普通人都将无法再使用它。

用户有机会以 JSON 格式请求所有已保存帖子的 zip 压缩包，但就目前而言，还没有什么好的方法可以使用它。

这太糟糕了！但是 ATProto 将如何防止这种情况发生？如果公司倒闭了，app 就会消失。

好吧，如果 Omnivore 是一个 ATProto app，并且他们关闭了他们的服务器，所有用户仍然会将他们的数据以标准格式存储在他们的 PDS 上。到那时，任何其他开发者都可以进入并运行另一个 app，甚至在它是像 Omnivore 这样的开源的情况下，也可以运行相同的 app，并在你登录时访问 所有 PDS 上已有的现有数据。

哦，和 Omnivore 不同，因为所有数据仍然在 PDSes 上，所有用户再次设置所要做的就是登录到新的 app。他们甚至不必创建一个新帐户或任何东西！

完全正确！这使得有人介入并“拯救” app 变得 容易得多。

即使没有人站出来运行可以运行你的 RSS 订阅等的完整服务，也可以创建一个免费网站，让你登录到你的 ATProto 帐户并_查看_所有你的 Omnivore 数据，以便至少你有一种方法可以使用剩余的数据。

所有这些都由标准化的个人数据存储提供支持。

身份

这把我们带到了 ATProto 所做的另一件 超级重要 的事情：他们已经将登录提供商去中心化了。

等一下！ATProto 不是第一个这样做的。

不，他们不是，但是再说一次，我回到“主流”因素。虽然还有其他东西，比如 Solid OIDC 和 Web Sign-in 让你使用你自己的域名登录，但 ATProto 使它变得更加“正常”。

当有人让你“使用 ATProto 登录”时，与“使用 Google 登录”按钮不同，它实际上让你使用你_自己的_ PDS 登录。

使用你的域名作为 handle 也 非常重要。这意味着仅仅通过输入我们的 handle，我们正在通过 DNS 透明地通知该服务，谁负责让我们登录。

“使用 Google 登录”按钮非常_有用_，但对 Web 的自由来说却如此可怕。为什么 google 可以成为我们所有 Web 登录的守门人？

我们需要一个替代方案，但它也需要简单，并且通过使 handles 成为域名，并使普通人可以使用和理解它，他们已经使实际上去中心化的社交登录按钮成为可能。

将 身份 链接到你的 个人数据存储 并使用 域名作为 Handles 是一种_至关重要_的组合，它真的开始释放 Web 自由。

更多的 PDS 提供商

但是 Bluesky 托管了几乎所有人的 PDS。这就是为什么它如此简单。我们怎么知道将来是否会有其他人为人们托管 PDSes？如果每个人只使用一个提供商，那么去中心化登录并没有帮助。

这是一个很好的观点，而且我们_确实_需要更多的人托管 PDSes。但我有充分的理由相信，很快就会有更多的服务托管 PDSes。

原因是 onboarding。

当今天大多数人制作 ATProto app 时，他们通常只是让你使用 Bluesky 登录。Bluesky 已经提供了 PDS，而且大多数对你的 app 感兴趣的人可能感兴趣是因为他们已经在 Bluesky 上了。

但并非对每个人都如此。我们 Muni Town，以及我交谈过的其他一些 ATProto 项目开发者，都在考虑托管 PDSes，以便用户不需要 Bluesky 帐户才能加入。

我们希望人们能够直接注册_我们的_ app。他们不应该_需要_使用 Bluesky 登录，但是如果他们想这样做，那也没关系。

如果我们托管 PDSes，那么我们可以让用户直接注册我们的 app。

我们的 app 会给他们一个域名 handle，就像 Bluesky 一样，而它的酷之处在于，他们可以使用我们 app 的 handle 登录到任何 ATProto app，包括 Bluesky！

哇！这很棒！

不是吗！最棒的是，对独立注册的渴望为更多 apps 启动 PDS 服务提供了自然的激励。

越多的认真 apps 开始在 ATProto 上构建，并且不希望要求 Bluesky 帐户，就可能有越多的服务开始提供 PDS 托管。

所有这些 apps 都让你将你自己的 PDS 带到任何其他 apps！

无需 Relay！

好的，这太酷了，但是 relay 呢？我听说很多人说 relay 太中心化了，而且对于任何人来说，真正运行自己的 relay 都太昂贵了。

围绕 Bluesky relay 以及是否可以“缩小” ATProto 存在很多争论。

幸运的是，随着 Bluesky 和 ATProto 最近受到的所有关注，人们对运行替代 relays 非常感兴趣，以防情况变得糟糕，而且我认为，为了防止 Bluesky relay 潜在的故障或妥协，为公共利益 relay 提供资金可能会实现。

但我也想提请注意 ATProto 的另一个不明显的事情：relay 不是必需的。

让我们做一个思想实验。假设我们正在制作我们自己的稍后阅读 app，称为 Herbivore。

还记得我说过 ATProto apps 基本上是普通的 Web apps 吗？从技术上讲，可以使 Herbivore 这样工作：你使用 ATProto 登录，然后在那之后，它是 100% 典型且中心化的。

所有数据都存储在 Herbivore 服务器上，并且在你登录后基本上完全忽略 ATProto。这将利用身份方面的东西，而不是 PDS。

现在让我们添加一个功能：我们所有的数据都“实时备份”到我们的 PDS。

在那时，我们有一个基本上“正常的” Web 应用，我们可以在其中使用 ATProto 登录，并且我们所有的数据都存储在我们的 PDS 上，但是不需要 relay。

有意思...有什么问题？

问题在于它与其他 apps 的交互方式。例如，假设有另一个 app 称为 Carnivore。它的工作是帮助我们删除我们不再需要的旧的 Herbivore 数据。

如果我们登录到 Carnivore 并使用它从我们的 PDS 中删除一条记录，如果没有 relay，Herbivore 不会立即知道我们的 PDS 已被修改。因此，如果我们重新登录到 Herbivore，我们将仍然会看到我们使用 Carnivore 删除的数据。

这是一个问题。

也许有时，但并非总是如此。

例如，也许 Herbivore 可以在我们每次登录时检查我们的 PDS 是否已同步。或者可能存在定期刷新。

Herbivore 可以公开一个 API endpoint，其他 apps 可以使用它来要求它刷新其数据。

或者更好的是，也许它可以在 relay 可用时使用 relay，但如果 relay 不可用，仍然可以回退到另一种刷新机制。

Herbivore 可以运行它自己的 relay，该 relay 仅订阅 Herbivore 用户吗？

我不确定！我认为这里有探索的空间。

他们已经有了 Jetstream，它就像一个过滤的 relay，但它仍然依赖于 Bluesky 的 relay 服务。

也许我们需要一些协议或 PDS 更改，才能实现对 PDS 上单个用户的更轻量级的订阅，或者也许我们已经可以尝试一些我们尚未想到的事情。

我希望看到更多对此的调查。

Local First + ATProto

这让我想到 Muni Town 已经开始使用 roomy.chat 的解决方案：将本地优先技术与 ATProto 相结合。

我们正在制作一个工具包，用于构建可以离线工作并有效地将其数据同步到其他 peer 或服务（包括其 ATProto PDS）的 apps。

我们仍然会有一个中心服务，可以帮助用户实时同步聊天消息和其他数据，但它也是一个社区可以自己运行的服务，并且他们可以轻松地将他们的数据从一个提供商转移到另一个提供商。

用户数据存储在我们自己的一种“个人数据存储”中，与 ATProto PDS 不同，它旨在有效地进行 peer-to-peer 同步。

最棒的是，我们仍然可以利用 ATProto 在身份和 PDS 作为你的所有数据都已备份并且始终可以访问你的地方方面的优势。

不是一个花招

我试图通过这篇文章表达的很多内容是，有一种以上的方法可以利用 ATProto，并且它已经开始正确地做一些我们现在真正需要的重要事情。

我们习惯于存在多种制作 Web app 的方法，即使你是在 ATProto 上构建它也是如此。它没有设定很多固定的东西，它只是给了我们一些我们可以共享的砖块。

"AppView" 是 ATProto 架构的一个组件，你可以几乎完全自由地使用它。它可以是你想要的任何东西，而且我认为那里有各种未开发的可能性。

你甚至可以使用有意义的 ActivityPub 集成来制作一个 AppView，或者可能借用有关收件箱和发件箱的想法来替代 relays。

因此，也许 ATProto 可以让你制作中心化 和 去中心化的 apps。

是的。我已经关注 ATProto 一年多了，当我发现它时，我绝对没有在任何方面相信它。我当然仍然没有把一切都押在它上面。

不过，我逐渐看到我真正相信重要的一些原则实际上比我想象的在 ATProto 中保持得更好。ATProto 不是我想象的那样。

它仍然不完美。我们整个 Local First + ATProto 的想法甚至没有以一种通常被认为是好主意的方式使用它。我们仍然不确定我们的计划可能会如何改变，而且我们正在积极地保留我们独立于 ATProto 进行部署的能力，如果我们需要这样做。

但是这里有很多好的东西，有时很难看到。

当你阅读协议的所有技术细节并看到现有 apps 在其上的所有特定设计时，很难看到还有哪些其他可能性以及还有哪些东西有待尝试。

最后的犹豫

哦哦，它来了，我知道会有另一个问题。

嘿，是的，我在 ATProto 中看到的最后一个大问题是我不舒服的 plc.directory。

PLC 目录是几乎所有 ATProto 用户使用的用户身份的中心化数据库。

它为你提供了一个永不改变的永久标识符，即使你的 ATProto handle 改变了。

它让你在你的 ATProto handle、PDS 提供商和其他身份关键的改变（如你的轮换密钥）改变时告诉网络。这是大多数人不需要考虑的事情，但对于 ATProto 的工作至关重要。

它几乎完全没问题且安全，除了控制 PLC 目录的人在技术上可以拒绝你对你的 PDS 或 handle 之类的事物的更新这一事实。

这并不意味着他们可以伪造对你的帐户的更新，因此，例如，他们无法说服世界说你在你没有更改 handle 时更改了你的 handle。

但是他们能够拒绝你与网络分享你更改了你的 handle 的能力，如果你想这样做。

例如，如果你想将你的 PDS 更改为非 Bluesky 托管的 PDS，你可以使用一些工具创建一个签名记录，说明你想切换你的 PDS。

但是，从技术上讲，Bluesky 有权完全忽略你的更新记录并且不与任何人分享它。实际上，他们锁定了对你的身份的更改。

我们需要一些后备方案来防止这种情况发生。人们一直在谈论将 PLC 目录的权力移交给像 IETF 这样的组织，这会有所帮助，但在我看来仍然不够。我觉得我们需要一个选项来使用替代目录或类似的东西。我们需要一种即使有人接管目录也能保持我们的身份的方法。

有人提出了一个 proposal 来帮助为目录提供一个逃生舱口，而且我觉得这里也有其他可能性值得探索。

因为，从根本上讲，这些记录是我们身份上的一系列签名操作。即使目录拒绝了我的更新，它仍然是签名且有效的，我可以去其他地方分享该签名记录。我甚至可以把它发布到 bluesky！

一旦人们发现我的签名更新，他们就会知道目录不是最新的，并且我的记录现在可以从其他地方查找？

听起来你没有任何可靠的想法。

不，我没有。我没有时间做必要的研究来实际有一个想法，但我确实认为这很重要，而且这是我感到不舒服的 ATProto 的最大部分。

其余的部分，比如 relays，在很大程度上是可选的，至少在我可以尝试其他东西的方面是如此，但是对于 PLC 目录来说，这不太正确。

did:web 呢，ATProto 不支持吗？

它支持，但是使用 did:web 作为你的身份基本上意味着你必须永远保持对该域名的所有权，这并不总是现实的。它只是转移了问题。

另一个有希望的可能解决方案是 did:webvh，但我也没有时间正确地研究它，所以我不知道它是否是一个合适的解决方案。

结束语

好吧，你完成了吗？我怀疑是否有人真的坚持了足够长的时间来阅读这么远。

是的，差不多完成了，而且，我的意思是，你坚持了下来，所以你永远不知道。

这很公平。

我对 ATProto 感到暂时性的兴奋，并且很高兴能够尝试在其之上进行构建。我希望以这样或那样的方式从中产生一些真正的好处。

下次再见，再见！ 👋

再见！ 👋

Charlie 的照片已获得公共领域 (CCO) 许可，可以在 SVG Repo 上找到。