許多工程師在設計協作應用時，常會陷入一個矛盾：為了讓使用者在多裝置間同步資料，我們必須依賴一個中央同步伺服器。然而，這個伺服器一旦失效或服務商倒閉，整個應用的同步功能就會癱瘓，甚至導致資料無法恢復。這種對單一後端服務的依賴，正是系統韌性的最大弱點。
為了克服這個問題，近期有技術討論提出將 AT Protocol（atproto，原本為 Bluesky 社交網路設計的協議）作為通用分散式應用的基礎設施，而非僅限於社交平台。其核心目標是實現 Local-First（本地優先）架構，讓使用者真正擁有自己的資料，並降低對特定應用後端的依賴。
什麼是 Local-First 與 AT Protocol 的角色
Local-First 是一種設計理念，強調資料優先儲存在使用者本地端，網路僅用於同步與備份。在傳統模型中，資料儲存在應用開發商的伺服器裡；但在 AT Protocol 的模型中，使用者擁有自己的 PDS（Personal Data Server，個人資料伺服器）。
PDS 扮演的是一個通用儲存層的角色，負責處理儲存、細粒度身分驗證以及推送更新。應用程式不再需要建立各自獨立的後端資料庫，而是請求存取使用者的 PDS。這樣做的好處是，即使某個應用程式的開發商停止維運，只要 PDS 還在，使用者的資料依然存在且可被其他相容的應用存取，有效避免了單一故障點。
實作路徑：將 AT Protocol 作為同步層的三種嘗試
為了驗證這個想法，開發者嘗試移除 AT Protocol 中較重的 App View（應用專屬視圖伺服器），僅利用靜態前端、PDS 與 Relay（中繼伺服器，負責將更新廣播給其他訂閱者）來實現功能。
第一種嘗試是協作文字編輯器。開發者結合了 YJS（一種用於共享編輯的 CRDT 框架）與 ProseMirror。在這種模式下，每一次的 YJS 更新都被視為一筆記錄寫入使用者的 PDS，而其他協作者則透過 Relay 即時獲取這些更新。這實際上將 AT Protocol 變成了一個通用的 YJS 同步伺服器。但這類做法的挑戰在於，文件狀態被分散在大量零碎的記錄中，導致其他應用程式難以解析這些資料。
第二種嘗試是協作待辦清單，這次直接使用原生 CRDT（Conflict-free Replicated Data Types，無衝突複製資料類型）記錄。CRDT 是一種特殊的資料結構，允許不同裝置在沒有中央協調的情況下獨立修改，最後能自動合併成一致的狀態。開發者將待辦清單定義為簡單的 JSON 物件，並為每個欄位使用 Last-Write-Wins（最後寫入者勝）策略。當發生併發寫入衝突時，則透過 Compare-and-Swap（比較並交換）邏輯拒絕寫入，強迫客戶端先拉取最新狀態、本地合併後再重新嘗試。這種方式讓資料具備更好的自解釋性，即便不理解 CRDT 邏輯的應用也能讀懂基本內容。
第三種嘗試則是將 AT Protocol 作為 WebRTC 視訊聊天 的信令機制（Signalling）。在 WebRTC 建立點對點連接前，雙方需要交換 ICE Candidates（網路連線候選路徑資訊）。開發者讓發起者將這些資訊寫入 PDS，接收者透過 Relay 監聽並回應，隨後建立直接連線。這證明了 AT Protocol 可以作為分散式應用的控制平面，而將高頻寬的即時傳輸交給 WebRTC 數據通道。
工程實務的啟發與限制
從這三個實驗中可以發現，將後端服務通用化、模組化是提升韌性的關鍵。伺服器應該保持簡單且可替換（Fungible），而不是與特定業務邏輯深度耦合。
然而，這種架構也帶來了新的挑戰。首先是網路穿透問題，在複雜的企業防火牆環境下，純點對點連線常會失敗，仍需依賴 TURN Server（一種用於轉發流量的伺服器）作為保底，這在一定程度上削弱了去中心化的理想。其次是資料粒度與互操作性的權衡：將資料拆得太細有利於同步，但會增加外部應用解析的困難度。
總結來說，AT Protocol 提供了一套成熟的身分驗證與資料分發機制，讓開發者能將重心從維護後端基礎設施，轉移到定義資料格式與前端體驗上。對於追求高可用性與資料主權的 Local-First 應用而言，這是一個值得探索的替代方案。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。