在 ATProto 之上進行開發：對權限數據與 Local-First 挑戰的反饋

前言

Luke Kanies 參加了在柏林舉行的 Local First Conference，他發現 ATProto 無處不在，但他認為目前的發展方向與他的目標相衝突，他的目標是構建允許用戶選擇公開或私密分享的應用程式。

Luke 想構建什麼

Luke 想要創建一套評論應用程式套件，可以取代 Yelp、GoodReads、Letterboxd 及類似服務，允許用戶記錄公開、私密或與特定群組分享的評論。

ATProto 的優勢

ATProto 提供了一個具擴展性的身份系統，讓應用程式無需從頭開始構建即可處理身份驗證、追蹤者和社交圖譜，這是會議上多位講者都提到的功能。

僅限公開的限制

目前 ATProto 僅限公開：它假設用戶所做的一切都會向全世界發布，這種設計已內置於其存儲系統和發布服務中。

權限數據設計問題

社群的「permissioned data」（權限數據）提案為私密數據創建了一個獨立的系統，迫使開發者必須維護兩個平行的數據存儲和協議。

"在深入探討之前，這一切的核心線索在於，公開廣播數據與權限數據有實質上的不同。" — Luke Kanies Luke 並不同意這一點，他認為無論誰可以閱讀，評論都是同一份數據；唯一的區別在於權限集（全世界可讀 vs. 有限讀取）。 由於該提案將公開和私密數據視為不同的東西，在兩者之間移動記錄需要刪除並重新創建它，從而導致點讚、轉發和連結的遺失。 開發者還必須向用戶隱藏這種雙系統的複雜性，因為用戶看到的應該是像「餐廳評論」這樣的單一概念。

Local-First 與離線支援

Luke 對 Personal Data Server (PDS) 運作方式如同 Git 儲存庫的假設是不正確的；PDS 是透過協議訪問的遠端伺服器，而不是你可以 push 和 pull 的本地副本。 ATProto 僅符合部分 Local First 原則：它缺乏「數據就在指尖下」和「選擇性使用網路」的特性，要求開發者構建自定義的離線存儲和同步系統。 將離線支援與權限數據的分離結合起來會導致：

• 用於離線數據的自定義本地存儲
• 必須對公開和私密數據使用不同協議的自定義同步系統
• 線上應用程式使用也需要為每種數據類型提供獨立的讀寫路徑

社群反饋（精選評論）

"Luke 對權限數據提案的反饋非常有趣。目前的提案在權限方面有一種位置元素，記錄的 URI 反映了訪問控制..." — @pfraze "閱讀像這樣的文章，我確實認為人們正試圖將方釘（他們的應用程式）塞進圓孔（ATProto）。ATProto 的設計初衷是所有數據都是公開的..." — @ekosz "退一步說，很明顯權限數據是由現實世界的用例驅動的（Bluesky 需要私訊，Tangled 需要私密儲存庫等）。然而，我認為與現有 atproto 的協同效應必須非常顯著，才值得開發另一個加密空間規範。" — @sbt "這位作者說出了我的心聲！...它應該直接稱為「私密數據」...權限就是全世界可讀。" — @verdverm

結論

Luke 對 ATProto 的身份基礎仍感到興奮，但他認為目前提議的權限數據設計與 Local-first、混合公開/私密的應用程式背道而馳。他希望該協議能向統一模型演進，即數據本身是相同的，僅訪問權限不同，從而讓開發者能夠構建他所構想的應用程式，而無需與協議的核心假設作鬥爭。