柏林 Local First 大会上,几乎每场演讲都提到 ATProto——Bluesky 那套开放身份协议。软件工程师 Luke Kanies 想拿它做一款本地优先的评论应用,目标是替掉 Yelp、Goodreads、Letterboxd。他在会场问了一圈开发者和 Bluesky 核心团队,得到的答案不算乐观。
身份系统可以直接抄,统一账号、关注关系、跨应用认证都是现成的。但协议目前的主体架构默认公开,私有数据的方案还停在早期讨论文档里。想做"隐私分级"的应用,现在得自己扛两套系统的维护成本。
一条评论,凭什么必须公开
Kanies 想做的东西不复杂:一份评论,能在私人、群组、公开三种状态间自由切换。这才是评论类应用的真实需求,不是天生就该广播给全世界。
他举了自己和太太的例子。他愿意公开分享书评,太太写日记式的评论,绝不想被陌生人看到。多数用户介于两端之间,只有少数人真想当"评论博主"。
现在市面上的评论类应用,默认数据公开。这套默认设定,给这批"介于两端之间"的用户留下的选择很少。
对读者来说这一点很直接:如果你在做评论、日记、私人笔记类应用,ATProto 现在能直接给的是身份和社交图谱,给不了的是"默认私密、按需公开"这套权限逻辑。
身份共用一套,数据却跑两条线
ATProto 最拿得出手的是身份、认证、社交图谱和 Lexicon,统一账号体系省得每个开发者重新造轮子。这也是 Kanies 觉得值得复用的部分。
麻烦出在数据层。社区正在讨论的 Permissioned Data 提案,复用了现成的身份和 Lexicon,但给私有数据配了一整套独立的数据结构和读写机制。这个提案目前还停在早期设计文档阶段,没有定案,更没上线。
| 维度 | 现有公开数据系统 | Permissioned Data 提案 |
|---|---|---|
| 阶段 | 已上线,生产环境在用 | 早期设计讨论,未定案未上线 |
| 数据结构 | 公开优先,面向广播 | 独立结构,复用身份和 Lexicon |
| 权限切换 | 不需要切换 | 私转公需删除旧记录、重新发布 |
| 点赞/转发/外链 | 有明确机制 | 目前无答案 |
私转公不是改个权限位那么简单,而是要删掉旧记录、在公开系统里重新发一条。点赞、转发、外部链接怎么处理,目前没有答案。
对开发者来说,这意味着要在界面上装成公私数据是同一份东西,后台却维护两条协议链路。这笔成本会一直叠加,不会靠一次性开发抹平。
PDS 不是本地副本,离线优先还得自己补
Kanies 原以为 ATProto 的"个人数据服务器"(PDS)像 Git:本地留一份,改完再推送同步。
实际不是。PDS 确实是"你的"服务器,但你只能通过协议访问它,数据本身并不常驻在你的设备上。账号可迁移、接口公开,不等于你手里永远有一份数据副本。
想做离线支持,得自己搭本地存储和同步系统,协议本身不管这一段。
名义上是"我的数据",实际上还是放在别人的服务器里,只是可以搬家。
这对两类读者的影响不一样:
- 关注 ATProto、开放协议和去中心化社交的开发者:现在能直接抄的是身份、认证、社交图谱。私有数据结构最好按早期提案的状态对待,先别把架构写死,等设计文档进入实现阶段再决定要不要跟进。
- 做本地优先、隐私权限、数据可移植产品的设计者:不能假设 ATProto 现在就能提供"数据自动留在设备上"这个能力。本地缓存和离线同步得算进开发成本,不是协议白送的。
接下来最该盯的是两件事:Permissioned Data 提案是否从文档进入实现阶段,以及有没有团队做出成熟的本地缓存方案,把 PDS 和本地设备之间的缝补上。这两件事没进展,ATProto 对"本地优先加隐私分级"这类应用就还只是半成品底座。
Kanies 的判断是他个人对应用数据模型的看法,不是 ATProto 社区的共识,也没人说这个协议已经失败。但他点出的矛盾是真实的:身份系统做得再漂亮,补不上"隐私、权限、本地数据主权不是一等公民"这个缺口。
【锐评】身份认得清,数据分不明——这笔账,ATProto 还没结清。