开放社交
本文信息来源：overreacted
开源显然已经胜出。是的，仍有许多闭源产品和企业。但共享的基础设施——公共资源——是依靠开源运行的。
我们可能会认为这是理所当然的，但在三十五年前，这并不是一个必然的结局。当时有强大的力量希望开源失败。一些人相信开源模式，但认为它永远无法与闭源竞争。许多类别的工具只以闭源形式存在。微软的一位 CEO 曾称开源为“癌症”——而在十年后，微软却围绕开源重建了自己的帝国。开源运动或许没有完全实现“自由软件”的理想，但它在行业采纳方面取得了胜利。如今，选择开源不会让人丢掉工作。对于许多关键软件来说，开源现在已是默认选项 。
我认为我们在社交应用领域正处于与三十五年前开源类似的关键节点。 一个新的运动正在兴起。 我喜欢称它为 “开放社交”。关于“开放社交”应该是什么样子，存在不同的愿景。我认为由 Bluesky 创建的 AT Protocol 是迄今为止最有说服力的实现。它并不完美，仍在不断完善中，但我所知没有任何东西能与之相提并论。
（披露：我曾在 Bluesky 客户端应用团队工作。我没有参与协议设计。我是它的粉丝，这篇文章是我尝试解释原因的努力。）
alicebob@alice.com@bob.comprofilecommentpostlikefollowprofile
在这篇文章中，我将解释 AT Protocol（亲切地称为 atproto）的理念，以及它如何改变用户、开发者与产品之间的关系。
我并不指望 atproto 及其生态系统（被称为 the Atmosphere）能在一夜之间赢得人心。就像开源一样，它可能需要几十年才能普及。通过在这里解释这些理念，我希望能稍微推动这个时间表。尽管当今社交媒体公司掌握着主导权，我相信开放社交最终会在回顾中显得不可避免——就像开源如今的地位一样。好事确实会发生；所需的只是一个由固执的爱好者组成的社区多年持续的努力。
那么，这一切到底是关于什么的呢？
开源之于代码，正如开放社交之于数据。
社交之前
互联网是一项美妙的发明。
你输入 https://alice.com，就会进入 Alice 的网站。
或者你输入 https://bob.com，就会进入 Bob 的网站。
alice.combob.comhtmlhtmlhtmlhtmlhtmljpgjpgjpg
从某种意义上说，你的浏览器是通往数百万个不同世界的门户，每个世界都有自己的一小片管辖权。只有 Alice 决定 Alice 的网站上显示什么，只有 Bob 决定 Bob 的网站上显示什么。他们在真正意义上“拥有自己的数据”。
alicebobalice.combob.comhtmlhtmlhtmlhtmlhtmljpgjpgjpg
这并不意味着他们是孤立的。相反，Alice 可以用 <img src> 嵌入 Bob 的图片，而 Bob 可以用 <a href> 链接到 Alice 的页面：
alicebobalice.com<img src><a href>bob.comhtmlhtmlhtmlhtmlhtmljpgjpgjpg
Alice 和 Bob 可以互相链接，但他们仍然掌控着自己的网站。
我说 Alice 和 Bob 负责自己的网站是什么意思？即使他们并没有在自己的电脑上实际托管内容，他们也可以随时更换托管服务。例如，如果 Alice 的托管服务商开始删除她的页面或在页面中插入广告，Alice 可以将她的内容迁移到另一家托管服务商，并将 https://alice.com 指向另一台电脑。 访客不需要知道。
htmlhtmlhtmlold hostingnew hostingalicealice.comhtmlminer.jstracker.jsads.jshtml
这很重要。 托管服务提供商对 Alice 和 Bob 并没有真正的控制权。如果托管服务提供商“变坏”并开始干扰你的网站，你可以直接离开并将其托管到其他地方（只要你有备份）。你不会失去流量，所有现有链接都会无缝解析到新的目标地址。
如果 Alice 更换了她的托管服务，Bob 不需要更新任何指向 Alice 网站的链接。Alice 的网站会像什么都没发生一样继续运行。最糟糕的情况下，DNS 更改可能会让它在几个小时内无法访问，但随后网络会被修复：
alicebobalice.com<img src><a href>bob.comhtmlhtmlhtmlhtmlhtmljpgjpgjpg
想象一下，如果链接真的绑定到物理主机，激励机制会有多么不同！
如果更换托管服务商会导致 Alice 失去流量，她在更换之前会再三考虑。也许即使现有服务商在破坏她的网站，她也会继续使用，因为失去连接更糟糕。幸运的是，网络的去中心化设计避免了这种情况。因为可以轻松离开，托管服务商被迫竞争，托管服务如今已成为一种商品。
我认为网络是一个美妙的理念。它将由不同人和公司控制的去中心化孤岛连接成一个任何人都可以索引和导航的互联表面。链接描述的是逻辑文档之间的关系 ，而不是物理服务器之间的关系。因此，你不会成为托管服务的“人质”。
正如智者所言，理论上理论与实践没有区别，但在实践中却有差别。那么，Web 发生了什么变化呢？
封闭社交
在 90 年代初，发布内容到 Web 的主要方式是拥有自己的网站。如今，大多数人通过使用社交媒体应用来发布内容。
Alice 和 Bob 依然在发布内容。但他们不再是在 alice.com 和 bob.com 这样的域名上发布，而是在社交媒体公司分配的 @alice 和 @bob 这样的用户名下发布。他们发布的内容不再是 HTML 页面，而是应用特定的实体，例如个人资料、帖子、评论、点赞等。
这些实体通常存储在社交公司的服务器数据库中。最常见的数据库可视化方式是将其视为一系列行，但你也可以将其可视化为一个图。这使它看起来与网络本身非常相似：
alicebob@alice@bobprofilecommentpostlikefollowprofile
这个社交图谱能实现哪些个人网站网络无法做到的功能？
将结构化的、特定于应用的实体（如帖子和点赞）存储起来，而不是存储 HTML 文档，其优势显而易见。特定于应用的实体如帖子和点赞具有更丰富的结构：你可以随时将它们转换为 HTML 文档，但在此之前你还可以对它们进行聚合、过滤、查询、排序，并以不同方式重新组合。这使你能够创建同一数据的多种投影 ——例如个人主页、帖子列表、带评论的单个帖子。
真正的优势在于，当许多人使用同一个社交应用时，由于所有人的公开内容都存储在同一个数据库中，跨越多人发布的内容进行聚合就变得非常容易。这使得实现全球搜索、通知、信息流、个性化算法、共享审核等社交功能成为可能。
正是这种社交聚合彻底颠覆了“个人网站”的范式。人类是社会性生物，我们渴望在共享空间中聚集。我们不仅仅想访问彼此的网站——我们想要一起互动，而社交应用提供了这种共享的基础设施。像通知、信息流和搜索这样的社交聚合功能，在现代社交产品中是不可或缺的。
如今，实现这些功能的最常见方式是这样的：
alicebob@alice@bobprofilecommentpostlike/@alice/@alice/post/123/notifications/@bobfollowprofile/search/feed/following/feed/recommended
我们的数据——个人资料、帖子、关注、点赞，以及我们创造的所有内容——依然存在一个类似网络的逻辑模型中，但它存储在某个社交应用的数据库里。对外暴露到网络上的，只是该模型的投影 ——主页、通知页面、单个帖子的 HTML 页面。
这种架构是合理的。这是将“个人网站”范式演进为支持聚合的最简单方式，因此今天的应用大多趋同于此并不令人意外。人们在社交应用上创建账户，使这些应用能够构建聚合功能，从而吸引更多人注册使用这些应用。
然而，在这个过程中有些东西丢失了。 我们实际上正在创造的网络 ——我们的帖子、关注、点赞——已经不再真正属于我们。即使我们创造的很多内容是公开的，它也不再是开放网络的一部分。我们无法更换我们的“托管服务商”，因为我们现在与互联网的运作方式隔了一层 。我们和我们创造的网络，已经变成了别人数据库中的一行数据：
alicealicebobbob@alice@alice@bob@bobprofileprofilecommentprofileposttweetlikefollowtweetprofilespacetweetfacebook.comtwitter.comhtmlhtmlhtmlhtmlhtmljpgjpgjpg
这造成了不平衡。
当 Alice 过去在 alice.com 发布她的内容时，她并不依赖于任何特定的托管服务商。如果她对某个托管服务商不满意，她知道自己可以更换它，而不会失去任何流量或破坏任何链接：
htmlhtmlhtmlold hostingnew hostingalicealice.comhtmlminer.jstracker.jsads.jshtml
这让托管服务商有所约束。
但如今，Alice 将她的内容发布在社交媒体平台上，她再也不能“不带走任何东西”地离开了。如果她注册另一个社交平台，即使她想保留自己的社交关系，也会被迫从零开始。Alice 无法在不撕裂自己及其在平台上创造的一切的情况下，与某个特定应用断开关系：
alicealicebobbob@alice@alice@bob@bobprofileprofilecommentprofileposttweetlikefollowtweetprofilespacetweetfacebook.comtwitter.comhtmlhtmlhtmlhtmljpgjpgjpg
Alice 创建的网络——她关注的人、她喜欢的内容、她发布的帖子——被困在一个属于他人的盒子里。离开它，就意味着将它抛在身后 。
在个人层面，这可能并不是什么大问题。
Alice 可以在别处一点一点地重建她的社交存在。最终，她甚至可能拥有与之前平台相同的影响力。
然而， 总体而言 ，最终的结果是社交平台——起初是逐渐的，然后是突然的——开始背弃他们的用户。如果你无法在不失去重要东西的情况下离开，那么平台就没有动力去尊重你作为用户的价值。
也许应用被投资人压榨，每三条帖子就有一条广告。也许它被一个想要消除竞争的企业集团收购，如今只能靠维持生命线勉强运转。也许它资金耗尽，你的内容两天后就会消失。也许创始人被收购并雇佣——一个令人兴奋的新篇章。也许应用被某个人买下，现在你正被算法慢慢“烹煮”。
alicebobbob@alice@bob@bobprofilecommentprofilexeetxeetprofilespacexeetfacebook.comx.comhtmlhtmlhtmlhtmljpgjpgjpg
如果你的下一个平台不尊重你作为用户的身份，你可能也会尝试离开它。
但是你打算怎么做？你会“导出你的数据”吗？你会拿那一小片孤零零的社交图谱做什么？你可以把它上传到某个地方作为存档，但它已经被剥离了社交语境——只是你自我流放的可怜纪念品。
你在离开时得到的那些 JSON 兆字节是死数据 。它就像一根从树上被折断的枝条，不属于任何地方。要让我们的数据重获新生，我们必须集体导出它，然后集体导入到某个大家一致同意的下一个社交应用中——这几乎是不可能完成的协调壮举。即便如此，网络效应依然如此强大，大多数人很快就会找到回去的路。
你无法离开一个社交应用而不留下你所创造的网络。
如果你能保留它呢？
开放社交
Alice 和 Bob 仍在使用社交应用。这些应用看起来与今天的社交应用没什么不同。 你几乎察觉不到有什么变化。
不过，确实有些东西变了。（你能发现吗？）
alicebob@alice.com@bob.comprofilepostcommentlikelikefollowprofile
注意，Alice 的用户名现在是 @alice.com。它并不是由社交媒体公司分配的，而是她的通用“互联网用户名”，也就是一个域名。Alice 拥有 alice.com 这个域名，因此她可以在任何开放社交应用中将其用作用户名 。（在大多数开放社交应用中，她使用 @alice.com，但在其他平台上她希望有一个独立且不关联的身份，所以她还拥有另一个不想公开的用户名。）
Bob 也拥有一个域名，尽管他并不懂技术。他甚至可能不知道“域名”是什么。Bob 只是把 @bob.com 当作他的“互联网用户名”。一些开放社交应用在注册时会为你提供一个免费的子域名，就像 Gmail 会给你一个免费的 Gmail 地址，或者可能提供购买域名的额外流程。你并不会被锁定在第一次选择的域名上，之后可以更换为其他域名。
你的互联网用户名是你真正拥有的东西，这是开放社交应用中用户最直观能感受到的特点。但更大的不同之处对用户来说是不可见的。
当你之前看到上面的社交图谱时，它被困在某个社交应用的数据库内部 。图谱周围有一个框——它并不是网络的一部分。在开放社交中，Alice 的数据——她的帖子、点赞、关注等—— 是托管在网络本身上的。除了她的个人网站，Alice 现在还有一个个人数据仓库 ：
alice@alice.comalice.comprofileposthtmllikelikehtmlfollowhtml
这个“数据仓库”是一个实现了 AT Protocol 规范的普通 Web 服务器。Alice 的个人数据仓库唯一的工作就是以签名 JSON 的形式存储和提供 Alice 创建的数据。Alice 很懂技术，所以她有时会用一些开源工具，比如 pdsls、Taproot 或 atproto-browser 来查看她的仓库。
然而 Bob 并不懂技术。他甚至不知道有一个存放他“数据”的“数据仓库”。当他注册第一个开放社交应用时，后台就为他创建了一个数据仓库。他的仓库存储着他的数据（来自所有开放社交应用）。
再看看这张图：
alicebob@alice.com@bob.comprofilepostcommentlikelikefollowprofile
这些并不是某人数据库中的行。这是一个由超链接 JSON 组成的网络。 就像每个 HTML 页面都有一个 https:// URI 以便其他页面可以链接到它一样，每个 JSON 记录都有一个 at:// URI，以便任何其他 JSON 记录可以链接到它。（在此及其他示例中，@alice.com 是 at://alice.com 的简写。）at:// 协议是在 DNS、HTTP 和 JSON 之上的一系列约定。
现在看看它们记录之间的箭头。Alice 关注了 Bob，所以她有一个 follow 记录链接到 Bob 的 profile 记录。Bob 评论了 Alice 的帖子，所以他有一个 comment 记录链接到 Alice 的 post 记录。Alice 点赞了他的评论，所以她有一个 like 记录链接到他的 comment 记录。Alice 创建的所有内容都保存在她的仓库中并由她控制，Bob 创建的所有内容都保存在他的仓库中并由他控制，而链接则表达了这些连接——就像在 HTML 中一样。
这一切都在幕后发生，对非技术用户来说是不可见的。 用户无需在意数据存储的位置，直到它变得重要，就像用户在浏览网页时不会去思考服务器是如何运作的一样。
Alice 和 Bob 的仓库可以托管在同一台机器上，也可以由不同的公司或社区托管。也许 Alice 自行托管她的仓库，而 Bob 使用的是他第一个开放社交应用默认附带的免费托管服务。他们甚至可能运行完全不同实现 。只要两个服务器都遵循 AT 协议，它们就可以参与这个 JSON 网络。
请注意，https://alice.com 和 at://alice.com 不必解析到同一台服务器。这是有意设计的，这样拥有一个漂亮的用户名如 @alice.com 并不会强制 Alice 自行托管她的数据、修改她的网站，甚至不必拥有网站。如果她拥有 alice.com，她可以将 at://alice.com 指向任何服务器。
如果 Alice 对她的托管不满意，她可以打包走人：
old hostingnew hostingalice@alice.comprofilepostlikelikefollowprofilepostfollow
（这在今天需要一定的技术技能，但它正在变得更易用 。）
就像迁移个人网站一样，更改她的代码仓库的服务来源不需要与之前的主机合作。这也不会影响她登录应用的能力，也不会破坏任何链接。网络会自行修复：
alicebob@alice.com@bob.comprofilepostcommentlikelikefollowprofile
值得停下来片刻，欣赏一下我们所拥有的这一切。
Alice 和 Bob 创建的每一条公开数据——他们的帖子、点赞、评论、食谱、音乐记录——都真正属于他们自己。 这些数据不是存放在某个 CEO 心血来潮就能改动的数据库中，而是直接托管在开放网络上，并且可以“随时离开”而不会失去流量或破坏任何链接。
就像个人网站的网络一样，这种模式以用户为中心。
这对应用来说意味着什么？
每个开放社交应用就像是一个 CMS（内容管理系统），用于管理存储在用户个人仓库中的一部分数据。从这个意义上说，你的个人仓库的作用类似于一个 Google 账号、一个 Dropbox 文件夹或一个 Git 仓库，不同开放社交应用的数据会被归类到不同的“子文件夹”中。
当你在 Bluesky 上发帖时，Bluesky 会将该帖子放入你的仓库中：
alice@alice.combsky.appprofilepostlikecreateRecord
当你在 Tangled 上为一个项目加星标时，Tangled 会将该星标放入你的仓库中：
alice@alice.comprofileliketangled.shpoststarcreateRecord
当你在 Leaflet 上创建一篇发布时，Leaflet 会将它放入你的仓库中：
alice@alice.comprofilelikeleaflet.pubpoststarpublicationcreateRecord
你懂的。
随着时间推移，你的仓库会逐渐成长为来自不同开放社交应用的数据集合。这些数据默认是开放的——如果你想查看我的 Bluesky 帖子、Tangled 收藏或 Leaflet 发布，你不需要访问这些应用的 API。你只需访问我的个人仓库并枚举其中的所有记录即可。
为了避免命名冲突，仓库中的数据会按以下格式分组：
alice@alice.comapp.bsky.postsh.tangled.starpub.leaflet.publicationpub.leaflet.publicationpub.leaflet.subscriptionpub.leaflet.subscriptionpub.leaflet.documentpub.leaflet.documentsh.tangled.reposh.tangled.followapp.bsky.likeapp.bsky.followapp.bsky.postsh.tangled.starsh.tangled.reposh.tangled.followapp.bsky.likeapp.bsky.follow………………………bsky.appleaflet.pubtangled.sh
在任何用户的仓库中，Bluesky 的帖子会与其他 Bluesky 的帖子放在一起，Leaflet 的发布会与 Leaflet 的发布放在一起，Tangled 的星标会与 Tangled 的星标放在一起，依此类推。每种数据格式都由相关应用的开发者控制和迭代。
我画了一条虚线来将它们分开，但这可能会产生误导。
由于来自不同应用的数据“共存”，开放社交应用之间可以更容易地利用彼此的数据。从某种意义上说，这开始让人感觉像是一个互联的应用多元宇宙，一个应用的数据会“渗入”到其他应用中。
当我注册 Tangled 时，我选择使用我现有的 @danabra.mov 账号。这很合理，因为身份可以在开放社交应用之间共享。更有趣的是，Tangled 预填了我的头像，基于我的 Bluesky 个人资料。它并不需要调用 Bluesky API 来做到这一点；它只是读取了我仓库中的 Bluesky 个人资料记录。 每个应用都可以选择利用其他应用的数据。
这可能会让你想起 Gravatar，但它适用于每一条数据 。每个开放社交应用都可以利用其他开放社交应用创建的数据：
app.bsky.postsh.tangled.starpub.leaflet.publicationpub.leaflet.publicationpub.leaflet.subscriptionpub.leaflet.subscriptionpub.leaflet.documentpub.leaflet.documentsh.tangled.reposh.tangled.followapp.bsky.likeapp.bsky.followapp.bsky.postsh.tangled.starsh.tangled.reposh.tangled.followapp.bsky.likeapp.bsky.follow………………………bsky.appleaflet.pubtangled.sh
没有需要调用的 API，没有需要构建的集成，也没有被封锁的风险。所有数据都在用户的仓库中，因此你可以解析它（作为类型化 JSON），并加以使用。
协议就是 API。
这对产品生命周期有着深远的影响。 如果一个产品被关闭，数据不会消失。它仍然存在于用户的仓库中。有人可以构建一个替代品，让这些数据重新焕发生机。有人可以构建一个新产品，整合部分这些数据，或让用户选择导入哪些数据。有人可以构建现有数据的另一种投射—— 一个分叉产品。
这也减少了新应用的“冷启动”问题。如果你关心的一些数据已经存在于网络上，你可以基于这些数据快速启动你的产品。比如，如果你正在推出一个短视频应用，你可以利用 Bluesky 的 follow 记录，这样用户就不必再次互相寻找。但如果这对你的应用来说不合适，你也可以拥有自己的 follow 记录，或者提供一次性导入功能。所有现有数据都可以被重复使用和重新混合。
一些开放社交应用明确是围绕这种类型的混合而构建的。Anisota 主要是一个 Bluesky 客户端，但它 原生支持 显示 Leaflet 文档。Popfeed 可以将评论 跨平台发布 到 Bluesky 和 Leaflet。如果 Leaflet 变得非常流行，Bluesky 本身也可以支持将 Leaflet 文档作为另一种帖子附件类型。事实上，一些第三方 Bluesky 客户端可能会率先这样做，而官方客户端最终也可能跟进。
这就是我喜欢“开放社交”这个术语的原因。
开放社交释放了我们的数据，就像开源释放了我们的代码一样。 开放社交确保产品能够获得新生，人们不会被剥夺他们所创造的内容，并且产品可以被分叉和混合 。当不同应用的数据在开放网络中流通时，你不需要一个“万能应用”。
如果你是技术人员，到现在你可能会有一个迫切的问题。
聚合到底是怎么实现的？！
由于每个用户的记录都存储在该用户的仓库中，因此存在数百万（甚至可能数十亿？）个仓库。应用如何高效地查询、排序、过滤并聚合这些信息？它显然不可能按需搜索它们。
我之前用过 CMS 作为类比——例如，一个博客应用可以直接将文章写入你的仓库，然后在有人访问你的博客时从仓库读取文章。这种“单人模式”的用例根本不需要任何聚合。
alice@alice.compub.leaflet.publicationpub.leaflet.documentpub.leaflet.publicationpub.leaflet.document……leaflet.publistRecordsgetRecord
为了避免每次显示用户的博客文章时都访问用户的仓库，你可以通过 websocket 连接到用户的仓库。每当有与你的应用相关的记录被创建、更新或删除时，你就可以更新你的数据库：
alice@alice.comleaflet.pubwss://subscribe#commit#commit#commitDBDBDB
这个数据库并不是用户数据的真实来源 ——它更像是一个特定于应用的缓存，让你在需要数据时避免每次都访问用户仓库。
巧合的是，这正是你用来做聚合的机制。 你监听所有应用用户仓库的事件，将它们写入本地数据库，然后可以随时查询该数据库，且不会增加额外的延迟。
这可能会让你想起 Google Reader 抓取 RSS 的方式（RIP）。
为了避免打开成千上万个事件套接字连接，监听一个从网络上所有已知仓库重传事件的流是有意义的：
alice@alice.combob@bob.comleaflet.pubwss://subscribe#commit#commit#commitDBDBDB
然后你可以将这样的流过滤成只包含你感兴趣的事件，并根据你的应用关心的事件来更新本地数据库。
例如，Leaflet 只对涉及 pub.leaflet.* 记录的事件感兴趣。不过，Leaflet 也可以选择监听其他事件。如果 Leaflet 想要添加一个功能，显示 Bluesky 讨论中指向某个 Leaflet 文档的反向链接，它只需开始跟踪 bsky.app.feed.post 记录即可。
你可以通过点击此链接自己试试：
这是网络上每一个事件的实时流。它主要由 app.bsky.* 记录组成，因为 Bluesky 是使用最多的应用，但你可以筛选成其他类型的记录。这个重传器（称为“relay”）由 Bluesky 运营，但你不必依赖它。Blacksky 社区在 wss://atproto.africa 运行他们自己的 relay 实现 ，你可以在这里试用。
另一个重要细节是，提交是经过加密签名的，这意味着你不需要信任某个 relay 或网络数据缓存。你可以验证这些记录没有被篡改，并且每一次提交都是合法的。
随着时间推移，我们会看到更多围绕开放社交应用构建的基础设施。Graze 让用户可以构建自己的算法信息流，而 Slices 是一个即将推出的开发者平台，可以为你进行大规模的仓库索引。
这些都是技术细节。
重要的是整体格局。
整体格局
在社交网络出现之前的“个性化网站”时代，数据所有权、托管独立性和链接权都做得很好。Alice 和 Bob 完全参与到网络中：
alicebobalice.com<img src><a href>bob.comhtmlhtmlhtmlhtmlhtmljpgjpgjpg
封闭的社交网络在扩展性和社交聚合功能方面进行了创新。通知、搜索和信息流是现代社交产品中不可或缺的功能：
alicebob@alice@bobprofilecommentpostlike/@alice/@alice/post/123/notifications/@bobfollowprofile/search/feed/following/feed/recommended
然而，封闭的社交网络也将我们排除在网络之外。 我们创造的网络已不再真正属于我们。我们只是别人数据库中的一行数据。
alicealicebobbob@alice@alice@bob@bobprofileprofilecommentprofileposttweetlikefollowtweetprofilespacetweetfacebook.comtwitter.comhtmlhtmlhtmlhtmljpgjpgjpg
开放社交将我们正在创造的网络从他人的框架中解放出来。我们的个人资料、点赞、关注、食谱、音乐记录以及其他内容真正属于我们：
alicebob@alice.com@bob.comprofilepostcommentlikelikefollowprofile
数据不再存储在产品内部 ；产品会聚合我们的数据：
alice@alice.combob@bob.comleaflet.pubwss://subscribe#commit#commit#commitDBDBDB
这模糊了应用之间的界限。每个开放社交应用都可以使用、混合、链接并基于其他开放社交应用的数据进行创作。
app.bsky.postsh.tangled.starpub.leaflet.publicationpub.leaflet.publicationpub.leaflet.subscriptionpub.leaflet.subscriptionpub.leaflet.documentpub.leaflet.documentsh.tangled.reposh.tangled.followapp.bsky.likeapp.bsky.followapp.bsky.postsh.tangled.starsh.tangled.reposh.tangled.followapp.bsky.likeapp.bsky.follow………………………bsky.appleaflet.pubtangled.sh
我们创造的网络在用于构建它的产品消失后依然存在。开发者可以构建新产品来重新赋予它背景。没有人能将它夺走。
alicebob@alice.com@bob.comprofilepostcommentlikelikefollowprofile
随着更多产品在开放社交范式下构建， 将会发生转变。
人们可能永远不会开始使用像“去中心化”这样的技术概念，但他们确实能理解当一个应用的数据可以无缝流入其他应用时的意义。
人们可能不在乎“联盟”，但他们会注意到，当他们登录一个竞争产品时，他们的数据已经在那里 ，而且他们的触达范围依然完好。
而人们确实能理解自己正在被耍弄。
在很长一段时间里，开放社交将依赖于一群固执的爱好者 ，他们看到了这种方法的潜力，并愿意承受在新生态系统中构建（和失败）的痛苦。但我不认为这会让努力注定失败。这是每一次由社区驱动的大变革的历史。总得有人去解决那些问题。就像开源一样，开放社交是一种复利式的努力。每一个稍微成功的开放社交应用都会提升所有开放社交应用。每一块共享的基础设施都能让其他人受益。在某个时刻，开放必将获胜。
