基于 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 是通过协议访问的远程服务器，而不是你可以推送和拉取的本地副本。 ATProto 仅符合部分 Local First 原则：它缺乏“触手可及的数据”和可选的网络使用模式，要求开发者构建自定义的离线存储和同步系统。 将离线支持与权限数据拆分结合会导致：

• 用于离线数据的自定义本地存储
• 必须为公开和私密数据使用不同协议的自定义同步系统
• 在线应用使用也需要为每种数据类型提供独立的读/写路径

社区反馈（精选评论）

"Luke 对权限数据提案的反馈非常有趣。目前的提案在权限方面有一种位置属性，记录的 URI 反映了访问控制..." — @pfraze "阅读像这样的文章，我认为人们正试图把方钉子（他们的应用）塞进圆孔（ATProto）。ATProto 的设计初衷是所有数据都是公开的..." — @ekosz "退一步来看，很明显权限数据是由现实世界的用例驱动的（Bluesky 需要私信，Tangled 需要私有仓库等）。然而，我认为与现有 atproto 的协同作用必须非常显著，才值得去开发又一套加密空间规范。" — @sbt "这位作者说出了我的心声！...它应该直接被称为“私密数据”...权限就是全世界可读。" — @verdverm

结论

Luke 对 ATProto 的身份基础依然感到兴奋，但他认为目前提议的权限数据设计与 Local-first、混合公开/私密的应用背道而驰。他希望该协议能够向统一模型演进，即数据本身是相同的，仅访问权限不同，从而让开发者能够构建他所构想的应用，而无需与协议的核心假设作斗争。