ATProto中没有实例

# atproto 中没有“实例”这个概念 — overreacted 原文链接：https://overreacted.io/there-are-no-instances-in-atproto/ 每次只要关于 atproto (https://atproto.com/) 的帖子出现在 Hacker News 上，总有人在评论区问：“但是 Bluesky 的实例都在哪儿呢？”问题在于，atproto 中根本就没有“实例”这个概念！这个问题本身就是一个范畴错误。“实例”是 Mastodon 思维方式下的产物，而我想要一篇能清楚解释这一点的文章，方便以后直接拿链接回复。 所以，就有了这篇文章。 --- ## RSS 与 Google Reader (https://overreacted.io/there-are-no-instances-in-atproto/#rss-and-google-reader) 我知道 RSS 现在还有人用（播客之类的？），但它的鼎盛时期确实已经过去了。挺可惜的。有那么几年（我们中的一些人可能还怀念那段黄金岁月），写博客曾经是件很酷的事。 现在请看这张图，因为它很重要： ``` Alice 的博客 猫的博客 Bob 的博客 ↓ ↓ ↓ ←--- Google Reader / Feedly ---→ ``` 提醒一下：你是在**你自己的博客**上发布内容，可以自托管，也可以托在流行的博客平台上。然后所有人的内容会被**聚合**到 Google Reader 或 Feedly 这类应用里，或者像 Monologue (https://www.mono-project.com/archived/monologue/)（已逝）这样的集体博客里。 请注意：**托管和聚合是两件不同的事情**。你的文章并不“活”在 Google Reader 这样的应用中。应用仅仅是博客圈的**投影**。 真的，把这个想法深深印在脑子里；后面会非常重要。 --- ## 脸书之类的东西 (https://overreacted.io/there-are-no-instances-in-atproto/#rss-and-google-reader) 这是这个概念的某种“进化版”。 我们给整个东西套了个框，把所有人都圈在同一个空间里，这样就能放广告什么的了。另外，只留一个应用（其他应用可以短暂存活，但活不长）。这就是传统社交媒体。 ``` ┌─────────────────────────────┐ │ Alice 的帖子 猫的帖子 Bob 的帖子 │ │ │ │ Facebook │ │ (Facebook 信息流) │ └─────────────────────────────┘ ``` 哦不，现在变成中心化啦！ 哦不，失控的网络效应！ 哦不，bla bla bla 啦 (https://overreacted.io/open-social/#closed-social)。 我们该怎么办？ 必须得想办法去中心化。 --- ## Mastodon 及其实例 (https://overreacted.io/there-are-no-instances-in-atproto/#mastodon-and-its-instances) 我在这里说“Mastodon”，是因为如果我说“ActivityPub”，就会有一大群人跳出来说：“实际上，你描述的只是 Mastodon **选择**实现 ActivityPub 的方式，ActivityPub 本身并没有真正规定具体怎么用。”我敢肯定这些都很有趣——但扯远了。 **我们如何将社交网络去中心化？** 把我们之前看到的那个版本，改成可以自托管的吧。这样每个社区都可以拥有自己的“小 Facebook”或“小 Twitter”。我们称之为**实例**。它们有点像国家——因为你“生活在”其中一个实例内部： ``` 实例 #1 实例 #2 实例 #3 ┌─────────┐ ┌─────────┐ ┌─────────┐ │Alice 帖子│ │猫的帖子 │ │Bob 帖子 │ │Alex 帖子│ │人群帖子 │ │Bree 帖子│ │Ann 帖子 │ │Cali 帖子│ │Boba 帖子│ │ │ │ │ │ │ │信息流 │ │信息流 │ │信息流 │ └─────────┘ └─────────┘ └─────────┘ ``` 但是等等，这引发了一堆问题。 你怎么选择加入哪个实例？你可能同时是好几个重叠社区的成员。好吧，那你只能挑一个你信任其管理员来处理你身份和数据的最合适的社区了。 好，还有另一个问题——如果我朋友在另一个实例上怎么办？他们怎么看到我的帖子？因为每个实例本质上都是自己的小 Facebook，它们没有共享的真相源。所以它们必须互相发送消息： ``` 实例 #1 ←→ 实例 #2 ←→ 实例 #3 ┌─────────┐ ┌─────────┐ ┌─────────┐ │Alice 帖子│ │猫的帖子 │ │Bob 帖子 │ │Alex 帖子│ │人群帖子 │ │Bree 帖子│ │Ann 帖子 │ │Cali 帖子│ │Boba 帖子│ │ │ │ │ │ │ │信息流 │ │信息流 │ │信息流 │ └─────────┘ └─────────┘ └─────────┘ ↑ ↑ ↑ └──── 互相发送消息 ────┘ ``` 这种网络拓扑可能让你想起中国古代的诸侯争霸。 如果**实例 #1 的 Alice** 关注了**实例 #2 的 Bree**，那么两个实例就达成了一项协议：Bree 的帖子会被转发到实例 #1，这样 Alice 就能看到了。这就叫“联邦”。你在你的实例上发帖，然后它会被转发给其他有关注你的用户的实例。 这张图有几个有趣的含义： - 你“属于”你的实例。你不是 *Alice*，你是 *实例 #1 的 Alice*。这就是为什么你的 Mastodon 登录名是 `[email protected]`。“你从哪来”成了你身份中不可改变的一部分。（不知怎么，这居然比国家和国籍还要限制人。） - 如果你的实例管理员和另一个实例的管理员闹翻了，他们可能会选择“停止联邦”，不再在之间转发任何帖子。你突然看不到朋友的帖子了，可能就是这个原因。 - 如果你的实例挂了，你的身份**就停止存在了**。关注你的人关注的是 *来自那个实例的你*，而不是什么抽象的“真正的你”。 哦，还有，实例之间的箭头是 *O(n²)* 量级的。现在可能问题不大，但如果这种社交网络方式流行起来，问题就大了。 --- ## atproto (https://overreacted.io/there-are-no-instances-in-atproto/#atproto) 现在忘掉上面所有那些——彻底重置。 之前的错误在于我们画了这个框： ``` ┌─────────────────────────────┐ │ Alice 的帖子 猫的帖子 Bob 的帖子 │ │ │ │ Facebook │ │ (Facebook 信息流) │ └─────────────────────────────┘ ``` 把框擦掉。 回到这个： ``` Alice 的博客 猫的博客 Bob 的博客 ↓ ↓ ↓ ←--- Google Reader / Feedly ---→ ``` 我们有托管（东西真正“活在”那里），而应用**聚合**它们。这对博客来说是可行的，那为什么对其他一切东西都不可行呢？ ``` Alice 的东西 猫的东西 Bob 的东西 ↓ ↓ ↓ ←--- 应用 #1 / 应用 #2 / ... ---→ ``` 就像 RSS 一样，但是针对**所有**类型的东西。比如用于 (https://bsky.app/)所有 (https://leaflet.pub/)这些 (http://tangled.org/)的 (https://semble.so/)应用 (https://rpg.actor/)。 这就是 atproto。 --- ## 那么 Bluesky 的实例都在哪儿？ (https://overreacted.io/there-are-no-instances-in-atproto/#so-where-are-all-the-bluesky-instances) 现在你知道了！atproto 中没有实例。 实例是那种 Mastodon 思维方式下的东西： ``` 实例 #1 实例 #2 实例 #3 ┌─────────┐ ┌─────────┐ ┌─────────┐ │Alice 帖子│ │猫的帖子 │ │Bob 帖子 │ │Alex 帖子│ │人群帖子 │ │Bree 帖子│ │Ann 帖子 │ │Cali 帖子│ │Boba 帖子│ │ │ │ │ │ │ │信息流 │ │信息流 │ │信息流 │ └─────────┘ └─────────┘ └─────────┘ ↑ 互相发送消息 ↓ ``` 它们是那些隔离的、捆绑了托管+应用的小王国，互相发送东西。 把这张图和 atproto 对比一下。 在 atproto 中，我们在网络层面把托管和聚合切开了： ``` Alice 的东西 Alex 的东西 人群的东西 Cali 的东西 Boba 的东西 ↓ ↓ ↓ ↓ ↓ ←---- atproto 应用 #1 / atproto 应用 #2 / atproto 应用 #3 / ... ---→ ↑ ↑ ↑ ↑ ↑ Bree 的东西 Ann 的东西 Bob 的东西 猫的东西 atproto 托管 #1 / #2 / #3 ``` 根本没有实例！你可以切换托管，还有从每个人的托管处聚合内容的应用。这跟 RSS 和 Google Reader 非常像。 atproto 的去中心化比“同一应用的多个副本”**结构上更丰富**： - 如果你想**切换托管**，你可以。我今天就刚做了。除了三四个用户体验小问题 (https://bsky.app/profile/did:plc:fpruhuo22xkm5o7ttr2ktxdo/post/3mon7oy66pc2e)，其他都是自动完成的。我的 atproto 东西现在在 Eurosky (https://eurosky.tech/accounts/) 上。如果我更爱冒险，我也可以**在 Cloudflare 上免费**自己托管所有数据 (https://github.com/ascorbic/cirrus)。 - 如果你想**尝试新应用或制作新应用**，你也可以！看看 Tangled (https://tangled.org/) 和 Semble (https://semble.so/)，它们跟 Bluesky 毫无关系。我最近做了我自己的应用 (https://sidetrail.app/)（而且是开源 (https://tangled.org/danabra.mov/sidetrail) 的）。我推荐你也试试手 (https://atproto.com/guides/statusphere-tutorial)。 你关心去中心化？这里你拥有完全的自主权。尽情去中心化吧。 --- ## 从“实例脑”中解放出来 (https://overreacted.io/there-are-no-instances-in-atproto/#free-yourself-from-the-instance-brain) 现在你明白为什么每一次关于去中心化社交媒体的讨论都会被这个问题带偏了吧。 Mastodon 用户通过实例数量来衡量去中心化，因为**在 Mastodon 中你只能做这一件事**。如果只有一种“盒子”，每个盒子是“一个应用加上托管”，那你唯一能做的就是托管更多这样的盒子，并让它们互相通信。它们默认是隔离的。 在 atproto 中，**每个应用都是整个 Atmosphère 的投影**，就像 Feedly 和 Google Reader 是整个博客圈的投影一样。你主要通过切换托管，和/或制作并尝试新应用来实现“去中心化”。运行 Bluesky 数据库服务器的多个完整副本是可能的，但这并不比运行多个 Google Reader 副本更有用。人们**确实**会搭建它们（比如 Blacksky (https://blacksky.community/)），但它们的出现是为了满足某人的**特定需求**（比如不同的审核理念）。还有其他方法：这个 Bluesky 客户端 (https://reddwarf.app/) 根本没有专用数据库，它只是访问一个免费的、由社区运行的、每个人托管的缓存 (https://constellation.microcosm.blue/)。像 Relay 这样的共享网络基础设施已经**低成本运行** (https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l) 一年了。 这就是为什么“数 Bluesky 实例数”如此具有误导性。重要的是： 1. 人们是否在迁移到替代托管？ 2. 人们是否在尝试和制作新应用？ 将托管和应用分离，修复了封闭式社交和联邦式社交中坏掉的激励机制。将托管和应用耦合在一起是原罪，而解决方案很简单。 把我们的东西**放在应用之外**；让应用**聚合它们**。 ``` Alice 的东西 猫的东西 Bob 的东西 ↓ ↓ ↓ ←--- 应用 #1 / 应用 #2 / ... ---→ ``` 就像 RSS 和 Google Reader 一样。