2007年蒂姆·伯纳斯-李提出“全球图”概念，强调人际关系应超越文档和网站。如今X向Nitter发停止函，反映开放API的衰落。网络巨头从开放转向封闭，开发者从资产变为威胁，互联网档案馆创始人呼吁锁定网络开放精神。

好的，这是根据您的要求，对原文进行中文重述和精简后的版本：

标题：从“围墙花园”到“查询整个互联网”：一个开放社交网络的构想

核心观点： 互联网正被各大公司筑起“围墙花园”，开发者无法自由获取和利用数据。解决问题的根本出路在于构建一个共享数据库的开放网络，而AT协议正是实现这一目标的方案。

文章主要内容：

1. 问题的根源：从开放到封闭

   • 2007年，蒂姆·伯纳斯-李曾畅想一个超越网站和文档、能自由分享人际关系等信息的互联网。
   • 然而，如今X（原Twitter）向开源项目Nitter（一个无需登录即可查看推文的工具）发出律师函，要求其停止服务。这标志着互联网从开放走向封闭的缩影。
   • 曾经开放的Twitter API，因商业利益（“网络获胜”）而逐步关闭：设置速率限制、收费、要求登录，直至技术封锁和法律威胁。Meta（Facebook和Instagram）也走了同样的路。

2. “围墙花园”的核心问题：无法“查询整个互联网”

   • 当前互联网的模式是：数据分散在各大公司的“文件柜”里，每个柜子前都有一个“接待员”（API）。开发者只能按“接待员”允许的方式，一次读取一个文件，且无法进行跨服务、复杂的数据操作。
   • API的局限性：
     • 功能受限： 只能问别人预设好的问题，无法实现自定义的查询（如“我关注的人中，谁经常被引用的帖子”）。
     • 效率低下： 数据返回格式固定，获取大量数据需要多次往返请求，耗时巨大。
     • 无法跨服务关联： 无法将不同服务的数据（如帖子、照片、评论）进行关联分析。
     • 无法建立索引： 无法获取完整数据集来构建搜索、推荐、排名等核心功能。

3. 真正的需求：共享数据库

   • 要真正构建服务，开发者需要的是完整、实时、可自由索引和写入的数据集，而不是通过API窥视的一角。这种访问权限不能受制于任何一家公司的季度业绩。
   • 对用户而言，需要身份持久化（身份不随应用改变）和数据可迁移（数据能在不同服务间保持“活性”，而非静态存档）。

4. AT协议的解决方案：实现“查询整个互联网”

   • AT协议不共享一个数据库，而是构建一个由个人数据服务器（PDS） 组成的网络。
   • 数据复制： 应用不直接查询PDS，而是复制PDS上的数据日志，在本地进行查询。
   • 写入/摄取循环： 应用可以向PDS写入数据，PDS再将数据复制给其他应用。这构成了AT协议的核心工作模式。
   • 效率优化： 应用可以“乐观”地先更新本地数据库，再等待PDS的确认，从而提升响应速度。

5. 成果与现状

   • AT协议网络已成功运行，是Bluesky、Tangled、Leaflet等应用的基础。
   • 关键数据： 目前已有4610万个账户，245亿条记录（其中31.5亿条帖子，174亿条点赞），每秒处理500-1000个写入事件，拥有超过5000个个人数据服务器。
   • 开发者可以通过Jetstream服务轻松接入实时数据流，代码示例展示了如何监听关注、转发和回复事件。

结论： 与其被动接收律师函，不如拥抱AT协议这样的开放网络，实现“SELECT * FROM internet.blogposts”（查询整个互联网的博客文章）的愿景。

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

1. 对ATProto/Bluesky的质疑与批评 - 评论者认为ATProto技术复杂且不必要，如James_K指出：“I despite ATProto with all my soul for taking a problem with such a simple and standard solution and totally obscuring it behind hundreds of layers of JSON”（我痛恨ATProto，它把一个简单问题用数百层JSON、伪联邦服务和术语搞得复杂不堪）。 - 网络效应才是关键，如aftbit所言：“it's the network effects that matter. Attention is all you need indeed”（网络效应才是关键，注意力就是一切）。

2. 对去中心化可行性的怀疑 - 技术不是问题，质量、努力和成本才是，如madrox指出：“The technology is not the problem. The problem is always quality, effort, and cost”（技术不是问题，问题始终是质量、努力和成本）。 - 去中心化需要“turnkey, explained without showing a network diagram, be basically free to run on your laptop”（开箱即用、无需网络图解释、基本免费在笔记本上运行）。

3. 对RSS/传统方案的推崇 - 博客内容更适合RSS，如8organicbits建议：“For blog posts, I'd look to RSS instead. That's where that content is traditionally published”（博客内容应使用RSS，那是传统发布方式）。 - RSS网络比Bluesky的Jetstream API更可靠：“Thinking of RSS and blogrolls as a network feels much more resilient than blueskys Jetstream api endpoint”（将RSS和博客圈视为网络，比Bluesky的Jetstream API端点更有韧性）。

4. 对Bluesky开放性的肯定 - Bluesky不限制AI抓取数据，如arjie称赞：“Bluesky actually does not restrict AI scraping and consumption of data... The fact that you're allowed to consume the feed is amazing”（Bluesky不限制AI抓取数据，允许消费信息流很棒）。 - 但评论者也指出，这种开放性可能面临类似Twitter的API关闭风险，如cube00警告：“the network won. The developers stopped being an asset, and the API progressively closed”（网络赢了，开发者不再是资产，API逐渐关闭）。

5. 对博客文章本身的批评 - 评论者认为文章过于理想化，如canterburry指出：“this blog post is written as if the described functionality should obviously be available... But, when did we conclude this 'should' be possible?”（文章写得好像这些功能理所当然应该存在，但我们何时得出结论说这“应该”可能？）。 - 另有评论者因首行拼写错误而关闭阅读（dmje）。

总体评价：评论呈现两极分化。支持者赞赏Bluesky的开放性和技术架构，但批评者认为其过于复杂、去中心化不切实际，并建议回归RSS等成熟方案。多数评论者认同网络效应和商业现实（如广告、API关闭）是去中心化面临的核心挑战。