前言

笔者先介绍一下文章的背景:

  • 2 月份, 笔者发现了 Nostr 这样一个新兴的社交网络, 并开始尝试使用一些客户端实现.
  • 5 月份, 笔者开始使用某 Nostr 的服务端(中继)实现, 开始深入体验.
  • 7 月份, 大致生态和软件设计体验完成, 也正好发生了一次账号数据 "事故".
  • 今天(28 日)受到账号数据事故的启发, 决定针对 Nostr 写一些东西(但读者朋友们可能看到这篇文章是好几天后了🤣).

这篇文章的目的是「劝退」, 笔者会描述这几个月之间使用 Nostr 中遇到的问题, 当然只是 "丑话说在前", 文末也会介绍这种社交网络的优势, 相比如今流行的 ActivityPub 组成的 Fediverse 之间究竟有什么理由选择新的.

本文只提供笔者主观的体验感受, 其中提到的问题对我而言是问题, 而对读者朋友们不一定是, 请不要因为我的只言片语就放弃亲自探索新事物😉.

什么是 Nostr

Nostr 全称 "Notes and Other Stuff Transmitted by Relays", 即 "通过中继传输的笔记和其他东西". 是一种用于设计实现全球性, 去中心化与抗审查的社交网络的通讯协议.

Nostr 也直接代指由这种协议组成的分布式社交网络.

Nostr 的协议规范被称为 "NIPs", 全称 Nostr Implementation Possibilities, 即 "Nostr 可能性实现". 每一个可能的具体实现经过社区讨论和实践后会被合并进入 NIPs 作为 Nostr 的标准进一步壮大规模, 已和并的 NIPs 依旧接受社区改进和讨论, 通过 NIPs 传输的具体响应内容依照不同用途分为不同类型(kind)的事件(event), 一个 NIPs 可能是作为一个超集包含其他的 NIPs, 也可能是一个完全独立的使用全新类型的 NIPs.

比如:

  • NIP-01: 定义了基础事件, 包含三个事件类型(0, 1, 2), 其中:
    • kind:0 是描述秘钥元数据(可读的用户名, 个人资料,资料横幅等等 )的类型;
    • kind:1 是社交网络中最基本的文字贴 text_note 的类型;
    • kind:2 是一种向获取事件的客户端发送首选中继的类型.
  • NIP-02: 定义联系人列表, 用于传递用户关注列表和追随者列表, 使用 kind:3 类型.
  • NIP-05: 定义了如何将域名通过 DNS 和 HTTP 映射到秘钥, 用于身份认证和声明偏好中继列表, 使用 kind:0 类型.

Nostr 的服务端的实现如它的名字一样为 "中继(Relay)". 客户端通过一对密钥标识一个用户, 公钥用于定位一个基本用户, 私钥用于发布事件时计算消息签名进行签署发布; 中继(Relay)与客户端使用 WebSocket 协议进行通讯, 中继只负责储存和传递事件并且各中继间互不通讯, 几乎所有的计算渲染都发生在客户端.

Nostr 的发展

Nostr 最早由 fiatjaf 创建, 根据 GitHub 仓库 nostr-protocol/nostr 的提交历史, 最早可以追溯到 2020 年 11 月 8 日:

basic server relay code. · nostr-protocol/nostr@6158017

nostr-protocol/nost 仓库的 master 分支中最早的提交记录

引来 Nostr 第一次爆发的是 Twitter 联合创始人兼前 Twitter 首席执行官: 杰克·多西(Jack Dorsey).

2022 年 11 月底 12 月初, 正值埃隆·马斯克(Elon Musk)完成 Twitter 的收购[1], 马斯克当即就向记者提供了 Twitter 内部的一些文件, 宣称是为了揭露 Twitter 存在的内容审核中的偏见和政府施加的影响[2], 随后与之相关的 Twitter 话题 "#TwitterFiles" 登上了流行趋势.

2022 年 12 月 14 日, 杰克·多西在自己的 Twitter 账号上发表了动态参与了 #TwitterFiles 话题的讨论, 谈到了关于马斯克揭开这块 "遮羞布" 后的问题的想法, 他认为社交媒体应该:

  • 社交媒体必须能够抵抗企业和政府的控制.
  • 只有(内容)原作者才能删除他们自己制造的内容.
  • 反极端的审查(moderation)应该通过算法实现(algorithmic choice)[3].

在下文将统称为三大 "原则".

a native internet protocol for social media | Revue (存档)

为了达到他心中的愿景, 他提到自己提供资助的 Bluesky 社交网络和其使用的 "AT Protocol(AT协议)", 为了让更多人展现可能性, 他发起了一个 Twitter 话题 "#startsmall" 和与之关联的 "open internet development(开放互联网开发)" 奖金, 这笔奖金将会用于 "致力于社交媒体和私有隐私通讯协议, 比特币, 纯 web 移动操作系统的工程团队" 提供现金和股权投资, 还说下周就会向加密通讯软件 Signal 提供资助.

同一天, 杰克·多西在 Twitter 线程下跟帖发送了 Nostr 的 GitHub 仓库表示这是个 "优秀的问题阐述和解决办法的文章":

提及 Nostr

jack: "excellent writeup of problems and solutions...excited to see this. and public domain:" — https://t.co/bCXRwQNC0p

两天后, 也就是 2022 年 12 月 16 日, 杰克·多西简短地再次跟帖, 表示自己已经为这个项目向 fiatjaf 发送了 14 个比特币(当时价值约 $245000):

宣布捐助

jack: "14 BTC deployed to @fiatjaf for #nostr"

时间快进到两个月后的 2023 年 2 月 1 日, Nostr 社区依靠杰克·多西的影响以惊人的速度完成了不可思议的成就: 成功实现并在应用商店发行 Nostr 的移动平台客户端以及网页客户端:

Damus

Amethyst

这其中的三个客户端分別是:

在下文中将通称为 "三大客户端".

随后的事件便是海外媒体争先报道了这个 "钞能力" 事件.

中国大陆自然也是包含在内的, 直到后来 Damus 被中国区 App Store 下架, 但那也是后话了.

Nostr 的现状

两个月就能让一个产品迅速从概念成形到上线主要市场, 14 BTC 功不可没, 但笔者认为, 除了金钱的灌注, 先进的产品概念, 还有其 BTC 为代表的 Web3 世界.

2023 年 2 月份应该算是 Nostr 产品的首次启动, 这个月全世界的网友争先涌入 Nostr 网络, 和 Fediverse 火热时期一样: 在其他社交媒体上公布自己的 Nostr 公钥.

甚至还有分不清什么是公钥私钥, 不明利害关系的网友公布了自己的私钥.

垃圾內容

大量的用户涌入再加上 Nostr 以抗审查为前提的自由之下, 垃圾信息自然也是泛滥成灾.

Nostr 自身确实实现了杰克·多西社交媒体三原则的前两条:

  • 社交媒体必须能够抵抗企业和政府的控制.
  • 只有(内容)原作者才能删除他们自己制造的内容.

唯独最后一条, 直到现在依旧是困扰 Nostr 社区的严重问题:

  • 反极端的审查应该通过算法实现.

Nostr 定义了几乎所有, 但没有定义什么是 "极端", 这存在于人与人之间的行为, 很显然是不可能通过简单的计算机代码来定义的, 至少到现在还没有一个能够 "反极端" 的计算机 "算法", 发现垃圾信息大多也是要依靠传统的用户举报和服务端中的过滤器. 再加之第二条原则, 垃圾信息自然也是只能被原作者删除, 因此在客户端中用户还是会接收到垃圾信息, 只不过它们都被隐藏了起来.

审查与封锁 vs 加密与隐私

Nostr 网络设计为抗审查, 不是规避审查. 客户端, 服务端以及用于实现和分发的基础设施不抗审查, 具体的案例就是中国大陆地区的 App Store 下架 Damus:

进驻两天后，Damus 在中国大陆苹果应用商店被下架_MarsBit

中继也就是服务端的所有者, 他们拥有完全地审查传递到中继储存到服务器的数据的能力, 这是杰克·多西三条原则中未实现的第三条带来的悖论: 如果要审查就必须要得到原始信息, 但是为了隐私如果带来的加密阻止了获得原文, 你就无法实行审查, 你不能指望人们自我审查, 就和当初泛滥成灾的垃圾信息一样. 这也同时存在破坏第二原则 "只有原作者能删除内容" 的灾害, 因为从中继传递过来储存到设施后, 设施所有者完全有能力操纵数据库删除他们想删除的任何东西.

那么 Nostr 到底有没有加密? 其实是有的, 那就是 NIP-04: 加密私信.

nips/04.md at master · nostr-protocol/nips

而它也和使用传统电子邮件传输加密内容一样, 加密并不完整, 存在元数据泄露的问题:

This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use AUTH to restrict who can fetch your kind:4 events.

如果互联网中人与人之间的信任崩塌, 最后就只能靠计算机完成信任网络的建立, 端到端加密的兴起就是最好的例子.

如果真的存在一种反极端算法, 读者朋友们愿意为了 "更好的互联网" 交出自己的私钥给那台计算机吗?

与 Web3 的融合

鉴于 Web 1.0, Web 2.0 到传说中的 Web3 的各个簇拥者团体间战争不断, 为了 "更好的互联网", 笔者认为使用何种世代的 Web 技术应该能成为部分人选择互联网消费产品的重要指标.

Nostr 本身不是 Web3 的产品, 它是一个完全基于 Web2 网络的, 没有设计来使用诸如 Web3 设施的更加 "去中心化" 的元素之一.

但是 Nostr 的三大客户端已经和比特币下的闪电网络形成了融合, 都支持使用闪电网络记账付款, 甚至可以为任何类型的事件附上这种货币化属性, 利用的也是闪电网络. 按照 NIPs 的合并标准, 必须要先实践再在社区中提出讨论最后才有机会合并到仓库中, Web3 的融合已经跨过了这条线, 就在 NIP-57 中:

nips/57.md at master · nostr-protocol/nips

最后, 可能是由于杰克·多西发给 Nostr 的这笔钱用的是比特币或是其他什么原因, 现在 Nostr 中也同时存在数量庞大的 Web3 拥护者群体, 与加密货币和区块链相关的内容也是随处可见的(当然也包括垃圾信息).

数据不一致和攻击事件

Nostr 使用分散的中继实现了去中心化和抗审查, 意味着使用私钥签署的信息发给每个中继的都是完全相同的一个副本, 使用相同的签名来确保数据不被仿冒和篡改, 这些都是 Nostr 为了保持数据一致性做出的努力.

读者可能会问: 那为什么你还说还存在数据不一致?

此时就需要我们复习一下杰克·多西的三原则其二:

  • 只有(内容)原作者才能删除他们自己制造的内容.

没错, 只有保证传递完整性是不符合原则二的, 这些数据还要能够被删除. Nostr 为此专门设计了一个事件删除协议标准: NIP-09.

nips/09.md at master · nostr-protocol/nips

为了删除已经传递到中继中的内容, 需要使用 NIP-09 定义的事件类型 kind:5 向中继发送引用删除标记, 中继在收到后会将已存在的对应内容标记为隐藏, 客户端会对这些被删除事件引用的事件做出对应的动作, 一般是直接不显示. 并且在文档里明确说明: 删除事件无法被再次删除, 即使发出引用 kind:5 的新 kind:5 事件, 也是无效的.

Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality.

现在条件列出完毕, 让我来给你讲一个 Nostr 小故事:

你用客户端向一百个中继都发送了一条 "我是靓仔", 一年时间过去了, 这期间你了解到在客户端使用这么多中继简直是手机电池克星, 于是逐渐清理掉了一些中继, 最后剩下了十二个速度和覆盖范围都不错的中继. 又过了一年, 你无意间从网络上得知两年前发的那条 "我是靓仔" 在部分方言里居然和 "我是sb" 别无二致, 你还跨越了两年的时间线找到了这条动态, 顿时感觉浑身上下有蚂蚁在爬, 于是决定里利用 kind:5 删除这条动态, 你也做了, 你在时间线里确实看不到这条动态了, 你心满意足地发了一条新动态说明了这件事, 于是你的关注者们立马圣地巡礼, 精准地找到了那条 "我是靓仔", 但有些网友和你自己一样还是找不到. 有的网友还表示你这条消息会 "闪现", 时而出现时而消失.

为什么?

  • 为什么你找不到别人却能找到? 因为你只是向当初一百个已经接收到这条消息的中继中的十二个发了删除事件, 删除没有覆盖到全部.
  • 为什么有人找得到有人找不到? 因为找不到的人恰好用了和你相同的十二个中继中的几个或者全部所以他们找不到, 而有的恰好用的是另外的八十八个中继, 所以他们没有收到删除事件自然就找得到.
  • 为什么有人说这条消息时而出现时而消失? 因为他们使用的中继里既有你使用的十二个中继, 也有另外的八十八个中继, 所以完全看客户端先收到的是有删除事件引用的还是没有删除事件引用的, 对应的客户端也会让这条消息时而消失(收到了删除事件), 时而出现(没有收到删除事件).

接下来还有一个故事, 改编自真人真事:

你很喜欢 Nostr, 这一年以来你在上面记录一切, 也积攒了上万粉丝, 这里面也同时有你上千条的动态, 点赞数量超过十万的也不是少数. 今天你的粉丝向你推荐了一个全新的 Nostr 客户端, 说它是专门为你这样的博主设计的, 有很多小惊喜. 你当然很高兴有适合自己的客户端, 于是毫不迟疑地从网友的私信里发给你的网盘链接下载了这个客户端开始试用. 你用私钥登录了客户端, 准备发一条动态试试感觉怎么样, 突然软件弹出一个窗口说你的公钥下消息太多需要优化本地缓存索引, 是否优化? 你觉得听起来很有道理, 毫不犹豫地点了一下 "确认", 于是弹窗消失了, 什么都没有发生, 你无聊地随便点击客户端里的功能浏览着, 看着自己的粉丝数量每刷新一下就多几个很是开心. 几分钟后, 你突然收到了新粉丝的私信问你为什么你的动态都没有了. 你很疑惑, 因为你刚刚才检查过你的主页并没有什么变化, 于是你用手机打开你最常用的 Nostr 客户端重新进到你的主页, 发现你的所有动态真的全部消失了. 你想要想要恢复数据, 但无力回天. 那位向你发送客户端的那位粉丝早早删除了自己的聊天记录逃之夭夭.

为什么?

  • 到底发生了什么? 那个粉丝发给你的客户端的那个弹窗就是个钓鱼攻击, 看似优化本地索引实则是缓存了你的所有动态并且通过你自己的确认签署了对所有动态的删除事件.
  • 为什么客户端能做到这么大的破坏? 因为整个 Nostr 网络中掌管私钥的客户端拥有所有权限, 只要你愿意, 你就能用私钥对你的公钥账户做任何事情, 只需要轻轻点击一下, 包括删除你的所有动态.
  • 为什么无法恢复数据? 因为 NIP-09 定义的删除事件无法被再次删除.

以上的两个小故事阐述了这在一对公私钥和中继器控制的 Nostr 社交网络会出现的数据不一致问题; 以及拥有私钥后的客户端能够做到的事情.

面对未来针对 Nostr 社交网络的攻击, 在这对最大弱点在人的公私钥系统中要利用 NIP-09 损害账户数据简直效果拔群, 攻击者只需要做到一次就能造成无法挽回的损失, 而用户需要时时刻刻提防自己的私钥泄露.

对于删除事件导致的中继数据不一致问题, 现在社区之中也有类似讨论:

Better deletions / Tombstones · Issue #669 · nostr-protocol/nips

然而 NIP-09 导致的这系列问题也只是冰山一角, 如何保护主密钥和控制私钥权限才是真正这座冰山下最大的那一部分. 针对权限控制, 现在实际上也存在解决办法, 那就是 NIP-26: 委托签署事件.

nips/26.md at master · nostr-protocol/nips

这个 NIP 定义了一种委托人和被委托人的密钥对关系, 可以做到类似 GPG 那样签署子密钥代表主秘钥进行专门和限时的行动. 减少使用主秘钥就直接降低的主密钥被攻击的概率, 甚至还能完全禁止子密钥签署发布特定类型的事件, 比如可以禁止发布 kind:5 的删除事件防止被失误操作和钓鱼攻击发布无法挽回的删除事件.

但 NIP-26 发布至今三大客户端也没有支持进行这样的子密钥委托签署, 流行的客户端中笔者也只看到了 Gossip 支持发布这样的事件, 但也都要手写 JSON 内容, 这对于没有任何技术经验的用户来说无疑就是一大使用阻碍.

割裂的多媒体内容存储

社交媒体从来不是只有纯文字组成. 图片和视频虽然不足以撼动文字的地位, 但两者的力量任何一个都足以和它相提并论, 如果需要打一架, 那现在就是 1 vs 2 的局势.

Nostr 的协议特性让它非常擅长处理纯文本内容, 当然它也几乎没有考虑过多媒体的问题.

现在在 Nostr 上发送一张图片应该怎么做? 假设你使用了三大客户端, 你的体验或许会好很多, 只需要像大多数社交平台上一样选择好图片后就会自动上传, 然后你就会得到一个图片链接自动插入到正文中, 再发送出去就可以了.

读者们可能会发现问题所在: 图片传送到了外部服务器, 使用了外部链接嵌入到正文才实现了发送图片.

这些专门用于储存和外链图片的服务器在中文互联网有一个更熟知的名字: 图床. 类似的, 如果是专门存储视频的, 就是「视频床」, 更加广义一些, 储存文件的, 都可以叫「文件床」.

问题就变成了: 一个去中心化的社交网络要依赖于另一个中心化的关键基础服务

Nostr 的服务端本身就无法存储非结构化的二进制文件, 社区自然也发现了矛盾所在, 于是为了解决这个问题提出了 NIP-94 和 NIP-95, 它们分别是:

  • NIP-94: 文件元数据. 用于记录文件的原始信息, 包括文件链接, MIME 类型, SHA-256 等等, 用于向客户端提供获取文件的方式和类型并且确保文件提供方提供的文件没有发生篡改. 使用 kind:1063 事件类型.
  • NIP-95: 中继文件存储草案(现已废除). 通过将二进制文件编码为 base64 实现直接在关系数据库中存储非结构化数据. 中继器也可以选择通过其他 NO-SQL 数据库如 MongoDB 存储文件. 使用 kind:30064 事件类型.

NIP-94 实际上主要定义了另外一个 "客户端" 的运作方式, 也就是负责存储多媒体文件的存储服务器. 多媒体服务器需要自己支持使用 NIP-94 中定义的数据结构存储文件元信息并且使用用户私钥签署生成事件, 然后用户客户端才能使用媒体服务器签署的事件以引用事件的方式在另外一个事件中嵌入多媒体.

至于被废弃的 NIP-95, 它解决文件储存的方式并不算高明, 使用 base64 编码存储二进制文件很有可能使文件体积进一步增大, 徒增中继服务器数据库的存储压力. 还好, 它后来被废弃了.

很显然, Web3 宣扬的「去中心化的存储」到现在都没有真正广泛应用, 而本身基于 Web2 的 Nostr 更不可能跳出这个圈. 「多媒体如何存储?」这个问题在三大客户端两个月的冲刺之中做出了抉择: 默认使用中心化的存储. 客户端它们也会让用户能够选择自己的文件会被传送到哪一个预设文件服务器.

问题并没有被完全解决, NIP-94 只解决了媒体服务器和用户间的信任问题, 没有解决存储问题. 并且这些公共的媒体服务器就算无法篡改你的多媒体文件, 而只需要让你的文件无法访问就足以造成难以估量的损失.

为此 NIP-94 甚至支持使用磁力(magnet)链接作为文件的提供方式, 当然最终还是要看客户端愿不愿把自己变成一个 Torrent 或者 WebTorrent 客户端.

当然了, 这个问题很可能永远无法完美解决, 毕竟人类到现在都没有找到永久记录信息的办法, 而要在人造的互联网上 "永久存储" 就更是不可能的事情. 并且在社交媒体上, "永久存在的信息" 有时候甚至会变成一种麻烦.

相对地, 要更加长久地且足够 "去中心化" 可控地储存媒体文件, 精明的用户当然也能找到解决办法, 那就是建设自己的媒体服务器, 解析为自己的域名, 自己托管自己的媒体, 从而直接解决信任和存储问题. 不过, 客户端使用自己的媒体服务器就不会像预设的那些媒体服务器那样一键式操作, 并且目前三大客户端也没有开放自定义设置媒体服务器的选项.

永远无法到达的角落

多数人喜欢群居, 于是去中心化社交网络总是会有受欢迎的某几个节点或节点网络, 大多数的人都会选择聚集于此, 于是在去中心化网络中又催生出了新的中心化网络.

在文章开头就提到, Nostr 网络中的 "服务端" —— 中继器, 只承担传递和存储的任务. 而客户端则需要承担从中继中取得, 缓存, 对比, 解析, 渲染再到签署和发送的所有计算任务.

好吧, 如果只是与一个中继进行这样的结构化数据交换, 也并不算是 "不公平". 但是如果是十个, 五十个, 一百个呢? 如果你想到达 Nostr 世界的每一个角落, 就必须与所有已知和未知的中继建立通讯.

nostr.watch (Nostr 中继状态监测)

目前公共中继的数量

上方截图中的只是已知的公共中继的数量, 并没有包括那些需要付费使用的以及私有的中继. 为了实现 "去中心化" 理想上应该每个人都应该有自己的中继器, 但由于中继器之间互不通讯就只能通过其他方式比如手动添加或通过 NIP-05 检索.

如果你希望自己的发送的动态被大多数人看到, 那么应该选择最热门的几个中继而不是往所有中继上都发一遍. 而相对的, 也有人只是用 Nostr 保存一下自己的琐事, 顺便和其他人分享一下, 那么他们也不会选择把自己的东西往所有中继上都发一遍, 而是选择自己的中继或者朋友们都在用的中继. 中心化在人与人之间的聚集后又再次诞生了.

那么, 这样的由去中心化为前提造就的中心化, 算是去中心化的失败吗?

不广泛支持 RSS

截止 2023 年 11 月, Nostr 中的 RSS/Atom 问题已经得到很大的改善. Nostr 开发者 dtonon 对 njump(一个 Nostr 静态网关) 添加了用户时间线的 Atom 输出功能, 并且阅读体验非常优秀.

以下是本节修订前的原文:

1
2
3
其实是笔者我的奇怪需求: 用 RSS 阅读器浏览用户主页时间线. 三大客户端都不支持 RSS, 当然 Nostr 的这个问题应该要交给客户端来处理, 目前 web 客户端没有一个支持 RSS/Atom 数据输出的. 仅有的一个 nostr.band 提供的付费 RSS 订阅生成服务生成的 RSS Feed 实际阅读体验很差. 甚至已经有将 RSS Feed 转换成秘钥对账户的, 但就是很多没有反其道而行之的.

> 笔者认为 RSS/Atom 等代表着一种通用数据交换格式, 可以和支持通过这种格式交换数据的软件很好地联合使用. 反观 Fediverse 这边, 基本上都支持 RSS 输出.😥

Nostr vs Fediverse

社交是件非常昂贵的事情, 互联网上也是如此.

笔者是个人类, 这样说可能比较诡异, 不过事实确实如此. 因为我喜欢用 "人类是群居动物" 来描述人需要社交的原因和必要性, 但同时我也会用 "人与人之间无法相互理解" 来尝试降级甚至消灭社交这种需求.

社交这种需求自互联网产生就已经转移到了上面, 当时间和空间变得不再是限制社交的阻碍, 最后就只剩下了选择, 就像超市货架上的方便面, 玲琅满目的选择, 多到足以让人打消想吃方便面的的想法. 如今互联网上的社交方式就如同这货架上的方便面一样, 触手可及, 当你只有一个人的时候也许会选择困难甚至放弃选择, 但是当有一群人的时候呢? 你会选择人人都会拿的的那些方便面, 还是选择只有小孩子才会拿的方便面, 还是选择那些角落上无人问津的方便面呢?

而对我来说, Nostr 就像是这货架上刚上架并且还在超市门外宣传过的那批新方便面, 有人买但不会是大多数, 就连超市自己都不知道自己进的这些货到底会不会好卖, 因为他们周围的现有产品 "看起来" 都太好卖了. 这些好卖的有叫 Twitter 和 Instagram 的, 也有叫 Mastodon 和 Misskey 的, 甚至还有独特风味的微信, 微博, VK 等等, 还有曾经也畅销过但现在没有什么新顾客问津的 Facebook.

笔者也曾经都尝试过上面的畅销产品, 最后选择了... 放弃了买方便面!

是的, 一方面上选择实在太多了, 另一方面上自觉没有什么值得发表给其他人观赏的内容, 早年的我认为自知技不如人还表露出来是种愚蠢, 但现在发生了转变, 现在的我认为技不如人还表露出来是种能开口说话的勇气, 现在如果能有人批评指出我的错误或是赞同和理解甚至因此受益我会倍感荣幸, 能给予不断前进的动力.

所以, 现在我社交的目的就变成了认识更多的人, 而不再是表露自己, 不再是希望一味地寻求认同和赞美以及更多人的注视.

在上一个章节说了那么多问题, 那么还选择 Nostr 是到底为什么?

按照 Nostr 的特性将上面的 "畅销产品" 分类, 只存在中心化和去中心化两类产品, 至于中心化产品的优劣好坏笔者已经不再想赘述, 能够找到并且阅读到本篇这里的读者应该明白为什么有了中心化还要有去中心化这种逆向操作.

接下来我会以去中心化类社交产品的明星产品与 Nostr 进行比较, 并给出 Nostr 的优势.

与域名解绑的身份标识

Nostr 网络依赖公钥定位用户, 唯一名称不需要使用域名. 但如果你愿意照样可以把域名映射到自己的公钥上, 使得拥有一个更加可读的用户名.

在 Fediverse 中, 域名是一切实例实现联邦的基础, 如果你没有域名你就无法在 Fediverse 中标记出自己.

作为互联网的基础设施, 域名系统从 1983 年开始到现在 2023 年的 40 年间依旧是人类进入互联网最大的那扇门, 但是随着互联网世界板块的分裂和漂移, 域名系统变得更加不平等, 不自由. 针对互联网的权力和资源争夺已经把域名系统变成了一种筹码, 随意地破坏这类基础设施已经成了夺得互联网权利过程中的一部分.

真正能够让互联网居民们能够接触到的这些 "门" 严格上来说是门上开的无数小门, 域名持有者拥有的实际上都只是顶级域名下二级域名, 真正控制所有门的是 ICANN, 被委托或指定的域名管理局, 被域名管理局认证的域名注册商, 以及提供域名解析的解析服务器所有者, 最后就是掌握十三台根服务器以及镜像服务器的国家.

可以这么说, 域名系统就是互联网最大的中心化基础设施并且极其容易被蓄意破坏. 意在实现去中心化的 ActivityPub 却选择将用户最重要的唯一标识与域名绑定, 这本来就是一个问题. 并且还让用户无法在不同域名标识下自由移动数据, 甚至连镜像都做不到, 如同一个不允许用户转移邮件的电子邮箱.

想象一下你使用的电子邮箱域名由于各种原因无法再提供邮件服务, 并且你无法镜像你的数据到新的电子邮箱, 你只能设置一个堂而皇之的跳转链接 "墓碑" 让来到这里的人看到后还要经过一次跳转才能找到你.

尽管 Nostr 网络中的中继器也依赖于域名系统, 但在这里用户转移数据比重新发贴还要简单: 删掉不再使用的中继, 添加你想要使用的中继, 重新把你事件广播到中继.

并且说回到问题上: 如果你自己有一个中继, 失去对 Nostr 中继域名的控制并不会让你失去身份标识.

协议级别支持货币化

Nostr 可以随意收取代币, 中继托管者可以为服务设置为付费使用, 域名投资人可以出售域名标识认证服务, 甚至通过任何事件都能获得打赏.

Web3 融合带来的一大特性就是可以将任何操作都货币化, Nostr 的货币化基于比特币下的闪电网络. 如果想通过 Nostr 营利, 实际实施起来相比 Fediverse 要更加快捷.

如果服务的客户不是用户, 那这个服务很可能就是在用爱发电.

如果用户没办法成为客户, 服务的托管商原则上就不会对用户负责, 反之这类服务商提供服务吸引来的真正客户大部分会是广告主和赞助商, 交易的「货物」就成了用户数据和隐私. 能够逆转这种利益关系的只有非营利服务(公益或自托管).

而 Fediverse 从没考虑过如何让实例营利, 以及提供营利便利的通用协议甚至功能.

人人都知道生存是第一要义, 人也要靠物质支持才能「用爱发电」.

杰克·多西的 14 BTC 成功把 Nostr 带进了互联网, 走到了用户手上, 这是无法否认的事实. Fediverse 同样收到了众多赞助, 不少的实例直到今天依旧靠邀请制或赞助者模式走到了现在.

也许会有人反驳说不想要让 Fediverse 被商业化, 不想被被资本操纵, 那么笔者会说: 让产品流通于市场目的是让产品参与到市场竞争中快速成长, 而不是被所谓 "资本操纵". 不参与市场竞争的产品永远只能存在于「象牙塔」之中, 这类产品永远只会讨好这些「象牙塔」里的人, 而不是作为用户的我们, 我们只是恰好迎合了他们的价值观以及需求. 想要他们变得更适合用户? 我们能做的只有: 要么试图加入他们, 要么找到新的替代品, 要么成为他们的「象牙塔」.

值得注意的是, Web3 中喜欢将一切操作进行货币化, 这样做的目的除了赚取收益更重要的一点通过记账操作能将一切计记入区块链中.

虽然笔者并不认为 Nostr 与 Web3 结合是件讨好市场上所有用户的行为, 但至少它走出了市场化的第一步.

分布式而不是联邦

如果你有一个小团体那就非常适合 Fediverse, 但如果你是一个人, 那么就轮到需要为成为或者直接为其他小团体付出努力的时候了, 因为你一个人就是一个联邦.

从左到右依次为: 集中式, 联邦式, 分布式.

Mastodon documentation - What is federation?

中心化等级 示例
中心化 Twitter, Facebook, Instagram
联邦式 电子邮件, XMPP, 电话网络, 邮政服务
分布式 BitTorrent, IPFS, Scuttlebutt

如果要把 Nostr 放在上面三种网络模型中, 那么就是 "分布式", 如果要找一个与之相似的产品来类比从而便于理解的话, 那么就是 BitTorrent: Nostr 客户端是 Torrent 客户端, Nostr 中继是 DHT 网络或 "Tracker".

由于 Nostr 客户端与客户端间隔了一个中继传递消息, 所以 Nostr 实际并没有真正 P2P 意义上的 Tracker.

Fediverse 被称为「联邦宇宙」, 建立这样一个宇宙的前提是要有群体首先组成联邦然后再互联. 那么只有一个人如何加入 Fediverse 呢? 只能要么加入一个已经建立的联邦, 要么自己一个人成为联邦.

几乎所有的 Fediverse 实例软件都被设计成适用于多人乃至大型社区, 他们 "强大" 到需要应对与无数联邦互联(当然前提是足够的计算资源), 但没有考虑过单人 "联邦" 的感受: 他们只是用 Fediverse 保存一下自己的琐事, 顺便和其他人分享一下. 僵化的联邦制思维导致 Fediverse 的最小单位无法再细分, 每个实例都默认是一个联邦, 它就必须得承受来自与其他实例互联的 "人肉 DDoS", 更多的计算资源被花在了组成和维护联邦上, 而不是社交本身.

这样的联邦思维再加上贯彻到底的软件设计似乎在揪着你的脑袋说: "嘿! 想要加入 Fediverse 吗? 先把你的 4 核 4 G 服务器和你所有的磁盘空间贡献给联邦宇宙吧! 哦对了, 流量自理哦. 别忘了, 这是去中心化计划的一部分."

更低的服务端运行成本

在 Nostr 里你不用为刻意的与他人互联提前准备一切, "人肉 DDoS" 来到了 Nostr 身上的时候(如果真的有)你也不需要担心, 你甚至可以关闭你的私人中继器, 你的数据照常会通过其他大型公共中继或你购买的付费中继为你分发数据; 如果你不愿意做转嫁矛盾的事情, 那么你也可以为自己多设置几个专用的中继, 重新将你的事件广播到你的这些中继上分散到来的流量, 如果不够, 那就再加几个.

不过实际 Nostr 网络中面对这种社交媒体大流量的拥塞最该优先考虑保护的目标是托管媒体文件的服务器.

Nostr 三大客户端之一的 Android 客户端 Amethyst 今年三月份通过代理处理用户资料图片开销 $932.90, 近 2200 万请求数量, 4.76 TB 流量消耗.

Last month, Amethyst's Image proxy processed ~22,000,000 requests with ~4.76 TB of ...

Nostr 得益于简单的服务端设计以及便捷的数据转移, 对其进行扩充或迁移都是非常轻松的事情. 维护一个中继就和使用 BitTorrent 软件一样轻松, 没有复杂的服务端依赖和数据结构, 只有一个 Torrent 客户端(中继程序), 一个 BitTorrent 种子(保存你数据的数据库). 流行的中继实现也已经被三大客户端验证过了性能可行性.

运行 Nostr 中继的开销比 Fediverse 服务端开销低得多得多, 中继不进行大规模负载计算, 只需要将数据传递给客户端. 而客户端才是 Nostr 网络中计算密集的主要位置.

以笔者举例, 我运行了一个私人中继以及一直在使用的图片托管, 中继使用的服务器有 1 个动态(没错不是全时的🤣) CPU 核心, 256 MB 内存, 由于使用外部数据库, 所以也只有运行中继程序的 Docker 容器占用, 本机不需要数据持久化, 除此之外还有一个个人持有的域名.

早期测试用的远程数据库使用的是 Supbase 结果也一直用到了现在, 因为免费层的限制对于私人中继来说实在是太慷慨了(只要你不用 NIP-95 存文件).

实际中继程序占用近三个月平均 60 MB, CPU 核心约 1%(可能有统计问题). 当然主要的原因可能是时间线上到删号之前都只有二三十条动态, 数据库存储体积为 77MB(PostgresSQL, v15.1).

如果你不介意使用公共或者付费的中继, 那么这部分的时间成本甚至金钱成本都能降到更低. 当然笔者还是建议自己花钱托管多媒体文件, 并且使用自己的域名, 因为普通的 Nostr 事件发出去之后都是无法修改内容的, 包括事件内容的外链引用.

结语: 去中心化的未来

Nostr 只是去中心化行动中的一个声音, 如果把所有去中心化的产品放在一起看, 会发现他们的命运几乎都是沦为小众爱好或者小众需求者的玩物. 笔者不敢说现在真的人人都会用电子邮件, 人人都会下载 BitTorrent, 人人都会写独立博客, 人人都会正确使用加密货币, 类似的还有 XMPP, IRC, Matrix 等等.

这逃不开的结局究竟是命中注定还是「墙倒众人推」?

Nostr 并不应该设计用于取代 Fediverse, 过于超前的概念并不一定适应得了当下的环境, 况且两者都还有自己没有解决的棘手问题, 作为用户应当选择适合自己的, 你可以听从本文的一些建议去选择 Nostr 或者 Fediverse, 但要记住本文的内容实际上对两者都是「不推荐」, 他们对于没有计算机技术经验的用户并不友好, 如果你不了解其背后的设计原理和目的, 甚至没有基本的使用和理解互联网知识的能力, 请不要过早考虑他们 —— 去中心化产品.

笔者认为, 当真正大多数人掌握互联网基础设施工作原理和设计理念后, 去中心化, 在互联网的去中心化才能真正成为主流. 然而, 这需要倾注一个人大量的时间, 金钱和精力去了解那些对现实生活几乎毫无实用价值的基础知识, 最后很大概率走进一个新的「象牙塔」永远止步于此.

现实世界的人是否真的需要去中心化的互联网产品, 这真的还需要「人民群众」的检验.

注释

  1. 埃隆·马斯克收购推特案 - 维基百科，自由的百科全书 ↩︎

  2. 推特文件 - 维基百科，自由的百科全书 ↩︎

  3. Algorithmic choice - Bluesky ↩︎