Lazaroff在演讲中分享了他开发的旅行规划应用，该应用使用YJS库与托管同步服务器实现数据协同。然而，一年后，这家同步服务厂商被收购并关停了服务，导致应用无法在本地运行，只能退回到手动传输文件作为替代方案。这个例子展示了协同基础设施与系统抗毁性之间的矛盾：实现多设备数据互通的同步服务器恰恰成了这款应用最脆弱的依赖项。随后，他介绍了一种替代架构模型——atproto，这种模型中应用不再维护独立的后端，而是由每位用户将数据保存在自己的PDS中，并向应用授予访问权限。
--91likeyou---
演讲的主体部分介绍了三项完全舍弃 App View、仅依赖静态应用、PDS 和中继的实验。在第一项实验中，Lazaroff 使用 YJS 和 ProseMirror 构建了一个协作文本编辑器。每个 YJS 更新都作为一条记录写入用户自己的 PDS。协作者信息存储在一条元数据记录中，各节点通过中继近乎实时地获取并复制彼此的更新。他表示，这实际上是将 atproto 作为 YJS 同步服务器。这种方法的主要挑战在于文档状态分散在许多记录中，导致其与其他应用的互通适配难度大幅提升。
第二个实验使用原生 CRDT（无冲突复制数据类型）记录实现多人协作待办清单。这些记录是包含 $type、listId、text、done 和 createdAt 等字段的普通 JSON 对象，CRDT 元数据则单独附加存储。Lazaroff 认为，即便应用不读取 CRDT 元数据也能正常解析内容。该方案为每个字段采用最后写入优先寄存器机制，当并发编辑修改不同字段时可避免冲突。若多端并发修改同一条记录，系统会通过比较并交换（CAS）逻辑拒绝本次写入，随后客户端随后拉取最新数据状态，在本地完成合并后重新提交写入操作。这个方案的主要难点是在不丢失更新或不破坏 CRDT 模型的前提下处理针对同一条记录的并发写入。
在第三项实验中，Lazaroff 将 atproto 作为 WebRTC 视频通话的信令通道。一方将 ICE（交互式连接建立） 候选记录写入 PDS，并标明预期接收方；另一方通过中继监听并做出响应，随后双方建立 WebRTC 直连通道。在现场演示中，会议现场的 Wi-Fi 信号不佳，需要使用 TURN（通过 NAT 使用中继进行穿越）中继，他戏称这类服务为“兜底备用 TURN 服务器”。他还建议 WebRTC 数据通道可以作为 atproto 的补充，为本地优先应用提供实时传输能力。这里的主要挑战是网络穿透，因为不稳定的会议网络环境无法建立顺畅的点对点直连，迫使系统回退到 TURN 基础设施。
整场演讲中，Lazaroff 主张开发者应当在通用共享基础设施上进行开发，而非为每个应用单独搭建专属服务端。他引用了”服务器应保持简单、通用且可替代“的观点。他指出，目前已有多家独立运营的个人数据服务器服务商、免费公共中继节点以及社区维护的数据聚合项目，这些都证明 atproto 协议已经契合该发展思路。在最后的讨论环节，观众的问题集中在互操作性、同步和 WebRTC 部署的权衡上。整场演讲传递的核心观点始终如一：atproto 完全有能力作为分布式应用的底层支撑，其适用范围并不局限于社交平台。
查看英文原文：
🔥 热词：#ata协议