每個人，在這個宇宙裡都有一顆對應的星星在閃爍。
阿瑟・克拉克《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