atproto 中没有“实例”的概念There Are No Instances in atproto

每次有关于 atproto 的文章登上 Hacker News，总有人在评论区问：“但是 Bluesky 的实例都在哪里呢？” 问题是，atproto 中根本没有实例！这个问题本身就是一个范畴错误。实例是 Mastodon 特有的概念，我希望能有一个可以分享的链接，把这件事解释清楚。

所以，这就是那篇文章。

RSS 与 Google Reader

我知道 RSS 在某些地方仍在使用（播客？！），但它全盛时期可以说已经过去了。这很令人遗憾。在短短的几年里——我们中的一些人可能会深情地将其怀念为互联网的黄金时代——写博客曾让人感觉是一件很酷的事情。

现在请看这张图，因为它非常重要：

alice的博客cat的博客bob的博客googlereaderfeedly

提醒一下，你在自己的博客上发布内容，你可以选择自托管，或者托管在流行的博客平台上。但随后，所有人的内容都会被聚合到像 Google Reader 和 Feedly 这样的应用中，或者是像 Monologue（ RIP）这样的聚合博客中。

请注意，托管和聚合是两码事。你的文章并不“居住”在像 Google Reader 这样的应用里。应用仅仅是博客圈的投影。

说真的，一定要把这个概念深深烙印在脑海里；这非常关键。

Facebook 之类的

这可以说是上述概念的某种进化。

我们画个框把整个东西圈起来，这样所有人就被关在同一个空间里，我们就可以展示广告之类的东西了。另外，我们只保留一个应用（我们可以让第三方替代应用存活一段时间，但活不长）。这就是传统的社交媒体。

alice的帖子cat的帖子bob的帖子facebookthe facebook newsfeed

哦不，现在我们迎来了中心化！

哦不，失控的网络效应！

哦不，等等等等。

我们该怎么办？

我们得想办法把它去中心化。

Mastodon 与它的实例

我在这里说“Mastodon”是因为，如果我说“ActivityPub”，就会有一大群人跳出来指出，我所描述的其实只是 Mastodon 选择实现 ActivityPub 的方式。而 ActivityPub 本身并没有真正规定在实际中该如何使用它。我相信这确实很有趣——但我跑题了。

我们该如何去中心化一个社交网络？

让我们基于之前看到的模式构建一个新版本，但让它可以自托管。这样每个社区都可以拥有自己的“小 Facebook”或“小 Twitter”。我们将它们称为实例（instances）。它们有点像国家——因为你“生活”在其中一个实例里：

alice的帖子alex的帖子ann的帖子cat的帖子crow的帖子cali的帖子bob的帖子bree的帖子boba的帖子mastodon instance #1mastodon instance #2mastodon instance #3the newsfeedthe newsfeedthe newsfeed

但等等，这引发了一系列问题。

你该如何选择加入哪个实例？也许你同时属于几个有交集的社区。好吧，我想你只能选择最信任哪个社区的管理员来处理你的身份和数据了。

好了，现在还有另一个问题——如果我的朋友在另一个实例上怎么办？他们怎么看到我的帖子？因为每个实例基本上都是它自己的小 Facebook，它们没有共享的事实来源。所以它们必须互相发送消息：

alice的帖子alex的帖子ann的帖子cat的帖子crow的帖子cali的帖子bob的帖子bree的帖子boba的帖子mastodon instance #1mastodon instance #2mastodon instance #3the newsfeedthe newsfeedthe newsfeed

这种网络拓扑结构可能会让你联想到中国古代诸侯割据的局面。

如果实例 #1 的 Alice 关注了实例 #2 的 Bree，这两个实例就会达成一种约定：Bree 的帖子会被转发到实例 #1，这样 Alice 就能看到。这就叫做“联邦”（federation）。你在自己的实例上发帖，帖子随后就会被转发到其他那些有用户想关注你的实例。

这种模式带来了一些有趣的意味：

哦，对了，实例之间的连接（箭头）复杂度呈 O(n²) 增长。这在目前可能影响不大，但如果这种社交网络模式普及开来，问题就会显现了。

atproto

现在，把刚才说的这些都忘掉——彻底重置。

我们犯的错误在于画了这样一个框：

alice的帖子 cat的帖子 bob的帖子 facebook facebook的动态消息

擦掉这个框。

回到这种模式：

alice的博客 cat的博客 bob的博客 googlereader feedly

我们拥有数据实际“栖身”的托管服务，而应用程序则从中进行聚合。这种模式在博客上运作得非常好，为什么不能将它应用在所有其他事物上呢？

alice的内容 cat的内容 bob的内容 app #1 app #2

就像 RSS 一样，但适用于各种类型的内容。

这就是 atproto。

那么，所有的 Bluesky 实例都在哪里呢？

现在你应该知道了！atproto 中根本没有实例。

实例是这种 Mastodon 式思维的产物：

alice的帖子 alex的帖子 ann的帖子 cat的帖子 crow的帖子 cali的帖子 bob的帖子 bree的帖子 boba的帖子 mastodon instance #1 mastodon instance #2 mastodon instance #3 动态消息 动态消息 动态消息

它们是那些将托管和应用捆绑在一起的孤立“独立王国”，相互之间传递内容。

将这幅图景与 atproto 做个对比吧。

在 atproto 中，我们在网络层面将托管与聚合剥离开来：

alice的内容 alex的内容 crow的内容 cali的内容 boba的内容 atproto app #1 atproto app #2 atproto app #3 bree的内容 ann的内容 bob的内容 cat的内容 atproto hosting #1 atproto hosting #2 atproto hosting #3

这里根本没有实例！只有你可以随时更换的托管服务，以及从所有人的托管服务中抓取数据进行聚合的应用程序。这非常像 RSS 和 Google Reader 的关系。

atproto 的去中心化在结构上比“单个应用的多个副本”要丰富得多：

你在乎去中心化吗？在这里你拥有完全的自主权。尽情去实现去中心化吧。

摆脱“实例思维”的束缚

现在你应该明白，为什么每次关于去中心化社交媒体的讨论，最终都会被这种思维带偏了。

Mastodon 用户通过实例的数量来衡量去中心化程度，因为在 Mastodon 中你只能这么做。如果只有一种类型的“盒子”，且每个盒子都是“应用与托管相耦合”，那么你唯一能做的就是托管更多这样的盒子，并让它们相互通信。它们默认是相互隔离的。

在 atproto 中，每个应用都是整个 Atmosphere 的投影，就像 Feedly 和 Google Reader 是整个 Blogosphere 的投影一样。你的“去中心化”主要体现在更换托管服务，和/或开发及体验新的应用。运行多个完整的 Bluesky 数据库服务器副本是可行的，但这并不比运行多个 Google Reader 副本更有意义。人们确实会去搭建这些副本（例如 Blacksky），但它们的出现是为了满足特定的需求（比如不同的内容审核理念）。当然也有其他方案：比如某个 Bluesky 客户端完全没有专属数据库，它直接调用由社区免费运行并缓存了所有人托管数据的公共缓存。像 Relays 这样的共享网络基础设施，其运行成本在过去一年里已经变得非常低廉。

这就是为什么“计算 Bluesky 的实例数量”会产生巨大误导。真正重要的是：

将托管与应用解耦，能够修复封闭式和联邦式社交网络中扭曲的激励机制。托管与应用的耦合是原罪，而解决方法很简单。

将我们的数据保留在应用之外；让应用在这些数据之上进行聚合。

alice的内容cat的内容bob的内容应用 #1应用 #2

就像 RSS 和 Google Reader 那样。