SELECT * FROM 互联网博客：用分布式数据库打破围墙花园

Paul's Leaflets，Paul's Leaflets 的网站。关注
SELECT * FROM 互联网博客：用分布式数据库打破围墙花园 图片 1

2007年，蒂姆·伯纳斯·李撰写了这篇文章巨型全球图谱.引用：

内心的呼喊......为了我的友谊，那段与另一个人的关系，超越文件和网站。..然后其他任何网站或程序都可以利用这些信息。

这似乎很合适，因为X正在向尼特发出停止侵权信记住TBL的文章。Nitter是——曾经——X的一个简单的前端，允许用户无需登录即可查看推文。

即使是这种少量的页面代理使用，也足以引发法律行动的威胁。

2007年，推特的API以开放著称，这意味着成千上万的开发者免费构建客户端、工具和分析工具。那么，发生了什么？为什么它被撤下？很简单：网络赢了。

开发者不再是资产，API也逐渐关闭。利率限制、定价层级、登录要求，然后是技术上的变通阻碍，现在还有律师来信。Meta十年前也用过同样的做法，现在很难记得曾经有哪个Facebook或Instagram的API值得开发。

这就是为什么互联网档案馆创始人布鲁斯特·卡尔十多年来一直呼吁我们锁定网络打开.

Nitter最初使用X的API。关闭后，它读取了公共网页。现在没有可关闭的，要求删除源代码。显示公共帖子的程序被计算机犯罪法规视为规避手段。

我们面临着围墙花园的问题。这不会改变，我们面前唯一的选择就是重新开始。

好消息是，阿特普罗托继续生长,活动出版社依然保持韧性，我们的社区充满了开放社交网络的信徒和建设者。既然我从事atproto工作，接下来我会谈谈这个。

互操作性SELECT *

SELECT * FROM internet.blogposts

围墙花园问题源自一个简单的问题：我该如何做SELECT * FROM internet?

如果你从未写过数据库代码，SELECT * FROM users这是你向数据库索取关于其用户的所有信息的方式。一旦你有了这些信息，你可以筛选、排序，并将其与你已有的其他数据合并。

网络历史上不是这样运作的。网络就是几十家公司，每家公司都有一个文件柜，每家公司门口都有接待员。他会一次给你读一份文件，但只能读你能命名的文件，速度快到他愿意读的程度，只要他的老板允许。

Nitter是轻量级的X读卡器，运行良好，直到X关闭了它依赖的访问。每个API（“接待员”）都是商业决策，至今尚未被逆转。

但无常性并不是唯一的问题。即使是永久、免费、且有宽松限制速率的API，也远远不够。应用程序需要比API提供的更多有意义的访问。

  • 你只能问别人已经想过要回答的问题。API 是一个固定菜单。它给你getPosts(user)以及getFollowers(user).如果你的产品创意需要“粉丝关注的人的帖子，按被引用频率排名”，那是没有终点的，也永远不会有，因为公司里没人为你的产品做开发。
  • 即使是正确的问题，回来的效果也不对。粉丝一次只有100个。一个拥有两百万粉丝的账号意味着往返2万次。在任何礼貌的限速下，回答一个用户的问题都需要花费数小时——所以任何互动性、任何必须感觉即时的内容，在你开始之前都被排除在外。
  • 你不能跨“柜台”加入。有趣的问题几乎总是跨服务：这个人的帖子与那个人的照片对比第三方服务的评价。两个接待员在两栋楼里不能交叉核对任何东西，你也不能。
  • 你无法索引你没有持有的数据。搜索、排名、推荐、订阅、审核工具——所有这些都是基于整个语料库的索引，针对你的产品提出的具体问题而设计。你不能通过钥匙孔来建立索引。

要真正构建服务，我们需要整个数据集，而不是对其进行视图;我们需要它实时发布，随变化而非轮询;我们需要根据产品要求索引;我们需要写入其中;而且我们需要以任何单一公司的季度优先事项无法取消的方式得到保障。

桌面应用通过共享文件系统来实现这一点。互联网应用不使用文件;它们使用数据库。我们需要共享数据库。

作为用户，我不想被困在一个应用里，就像我不想被锁在汽车后备箱里一样。我想要一个真正的自由市场。

那么，这里还有另一套需求。

  • 身份的持续性。
    • 我的存在感和关系是围绕我的身份建立的。它需要比我注册的应用更持久。
  • 服务间的活数据（非死数据）的导出。
    • 导出推文存档作为账户迁移方案毫无用处，因为数据并非孤立存在。
    • 如果数据不再可操作——无法由网络参与者进行额外操作——那么它就是一个静态归档，对其他应用毫无用处。
    • 你也可以打印你的推文，看看吧。

如果我们希望数据即使在原始服务之外也能保持可运行，那么我们需要共享数据库。

这些都是Atproto旨在解决的问题，包括开放数据访问、账户迁移以及网络活动的洪流。

Atproto如何制作SELECT * FROM internet发生

我们如何共享数据库？我们没有。我们共享大量数据库。我们创建了一个完整的个人数据服务器网络（PDS），应用程序与之交互。

我们如何处理应用程序发送复杂的问题SELECT *查询我们的个人数据服务器？我们不这样做。我们会在日志中复制数据。我们让每个应用汇总数据副本以便在本地查询。

我们如何让应用程序写入这些数据库？在这种情况下——我们确实写入了！我们让应用向PDS发送写入，这些写入又复制回其他应用。

最后一个是Atproto直觉的核心：写入/导入循环。几乎所有atproto应用的代码都是这样的：

// write
pds.putRecord(post)

// ingest
onPut(‘app.bsky.feed.post’, evt => {
  mydb.put(‘posts’, {...})
})

你可以不用等数据通过线路返回，而是利用“短路”，让应用数据库更新更快。PDS的200 OK是交易批准。

因此，更高效的模式更像是这样：

// write
pds.putRecord(post)
mydb.put(‘posts’, {...}) // ← optimistic

// ingest
onPut(‘app.bsky.feed.post’, evt => {
  mydb.put(‘posts’, {...})
})

它有效吗？

是的。网络存在。它是实时的，是公开的，你现在就可以在笔记本电脑上阅读所有内容，无需征求任何人许可。这正是正确的方式蓝天,纠结,传单，以及一个还有其他一堆现在就去干活。

让我来给你一些数据。截至撰写时，有：

利用新数据从未如此简单喷气流服务.

import { Jetstream, isCreate } from '@bsky/jetstream';
import { app } from '@bsky/sdk/lexicons';

const jetstream = new Jetstream('https://jetstream.us-east.bsky.network');
const collections = [app.bsky.graph.follow, app.bsky.feed.repost, app.bsky.feed.post];

for await (const event of jetstream.live({ collections })) {
  if (isCreate(event, app.bsky.graph.follow)) {
    console.log(`🌱  ${event.did}  follows  ${event.commit.record.subject}`);
  } else if (isCreate(event, app.bsky.feed.repost)) {
    console.log(`♻️  ${event.did}  reposts  ${event.commit.record.subject.uri}`);
  } else if (isCreate(event, app.bsky.feed.post) && event.commit.record.reply) {
    console.log(`💭  ${event.did}  replies  ${event.commit.record.reply.parent.uri}`);
  }
}

如果你想快速进入，试试看这里.

别再收到停止侵权通知了。SELECT * FROM internet.blogposts反而。

哦，如果你专门想找关于atproto的博客文章，你可能想用standard.site.

👉关注我的Bluesky。

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论