每个人，在这个宇宙里都有一颗对应的星星在闪烁。
阿瑟・克拉克《2001: 太空漫游》
引言#
由于马斯克在 Twitter 转换 𝕏 的过程中一些充满争议的举动，大量的用户选择从 Twitter 迁移到 Mastodon，Threads 等平台，联邦宇宙（Fediverse）这个词逐渐进入大众的视野，同时哪怕是 Threads 也宣称自己将在将来支持 ActivityPub 协议以实现互联互通以及加入联邦宇宙（甚至还引起了联邦宇宙社区的一系列讨论）。
2024 年 2 月 6 日，Bluesky 宣布结束自 2021 年以来的公测，用户可以无须邀请码便可注册。1作为由 Twitter 联合创始人的团队创建的联邦宇宙的后起之秀，Bluesky 未采用目前联邦宇宙流行的 ActivityPub 协议，而是采用自己带头开发的 AT 协议（AT Protocol or @ protocol, Authenticated Transfer Protocol）。
关注联邦宇宙时长超过两年半 的我，本着好奇心理浏览了 AT 协议 的相关内容，以 一起入坑 相互分享的精神，用这篇不像论文不像报告也不像博文的文章来记录对 AT 协议 的思考和理解，由于水平有限，仅供参考，并欢迎指正与交流。
初步印象与对比#
可能这个比喻不是很恰当，但如果拿区块链的发展作为类比的话，个人以为以 OStatus 为代表的协议类似于曾经亚当・贝克的 hashcash，ActivityPub 则类似于 Bitcoin，而 AT 协议 有种类似于 Ethereum 和 EOS 的感受。
如果之前有在 Mastodon 之类的基于 ActivityPub 协议的 联邦宇宙 实例(Instance)的话，或许会对 实例 之间的互联性的缺陷有所了解：无法做到在原有域名已经停止工作的情况下迁移到新的域名，在与其他实例的互动时只能显示自己所在实例已经联合的实例的互动；如果曾经运维过这样的 实例 的话，可能还会对 联邦宇宙 的烧钱有所感受（这也成功让 Hetzner 之类的 IDC 成为联邦宇宙超过半数的实例托管服务选择，戏称联邦宇宙首都），以及既要做技术又要做管理的疲惫。当然，这并不阻碍 ActivityPub 成为 联邦宇宙 非常优秀的协议之一，但这些 bug 总会让人思考有无办法改进。
2023 年，Nostr 为代表的基于 区块链 的 Web3 社交由于以爱德华・斯诺登为首的推广而逐渐「火出圈」，一时 Twitter 上流行一串串「神秘代码」。Nostr 将区块链引入社交平台为其增添了价值层（或激励层），通过 DHT 等 P2P 协议实现了节点的互联互通。然而，由于 Nostr 的设计理念，导致其缺乏对信息筛选过滤的内在机制，由于目前跨链机制的缺乏以及运营链或节点的高昂成本和风险，导致用户基本集中于 Nostr 主链，并且 Nostr 的「神秘代码」也显示出该社交方式的缺陷：缺乏易读性。计算机对解读 Hash 是家常便饭，然而绝大多数人类无法记忆大量充满随机字符串的 Hash 地址。虽然例如另一种基于区块链的 Web3 社交尝试 Farcaster 以及个人曾经体验过的 `Status`` 等项目尝试通过 ENS 等人类友好方式进行映射，然而 ENS 的较高成本阻碍了用户的参与。
此外，无论是 ActivityPub 还是类似于 Nostr 与 Farcaster 的实现均采用绝对的时间轴与关注推送，这固然避免了由于平台单一算法导致的 信息茧房，但却导致了另外的问题。由于用户的精力是有限的，ActivityPub 的思路是优先考虑推送（甚至是只推送）本 实例 以及联合的 实例 的信息，在发现信息时需要用户对时间排序的信息进行筛选，将筛选成本转移给了用户；而 Nostr 之类的亦采用时间轴强相关机制，但由于主链的集中性导致信息溢出超过任何采用 ActivityPub 协议的大 实例，从 信息茧房 演变成 信息爆炸。ActivityPub 协议的设计使得用户实际上对信息只能采取一刀切的 屏蔽，亦或是等待 实例 管理员对信息的删除或阻拦，而未考虑到可能的减少推送需求；Nostr 则情况更糟，大量的信息导致用户如果探索时间轴时，接近无法屏蔽，且导致无论是基于客户端的过滤亦或是基于人工的审查变得异常困难。
AT 协议的架构#
AT 协议 设计的巧妙在于，将数据存放，推送与发现，筛选与过滤，以及用户可以接触到的界面进行了分离，并做到了开放，友好，容灾且易于迁移以及可扩展性。
正如 Bluesky 在论文中阐述的：AT 协议的设计参考了当今的互联网，2 网站不应该全部必须承担互相发现，联合整个互联网的所有网站的责任，也不应该全部必须承担对整个互联网的筛选和过滤工作。可以说万维网是目前最成功的去中心化自治组织，在其基础上进行参考无疑是非常明智的，并大大减少了思维量与工作量。互联网拥有 硬件，软件，以及标准，AT 协议 的设计可以说也有 硬件，软件，以及 标准，不过也正如互联网借助虚拟化与容器技术使得软硬件的界限逐渐模糊，可以预见 AT 协议 的软件与硬件 等在将来也不会局限于原来的标准实现，而可能出现融合和扩展的情况。
硬件#
假设将 AT 协议 中的 硬件 定义为对于互联网中传统硬件的部分，那么在 AT 协议 官方标准实现中，个人数据服务器（Personal Data Server，PDS），中继（Relay）与应用视图（App View）3 可以说是 AT 协议 的 硬件。
个人数据服务器 (Personal Data Server，PDS)#
个人数据服务器 顾名思义是存放用户数据的地方，在之前的 ActivityPub 实现中依靠的是各个 实例，但在 AT 协议 的设计中，个人数据服务器 相当于万维网中的服务器，只需做好存放相关数据的实现就可以了，大大减小了性能要求以及成本，甚至可以在家用 NAS 以及树莓派上搭建，可以遇见这将使依靠 AT 协议 构建的去中心化网络整体由于更多节点的加入而更加健壮。同时，正如互联网中通过虚拟化技术使得一台独立服务器可以承载多台虚拟服务器一样，个人数据服务器 也可以聚合运行而提供服务，例如 Bluesky 官方运营即为目前最大的 个人数据服务器 聚合体，类似于云计算中的 IDC。
中继 (Relay)#
中继 则类似于互联网中的 网关 与 路由，作为 个人数据服务器 之间联系的中介。 中继 的第一个组件是中继器，负责抓取已知的 个人数据服务器 的推送数据并进行数据校验，丢弃校验失败的数据并初步过滤高频的垃圾信息。中继 将这些数据通过 中继器 进行聚合后创建 管道（Firehose），3 管道 由 应用视图 进行 接收（Consume），3 这样做的好处是相对于分别订阅多个 个人数据服务器，通过 管道 聚合信息大幅降低了 个人数据服务器 以及 应用视图 的请求数，并且可以通过基于时间戳的 Merkle 树 进行校验。类似于互联网中负责运营线路以及网关的运营商较少，运营 中继 是 AT 协议 所有节点中成本最高，预计数量较少的部分。
应用视图 (App View)#
应用视图是用户感知最明显的组件，类比于互联网的话，可以比作接入互联网的终端，或者更形象的 APP（应用）。应用视图 通过 接收 来自 中继 的 管道，然后按照 词典 处理相应记录，在 Bluesky 中对应于统计每篇帖子的点赞数，整理帖子的回复线程，维护每个用户的关注者集合并为其构建包含关注用户所发帖子的时间轴，同时对信息中解析媒体文件的地址并将解析后的文件（必要时进行一定的处理，例如压缩）递送至用户。正如现在联网的应用几乎本质上都是基于 TCP 或 UDP 进行通讯的一样，应用视图 也是基于 AT 协议 进行通讯。然而，TCP 与 UDP 只是提供通讯的协议，而传输内容的输入，解析与输出则依靠 APP 一样，基于 AT 协议 可以开发出类似于万维网生态的诸多应用，目前最大的应用是 Bluesky 这一微博客平台，但可以遇见在未来类似于现有联邦宇宙中的诸多 应用视图 会被开发出来。
软件#
同样的，将 AT 协议 中的 软件 定义为对于互联网中传统软件的部分，在 AT 协议 官方标准实现中，馈送生成件（Feed Generator），标记件（Labelers）3 可以说是 AT 协议 中的 硬件。
馈送生成件 (Feed Generator)#
网站的目录与搜索，更多依赖的是 搜索引擎 以及其算法，对应的，AT 协议 中的 馈送生成件 起到的便是索引和进行有选择的推送的作用，正如用户可以自由选择以至于自己写搜索算法并建立搜索引擎，用户亦可以自由选择以至自建 馈送生成件，Bluesky 在 Github 也提供了方便的启动工具包。4而且类似于 SearXNG 可以选择并聚合搜索引擎的信息，用户亦可以在 应用视图 中选择并聚合 馈送生成件，来获取与探索信息，仅需点击添加即可，就像在应用商店下载 APP 一样，或者说大量的 馈送生成件 形成一种 算法市场 本身便是 AT 协议 的愿景。
标记件 (Labelers)#
对于网站内容的过滤与筛选，更多是 广告拦截 以及欺诈保护，或者说防火墙，AT 协议 中的 标记件起到的也是类似的作用。正如用户可以订阅与叠加不同的 广告拦截 规则，用户也可以使用不同的 标记节点以给数据打上标签，实现更精细化的筛选和控制，照顾到了不同用户的不同需求，同时使得运维与管理工作可以有效分开。
标准#
继续按照刚才的定义，将 AT 协议 中的 标准 定义为互联网中传统标准的部分，在 AT 协议 官方标准实现中，DID（Decentralized Identifiers，去中心化标识），Handle（句柄），Repository（存储库），以及 Lexicon（词典）3 可以说是 AT 协议 中的 标准。
标准 的背后，是 AT 协议 的数据模型。AT 协议 应用了多种资源标识规范，目前包括 DIDs（Decentralized IDs），CIDs（Content IDs），NSIDs（Namespaced Identifiers ） 和 rkey（Record Keys）。5
DID (去中心化标识)#
由于 AT协议 的身份标识系统设计过于精彩，因此单独拎出来（bushi）
好吧，其实只是因为篇幅比较长，不过设计确实很巧妙。
DID 粗看起来类似于互联网中的账号系统，然而个人认为其更类似于互联网中对 域名 的实现，并很大程度上参考了互联网的证书派发机制。准确来说，DID 并不是 AT 协议 的原创发明，真正的发明者是 W3C，而且目前拥有数百种 DID 方法（可见人类善于折腾）。6 AT 协议 的开发者经过讨论后决定只采用 did:web 方法与 did:plc 方法以更好的 避免加班 符合需求。
DID 的巧妙之处在于，它不是简单的字符组合，而是可以通过类似互联网中的 DNS 记录解析的机制将 DID 解析为一个被称为 DID 文件（DID Document）3 的 JSON 数组（本质上还是字符组合）。DID 文件 在 AT 协议 中遵循 Merkle 树 规范以保证不可篡改与可验证性，因此 DID 文件 的 Merkle 树 会随着时间的推移和操作的进行而逐渐增长。
然而因此 DID 大多采用基于哈希的压缩机制，使得 DID 很多时候看起来像随机字符的组合，对人类并不友好。对此，AT 协议 的开发者采用 Handle 的方式解决了这一问题，通过人类友好的域名机制，以 TXT 记录或是 /.well-known/ 路径的 https 方式（熟悉 Let's Encrypt 之类的免费 SSL 对这个路径应该不陌生）来建立互联网中的域名与 DID 之间的映射。因此，Bluesky 中用户名为 @xxx.com（同时间接解决了蓝 V 认证问题，只要 example.com 为某个人或者某个组织的官方网站，那么相当于得到了认证，将认证的责任转移给了 ICANN）
did:web 方法的实现便类似于 Handle 机制，这个时候用户的 DID 就是域名，解析 DID 返回 JSON 数组的机制便是通过查询域名对应的特定 TXT 记录，返回值便是 DID 文件（这种情况可以把「类似」去掉，真的就是 DNS 解析 /doge），或者通过 https 方式访问 /.well-known/ 路径获取 DID 文件。这样做将 Handle 与 DID 结合在了一起，也做到了人类友好，然而缺点在于，这样作为 DID 与 Handle 的域名由于 DID 的不可变性也是不可变的，但现实中很容易遇到域名更换等事件。同时，伴随着每次 Merkle 树 的增长，需要对 TXT 记录或 /.well-known/ 路径进行手动更新，这在大规模的应用中显得低效，并可能因为网络环境的不同而导致更新无法及时传递以及可能的劫持。
did:plc 方法便是为了解决以上痛点。之所以叫 did:plc，是因为开发者本来是把这作为「占位符（Placeholder）」，不过很明显现在不是了， 而且不必担心 did:plc 的未来，因为 AT 协议 在 DID 的相应实现中提供了向后兼容性以避免可能的存在 DID 方式增添导致的原有方式失效。did:plc 方法采用 did:key 中的 secp256k1 与 NIST P-256 算法实现 DID 文件 的加密与压缩，具备原生的加密特性。
did:plc 的请求过程为：向 PLC 服务器（PLC Server）发送请求，3 PLC 服务器 查询是否已经注册，如果已注册则返回状态码并在需要时返回 DID 文件，如果是对 DID 的更新操作，PLC 服务器 便通过验证机制以进行判断。PLC 服务器 亦在 DID 出现分叉时进行判断保留哪一个版本。PLC 服务器 有多种验证机制可以选择，可以采用 ddi:plc 自带的轮换密钥对进行校验，亦可采用由 PLC 服务器 代托管 签名密钥对并采用传统的邮箱 - 密码等机制进行校验（例如 Bluesky 的官方 PLC 服务器），做到了便利与安全的可选与均衡。
DID 的应用让 AT 协议 中的数据迁移变得异常容易，用户只需对自己的 DID Merkle 树 进行更新，新增 个人数据服务器 变更的记录，并将原 个人数据服务器 中的媒体文件备份转移至新 个人数据服务器，哪怕原来的 个人数据服务器 已经彻底跑路，也仍然可以保留原来的社交关系网。同时，通过 did:plc 以及扩展的 Oauth 2.1 之间的结合，甚至还可以做到使用 AT 协议 登录兼容相应 Oauth 标准的应用。7
Lexicon （词典）#
如果在基于 ActivityPub 协议的 联邦宇宙 游玩过的话，应该对一些不同项目之间的区别有所印象：例如，Mastodon 对一条帖子只有点赞 这种操作，但 Misskey 可以有多种表情进行回应。无论是 Mastodon 亦或是 Misskey 都采用 ActivityPub 作为互联互通的协议，但是如果要让 Mastodon 支持 Misskey 的表情回应，需要进行的工作是对整个 Mastodon 项目的修改。这种设计并不是很优雅，而AT 协议 的 Lexicon 的设计则以很优雅的方式解决了这种问题。
Lexicon 的架构语言参考了 JSON 和 OpenAPI，笔者个人感觉 NSID 起到类似 Android 包名的作用，而 rkey 有些类似于一个个 Activity。NSID 这一命名空间机制让 Lexicon 更加易于扩展，并且使得基于 AT 协议 开发项目只需考虑如何设计 Lexicon 以及 应用视图 的对应元素即可，让 联邦宇宙 的互联互通与互操作性从未如此便利。
Repository （存储库）#
如果对 IPFS 有所了解的话，看到 CID 应该会有种熟悉的感觉。感觉没错，AT 协议 的 Repository 遵循 IPLD 规范，并通过 Git 的 Merkle 树 机制实现了版本控制功能。对于 IPLD 规范的内容寻址，避免重复数据，以及 Git 和 Merkle 树 的签名校验和版本控制等等优势在此不做重复阐述。
结语#
可以说，AT 协议 的发展，站在了无数巨人的肩膀上，从随处可见的互联网元素在其中的映射，到嘴上说自己不是区块链，8 身体却很诚实的对 Merkle 树 的大量成熟应用，再到前所未有的推送可自定义性上可以看到的 RSS 的影子，以及 Git 在数据模型中的应用，AT 协议 从 Twitter，ActivityPub，Nostr 等踩过的坑中吸取教训，不断发展，后来居上，成就了目前 Web3 社交协议中最有希望的形态。
目前的 AT 协议 的应用仍存在较为中心化的现象，Bluesky 仍然是许多情况的唯一选择，但如果按照 Bluesky 的声明发展下去的话，AT 协议 将会越来越开放，而且可以预见 AT 协议 优异的特性将吸引众多开发者，未来生态可期。有种奇妙的感觉，𝕏 宛若当年的网景公司，而从其中走出的 Bluesky，希望可以成为 Mozilla 一样的开放组织，推动技术朝更加开放，透明，公平与互联互通的方向发展。
原文地址：https://blog.iceyear.eu.org/atprotocol-study