作者Luke Kanies认为Bluesky的ATProto协议有潜力成为新一代应用的基础，但目前的发展方向令人失望。他通过实地调研发现，该协议在支持开发者构建互操作应用方面存在不足，并希望ATProto能回归社区驱动的公共标准。

构建于ATProto之上：机遇与挑战

Bluesky的ATmosphere协议（ATProto）有望成为新一代应用的基础，但其发展路径令人既期待又担忧。作者在柏林参加“本地优先会议”时发现，AI编程和ATProto成为热议焦点。他本人已考虑基于ATProto开发数月，借此机会向开发者和Bluesky核心团队深入咨询。

作者理想中的ATProto应能支持开发者利用公共、社区驱动的标准，构建具有通用数据标准的互操作应用。然而，他认为当前协议并未朝此方向充分发展。

核心需求：构建评价类应用

作者计划开发一套评价应用，覆盖餐厅、书籍、电影等领域，旨在取代Yelp、GoodReads等平台。原因并非功能不足，而是商业模式问题：这些平台将用户数据据为己有，用户无法自由导出、分享或跨应用使用。例如，Yelp中上千条书签无法导出、分享或进行脚本操作，体验糟糕。

数据主权与隐私需求

作者强调“本地优先”理念：用户应拥有数据控制权，可自由选择工具管理、发布或分享数据。同时，用户对隐私需求各异： - 公开型：希望评价被他人看到，成为“影响者”。 - 混合型：根据场景选择公开或私密分享。 - 私密型：仅限亲友或自己可见，绝不公开。

现有应用主要服务第一类用户，忽略了后两类更庞大的群体。因此，系统需支持用户灵活控制数据可见性。

ATProto的现状与局限

ATProto在身份系统方面表现出色，解决了跨应用的身份认证、社交图谱等通用需求。然而，其当前设计存在关键问题：

1. 仅支持公开数据：所有数据默认全网公开，存储和发布系统均基于此设计。
2. “许可数据”设计缺陷：社区正设计“许可数据”（实为私有数据），但将其视为与公开数据完全不同的系统。这导致开发者需为同一数据维护两套协议和存储，用户却期望数据统一。例如，将私有评价转为公开时，需删除旧数据并新建，可能丢失点赞、转发等关联信息。
3. 缺乏本地优先支持：ATProto的“个人数据服务器”（PDS）是远程服务器，用户无法像Git那样本地拥有数据副本。离线时需自行构建临时存储和同步系统，且需区分公开/私有数据的同步协议，增加开发复杂度。

哲学分歧与挑战

作者认为公开与私有数据本质相同，仅访问权限不同。但ATProto社区视其为不同系统，导致开发者需对抗协议、存储和社区理念。若“许可数据”设计按当前方向推进，开发者将面临双重系统维护、用户感知割裂等问题。

结论与期望

尽管存在挑战，作者仍对ATProto保持期待。他认可其身份系统和词表（Lexicon）的价值，但希望协议能更贴近“本地优先”原则，统一公开与私有数据处理，降低开发者负担。他呼吁ATProto团队抓住机遇，构建真正赋能开发者、用户至上的新一代协议，重现90年代互联网基于开放标准、社区驱动的繁荣景象。

根据评论内容，主要观点和论据总结如下：

观点一：对ATProto公开数据设计的质疑 - 评论1（inigyou）认为，在线发布内容的意义已变，若不想成为网红则无动力，暗示ATProto的公开数据模式可能加剧这一趋势。 - 评论4（ekosz）指出，ATProto设计初衷是数据公开，若默认私有会违背其核心目标；但公开数据也带来好处，如初创公司倒闭后数据可被新服务复用。关键引用："The ATProto was designed around all data being public" 和 "If all data was private... that would defeat half of all of ATProto's goals"。 - 评论3（verdverm）批评ATProto的权限数据设计，认为应称为“私有数据”，且设计难以构建，建议采用ReBAC/Zanzibar风格系统。关键引用："it should just be called 'private data'" 和 "the resulting design looks very hard to build on"。

观点二：对ATProto实用性和生态的担忧 - 评论5（Striving7340）将ATProto与失败的加密去中心化平台类比，认为其缺乏运行节点的经济激励，且开发者需“崇拜协议”才能构建应用。关键引用："ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed" 和 "It never catches on with application developers because it requires you to already worship the protocol"。 - 评论7（vzaliva）对ATProto的局限性表示认可，并询问ActivityPub是否更合适。关键引用："Since the author has hit the limitations of ATProto, could ActivityPub be an answer?"

观点三：对ATProto的积极应用和未来展望 - 评论2（MarceColl）分享了基于ATProto构建棋盘游戏社区的经验，强调其支持俱乐部、联赛和游戏变体，且通过广播游戏数据实现AI分析和回放扩展。关键引用："I've been building a board game community on ATProto" 和 "The idea that my application can be extended without me adding an API is very exciting"。 - 评论6（arikrahman）从Codeberg切换到Tangled，称赞ATmosphere带来的安心感。关键引用："Being on the ATmosphere really helps with peace of mind"。 - 评论8（pfraze）回应了权限数据设计的反馈，承认存在权衡，但认为ATProto可与iroh等本地优先工具结合使用。关键引用："I wouldn't say it's a nonstarter for the ecosystem; you can use something like iroh in conjuction with atproto" 和 "engineering often involves trades, and for the v1 that was one of the trades we had to make"。

平衡总结：评论者对ATProto的公开数据设计存在分歧，一方认为其限制应用场景且缺乏激励，另一方则肯定其开放性和扩展潜力。同时，部分评论者提出替代方案（如ActivityPub）或改进方向（如本地优先集成），但整体上ATProto仍被视为一个需要权衡的协议。