ATProto: 为什么没有实例

ATProto 与 Mastodon 等联邦网络之间的根本区别在于 ATProto 不使用“实例”。虽然联邦社交网络依赖于耦合的托管和应用逻辑，但 ATProto 将这些功能分离，允许用户在不丢失身份或社交图谱的情况下更换托管提供商。

解耦托管与聚合

ATProto 被设计为一个托管与聚合是两个独立的网络级功能的系统。在传统的联邦系统中，“实例”是托管和应用程序本身的集合。相比之下，ATProto 将数据托管视为一个基础层，应用程序随后从中聚合数据。

这种架构模仿了早期 Web 的 RSS 和 Google Reader 模型：用户在自己的博客（托管）上发布内容，并使用聚合器应用（如 Google Reader）来查看这些内容的组合馈送。在 ATProto 中，应用程序是分布在网络中的托管数据的“投影”，而不是数据存放的地方。

对比：联邦 vs. ATProto

联邦实例 (例如, Mastodon/ActivityPub)

在联邦模型中，用户“属于”一个特定的实例。身份与他们加入的服务器绑定，这会产生几种结构性依赖：

• 身份绑定： 用户的身份通常是不可变的，并与服务器绑定（例如，user@instance.com）。
• 依赖管理员策略： 如果两个实例的管理员决定停止联邦（defederation），无论用户个人的意愿如何，这些实例上的用户都无法再进行通信。
• 单点故障： 如果一个实例关闭，除非手动迁移，否则用户的身份和数据通常会随之消失。
• 扩展复杂度： 随着实例之间必须建立协议来转发帖子，网络拓扑的扩展复杂度为 $O(n^2)$。

ATProto 模型

ATProto 通过允许托管和应用程序独立存在，消除了“实例”的概念。这为用户提供了对数据的更大自主权：

• 可移植身份： 用户可以在不改变身份或丢失关注者的前提下，迁移他们的托管（个人数据服务器或 PDS）。
• 应用多样性： 因为应用只是数据的投影，用户可以使用不同的客户端（例如 Tangled 或 Semble）来查看相同的数据，而无需被绑定到 Bluesky 应用程序。
• 灵活的基础设施： 用户可以选择运行自己的 PDS，或者使用社区运行的缓存或中继器（relay）来聚合数据以提高性能。

技术实现与社区观点

虽然架构在概念上很优雅，但社区讨论强调了几个技术权衡和实现细节：

中继器 (Relays) 与 AppViews 的角色

中继器充当了使 ATProto 性能卓越的“胶水”。它们将数据从 PDSes 传输到 AppViews，减少了聚合器需要查询的服务数量。一些批评者认为，这使得系统依赖于高成本的基础设施，并指出 RSS 类比并不完美，因为 RSS 馈送通常比 ATProto 数据馈送更具自给自足性。

一致性 vs. 去中心化

一些用户认为 ATProto 优先考虑一致性和数据所有权，而非“真正的”去中心化。因为运行一个内容中继器比运行一个 Mastodon 节点更耗费资源，所以网络的去中心化侧重于个人数据的所有权，而非网络基础设施的集体所有权。

PDS 作为“事实上的”实例

关于个人数据服务器 (PDS) 是否仅仅是一个改名的实例，目前存在争议。一些人认为，由于用户向一个规范的 PDS 写入数据，且发现机制是通过 DNS 实现的，因此该架构仍然是客户端-服务器模型，而非点对点分布式数据库。

"如果它叫起来像鸭子... 一个账号有一个单一的个人数据服务器 (PDS)，对吧？DID 链接到 PDS，它是用户的规范数据馈送... 我不认为把 PDS 称为实例、把中继器称为镜像是一个过分的说法。"

ATProto 方法总结

ATProto 的核心目标是将用户数据保留在应用程序之外。通过将数据的托管与社交体验的聚合分离，ATProto 旨在解决封闭平台和联邦实例中固有的激励机制和限制。