基于ATProto构建
摘要
Luke Kanies讨论了他在ATProto上构建一套去中心化评论应用的计划,分享了来自Local First Conference的反馈,并对该协议当前的发展方向提出了批评。
暂无内容
查看缓存全文
缓存时间: 2026/07/24 05:00
# 卢克·卡尼斯 | 基于ATProto构建
来源:https://lukekanies.com/writing/building-on-atproto/
## 基于ATProto构建
发布于2026年7月20日
*Bluesky的ATmosphere协议有机会成为新一代应用的基础。但它正朝着令人惊讶且令人失望的方向发展。*
上周我大部分时间参加了在柏林举办的本地优先大会 (https://www.localfirstconf.com/)。毫不意外,AI编程是每个人关注的重点。更出人意料的是ATProto (https://atproto.com/) 的普及程度。
几个月来我一直在考虑是否基于ATProto构建,所以这次会议是个绝佳机会,可以向正在其上构建的人以及实际构建它的人(Bluesky的几个关键人物都在场)提出大量问题。
我*希望*ATProto能成为我的答案。我希望重新回到一个应用开发者使用公共、社区驱动的标准来创建具有通用数据标准的互操作应用的世界。我认为它有这个潜力。但不幸的是,我认为它目前并没有走上这条轨道。
在这篇文章中,我将描述我一直想构建的东西,以及ATProto当前和提议的设计如何与之契合或不契合。我还会加入一些让我感到惊讶的评论。
我可能试图在这里做得太多。但我的主要目标是对提议的设计提供反馈,而如果不明确我想构建什么以及为什么,就很难做到这一点。
## 从评论开始
我想构建的最小版本是一套用于记录评论的应用。在理想世界中,这些应用将取代Yelp、GoodReads、Letterboxd以及大量类似的应用,涵盖你可能会评论的任何事物。(是的,我知道已经有人在ATProto上构建这些的版本了;我希望与他们合作。)
我想取代这些应用,不是因为它们的功能,而是因为它们的商业模式。我和我的妻子都不会按照它们预期的方式使用它们,我认为大多数人要么像我,要么像我妻子。
## 本地优先数据
对我来说,我不希望这些公司拥有我的数据。我们在Yelp上有超过一千个书签,但它们...被困在Yelp里。我无法用它们做任何有用的事:无法发布、无法分享、无法编写脚本、无法进行版本控制。它们属于Yelp,不属于我。而且,坦率地说,它们提供的管理书签列表的体验相当糟糕。
这是一个经典的本地优先 (https://www.inkandswitch.com/essay/local-first/) 用例。我可以使用一个工具来写评论,另一个工具使用相同数据但更适合为朋友发布最佳列表,再一个工具可以轻松在我的网站上分享“最佳商业书籍”列表。没有哪个单一应用能完成所有这些,但一个共享的公共数据模型允许每个人拥有他们想要的东西。
我已经失去了让大公司永久控制我如何使用自己数据的意愿。(这就是为什么我用纯文本编写并通Hugo (https://gohugo.io/) 发布的原因。)应用只会越来越糟。如果我投入那么多时间记录我的观点,我想控制它的使用,而不是让Yelp来掌控。
## 公开与私密
至于我妻子,她*绝不*会在网上发布任何东西。永远不会。如果我想让她评论书籍、餐馆或菜谱,那必须在一个我能看到——也许还有我们家人能看到——但其他人看不到的地方。
就我个人而言,我*愿意*发布公开评论。有时我特·别想这样做,比如分享我作为创业者认为有用的书籍。但这样做很复杂。我为自己记录关于一家餐馆的信息,与我想让更广泛世界知道的信息截然不同。然而...大多数应用不允许你区分这一点。评论是公开的。你的观点会影响被评论对象的声誉,即使你不想这样。(我是素食主义者且患有自闭症,所以对我来说合适的餐馆对其他人未必相关。)
从根本上说,这些应用大多是为了赋能*影响者*:那些希望在网上为自己的评论建立粉丝群的人。“天哪,她的书推荐太棒了!”“如果他喜欢这家餐馆,我知道我也会喜欢!”
但我们大多数人*并不*想成为影响者。如果说有什么的话,我们通常已经学到,在网上被一群人关注是很糟糕的事。我想保持自己的东西私密。我不希望我的观点对其他人重要。
当然,当有人来到城里时,我希望能够给他们一份他们应该去的餐馆和应该做的活动的清单。但我想把它发给*他们*,而不是全世界。
我们可以把人们分成三类:
- 只有在别人会读的情况下才会记录评论的人。这些是潜在的影响者。
- 像我这样,根据情况会混合公开和私密评论的人。
- 像我妻子那样,只有在能确信评论仅对朋友群体或甚至仅对自己私密时才会记录评论的人。
目前的应用对第一类人来说很好,但让后两类人受到了冷落。
我敢打赌,后两组人*要大得多*。
所以,我们需要的是一个系统,让应用开发者能够轻松让用户选择他们想要多公开或多私密——完全公开、完全私密,或者与特定群体分批分享。
## 这与ATProto有什么关系?
先说ATProto的优点:它似乎是第一个旨在大规模解决身份问题的协议,使得任何应用都可以将ATProto身份构建到应用中,用于认证、跟踪关注者和关注对象,以及其他几乎所有应用都需要的相关功能。
它的身份系统并不完美(特别是我希望它更易于人类阅读)。但它似乎已经足够接近,以至于今年本地优先大会上的几乎所有演讲者都提到了它。每个应用开发者不再需要创建自己的社交图谱、自己的身份和认证系统、自己的查找朋友的方法。
不幸的是,至少目前,协议的其余部分对我的目标用处有限。
今天,ATProto是纯公开的:它假设你做的所有事情都会发布到网上,让整个世界看到。这个设计决策从存储系统到发布服务的结构都已经内化。
社区目前正在设计他们所谓的“权限数据 (https://dholms.leaflet.pub/3mqtqvjidqs2p)”。(我认为这个名称很傻,应该只叫“私密数据”,这更好,既因为“私密”实际上是一个词,也因为它描述了用户行为而不是技术实现,这是一个好得多的命名实践。)
不幸的是,虽然驱动设计的多数假设看起来合理,但最终的设计看起来很难在此基础上构建。我认为其问题所在在上述链接的文章中得到了完美体现:
> 在深入之前,贯穿这一切的主线是,公共广播数据与权限数据有本质区别。
我基本不同意这一点。(我不是唯一这么认为的人 (https://pckt.blog/b/bits-of-entropy/all-data-should-be-permissioned-data-g47655y)。)
私密数据和公共数据基本上是一样的。一篇餐馆评论就是一篇餐馆评论,无论只有我能看到还是被全世界传颂。我和读书会分享的书评,与我和妻子分享或在网站上发布的书评是相同的。
我发布给世界的数据只是一个特例:权限是全球可读。就像我从未发布的数据也是一个特例:除了我没有其他读者。
不幸的是,ATProto已经在Bluesky中实际使用,并且它是作为一个纯公开的协议设计和构建的。要改变它来支持访问控制、有限分发以及私密数据所需的其他功能会很难。
所以,据我所知,社区只是...设计了一个完全独立的私密数据系统。
权限数据依赖于现有的身份系统和词表(用于定义数据类型)。但增加了全新的数据结构,以及管理、验证这些数据的新方法。(注意上面的链接是一个系列文章中的一篇;你可以从那里找到所有文章。)
所以,作为应用开发者,你基本上要写两个应用:一个用于公共数据,一个用于私密。但你的用户不认为这是两个应用。“这些都是餐馆评论。所有餐馆评论应该在一起。”所以,作为开发者,你的工作是支持这两个数据系统和两个协议,但永远不让用户看到它们完全不同。
这很快就会变得一团糟。你有一条私密帖子想公开发布?你不是在修改它——你是删除旧帖子,在公共子系统中创建新帖子。它会保留点赞、转发、链接吗?🤷♂️ 不知道,但...可能不会。
实际上更糟糕。ATProto的存储子系统“个人数据服务器 (https://atproto.wiki/en/wiki/reference/core-architecture/pds)”直接提供对你的数据的访问。换句话说,你应该预料到不止一个应用想要读写你的数据。所以现在,任何对这个数据感兴趣的人都必须写两个版本,但向用户撒谎并隐藏任何差异。
因为,重申一遍,实际上并没有差异。实际存储的数据是相同的。用户思考的方式也是相同的。
对我来说,这表明当前提议是有缺陷的。
我不知道如何修复它。我离对话还远远不够,无法提出解决方案。但至少希望我能帮助人们看到问题。
## 最后一点关于本地优先
我去本地优先大会时对ATProto只有高层了解,所以我在那里学到了很多。我肯定错的一件事是PDS的工作方式。
我天真地以为它很像git仓库。ATProto社区经常说我自己拥有数据。我倾向于认为这意味着我有一份副本,当我做更改时,我是在对副本操作然后分发它。这正是git的工作方式:我克隆仓库,做更改,然后推送回服务器进行分发。没有永久拥有副本,我很难想象“拥有”自己的数据。
但不对,ATProto根本不是这样工作的。PDS是“你的”服务器,但...它实际上是一个服务器。你不会把数据推上去再拉下来;你通过协议与它通信。你“拥有”你的数据只是因为它和访问它的协议是公开的,并且你可以改变它存储的位置。
它确实像git一样使用基于密码学的数据完整性保证,这是我更以为可以像管理git一样轻松管理数据的另一个原因。但这些保证只在服务器上使用,而不是在你用来提供新数据的协议中。
ATProto满足了上面链接的本地优先论文中约一半的设计原则。但它显然不符合数据触手可及或网络可选的原则,也由于你始终与远程服务器通信而失去很多隐含能力。
如果你想在离线时记录评论...最佳实践基本上是把这些评论存储在临时区域,然后在上线时推送到服务器。换句话说,如果你想支持离线,你必须构建自己的自定义存储和同步系统。显然不是不可能,但也显然不是本地优先。
如果你再将这与当前的权限数据设计交叉,我面临着一团乱:
- 用于离线数据的自定义本地存储
- 用于清空离线数据的自定义同步系统
- 同步系统必须为公共和私密数据使用不同的协议
- 在线应用使用也必须为私密和公共数据使用单独的读写系统,并且很可能与离线支持的体系不同
作为一个致力于本地优先原则并让用户在公开和私密之间选择的应用开发者,ATProto对我的帮助和阻碍至少一样多。与设计我自己的系统相比,我真的更值得在它之上构建吗?当认识到协议设计者与我在哲学上相差甚远时,这个问题更加可怕。
如果我认为公共和私密数据本质上相同,只是访问权限不同,但社区认为它们不同并且应该不同...我将在每一步都与协议、存储系统和社区抗争。我以前做过这种事,很糟糕。
## 结论
我仍然对ATProto感到兴奋。而且幸运的是,权限数据的设计还很早期,仍可改进。我并不是唯一一个反对现有设计及其目标的人。
即使提议的设计通过了,我至少可以在某种程度上基于ATProto构建,也许使用它的身份和词表系统。
但我在90年代长大,那时整个互联网建立在标准化的协议上,这些协议是互联网规模的、有弹性的、由社区和标准组织维护,并且旨在赋能用户而不是让谁能建造最大的护城河而致富。我希望回到那个世界。
我认为ATProto有机会成为几十年来第一个这种类型的新协议。我希望他们努力争取,并构建出每个应用开发者(特别是像我这样的!)都愿意在其上构建的东西。
相似文章
在 ATProto 之上运行 ActivityPub
本文建议在 AT Protocol 的 PDS 之上运行 ActivityPub,认为结合两种架构可以在保持与现有联邦式社交媒体兼容性的同时,提供更好的用户自主权和可信退出机制。
ATProto 许可数据提案草案
Bluesky 已发布 AT 协议上许可数据的提案草案,同时还有用户列表、审核、OAuth 等其他提案,作为其持续开发工作的一部分。
ATProto 中的私有数据:权限数据提案
这是 Bluesky 的一项提案,旨在为 AT Protocol 添加权限化(私有)数据支持,从而在去中心化社交网络中实现对用户数据的访问控制。
ATProto中没有实例
解释为何来自Mastodon/ActivityPub的“实例”概念不适用于ATProto(Bluesky的协议),并阐明在ATProto架构中托管和聚合是分离的。
我为 Claude Code、Codex 和 Gemini 构建了一个本地 CLI,利用现有的认证机制来互相审查彼此的 GitHub PR
作者介绍了 `coding-review-agent-loop`,这是一个开源的本地 CLI 工具,它协调多个编码代理(Claude Code、Codex、Gemini)使用现有的本地身份验证相互审查彼此的 GitHub PR,从而避免额外的 API 成本。