ATProto: 為什麼沒有「實例」

ATProto 與 Mastodon 等聯邦式網路（federated networks）的根本區別在於，ATProto 並不使用「實例」（instances）。雖然聯邦式社交網路依賴於耦合的託管與應用程式邏輯，但 ATProto 將這些功能分離，讓使用者能夠在不失去身份或社交圖譜的情況下更換託管提供者。

將託管與聚合分離

ATProto 的設計是一個將託管（hosting）與聚合（aggregation）視為兩個獨立網路層級功能的系統。在傳統的聯邦式系統中，「實例」是託管與應用程式本身的組合包。相比之下，ATProto 將數據託管視為一個基礎層，應用程式則從中進行聚合。

這種架構反映了早期網路的 RSS 與 Google Reader 模型：使用者在自己的部落格（託管）上發布內容，並使用聚合器應用程式（例如 Google Reader）來查看該內容的合併饋送（feed）。在 ATProto 中，應用程式是網路中託管數據的「投影」（projection），而非數據存放的地方。

比較：聯邦式 vs. ATProto

聯邦式實例 (例如 Mastodon/ActivityPub)

在聯邦式模型中，使用者「屬於」特定的實例。身份與他們加入的伺服器綁定，這會產生幾種結構性的依賴：

• 身份綁定： 使用者的身份通常是不可變的，且與伺服器綁定（例如 user@instance.com）。
• 依賴管理員政策： 如果兩個實例的管理員決定停止聯邦化（defederation），無論使用者個人的意願如何，這些實例上的使用者將無法再進行溝通。
• 單點故障： 如果一個實例關閉，除非手動遷移，否則使用者的身份與數據通常會隨之消失。
• 擴展複雜性： 隨著實例之間必須建立協議來在彼此之間轉發貼文，網路拓撲的擴展複雜度為 $O(n^2)$。

ATProto 模型

ATProto 透過允許託管與應用程式獨立存在，消除了「實例」的概念。這為使用者提供了對其數據更大的自主權：

• 可移植身份： 使用者可以在不改變身份或失去追蹤者的情況下，遷移他們的託管（個人數據伺服器或 PDS）。
• 應用程式多樣性： 因為應用程式只是數據的投影，使用者可以使用不同的客戶端（例如 Tangled 或 Semble）來查看相同的數據，而不會被綁定在 Bluesky 應用程式上。
• 靈活的基礎設施： 使用者可以選擇運行自己的 PDS，或使用社群運行的快取（cache）或中繼器（relay）來聚合數據以提升效能。

技術實作與社群觀點

雖然架構在概念上很優雅，但社群討論突顯了幾種技術權衡與實作細節：

中繼器 (Relays) 與 AppViews 的角色

中繼器充當使 ATProto 具備效能的「膠水」。它們將數據從 PDSes 轉運到 AppViews，減少了聚合器需要查詢的服務數量。一些批評者認為這使得系統依賴於高成本的基礎設施，並指出 RSS 的類比並不完美，因為 RSS 饋送通常比 ATProto 數據饋送更具自給自足性。

一致性 vs. 去中心化

有些使用者認為 ATProto 優先考慮一致性與數據所有權，而非「真正的」去中心化。因為運行內容中繼器比運行 Mastodon 節點更耗費資源，網路的去中心化重點在於個人數據的所有權，而非網路基礎設施的集體所有權。

PDS 作為「事實上」的實例

關於個人數據伺服器 (PDS) 是否僅僅是重新命名的實例，存在著爭議。有些人認為，因為使用者將數據寫入一個規範的 PDS，且發現機制是透過 DNS 進行，因此該架構仍然是客戶端-伺服器模型，而非點對點的分散式資料庫。

"如果它叫起來像鴨子... 一個帳號有一個單一的個人數據伺服器 (PDS)，對吧？DID links 連結到一個 PDS，它是使用者的規範數據饋送... 我不認為將 PDS 稱為實例、將中繼器稱為鏡像（mirror）是一種過度的說法。"

ATProto 方法的總結

ATProto 的核心目標是將使用者數據保留在應用程式之外。透過將數據的託管與社交體驗的聚合分離，ATProto 旨在解決閉鎖平台與聯邦式實例中固有的激勵機制與限制問題。