解读Nostr：抗审查的去中心化社交协议

把信息保存一亿年左右的方法，他们强调，这是目前已知的唯一可行的方法，它就是——”罗辑把拐杖高举过头，白发长须舞动着，看上去像分开红海的摩西，庄严地喊道，“把字刻在石头上!”

—by《三体》

背景

• 信息如何流传下去？有着前言中的那句振聋发聩的声音：把字刻在石头上！
• 信息如何不被阻断？那可以刻在更多的石头上，越多越好。
• 信息如何证明所有权？基于椭圆曲线那样优美的函数，在数学理论上的无限与唯一对应。

这是被串公钥刷屏一周，无论是在朋友圈还是推特Facebook，关键性事件就是Twitter 前首席执行官 Jack Dorsey 发推称，基于去中心化社交协议Nostr的社交产品 Damus 和 Amethyst 已分别在苹果 App Store 和谷歌 Google Play Store 上线，同时网页端 snort.social 也正式开放，其中Damus短短数日用户数已经突破72W。

虽然一句话里涵盖了很多产品的名词，不过其实关系很清晰，Nostr本质是去中心化社交场景的信息传输协议，Damus、Amethyst、snort.social则是根据该协议开发的第三方应用。

为什么会有Nostr的需求场景？

经历了反垄断之年的互联网群众们，即痛恨于中心化机构对数据的滥用与侵犯，又无力脱离优秀的应用体验以及并无选择性的市场，归根究底在于社交产品背后是公司为机构在运营，是公司就有接受监管与审查的义务，他所有负责的对象是股东以及注册地政府，本质上追求的是商业上的成功，而不是言论自由的理想。

而反垄断的终局古往今来更多是屠龙勇士终成恶龙，既然中心机构做不到，也没有立场去做，那么对自由的向往便催生出使用代码来保障自由的去中心化协议：Nostr

Nostr协议架构

其实Nostr非常简洁明了，可以一言概况：

让每个人都运行一个客户端程序，要发布什么信息时，用自己的私钥对文本签名，发送到多个中继器上。想要获取信息时，则向各个中继器问询。客户端再对得到的信息，借助其公钥验证从而判断真实性。

角色关系

协议中只有中继器和客户端两种角色

• relay，作为中继器可以有任意多个，使命是接受存储客户端上报的信息，并依据客户端请求返回本地查询结果。

• client，便是客户端也可以有任意多个，存在用户的设备中，要做的核心是签名与验证。

从这样简洁的角色关系可以看出，用户客户端并不与其他用户客户端产生交互关系，并非是p2p的形式，而中继器之间也无需交互他们之间无需信息沟通，这也意味着不存在共识层面的问题。

综合来讲，属于一种强客户端，弱服务端（中继）的结构，多个服务端可以互相替代，从而淡化其重要性，这也是抗审查的基础，用户之间对中继有自主选择的权利，从而能引发中继器层面的竞争，更大容量、更快速度、更好网络激励以及对垃圾内容的筛选能力。

账号体系

Nostr 中的身份由公钥和私钥组成。因此没有密码或唯一的用户名（或者公钥即为用户名），任何人创建新的公私钥对都是毫无成本的事情，本质上都是已经存在的关系。

不过与以往的去中心化社交产品显著区分的是，他全程不上链，可以说与链本身毫无相关，只是应用了区块链上最常规的公私钥账号体系而已。

我们已经可以从很多场景都见到公私钥的作用了，对于能接受自控私钥管理风险的用户而言，是绝佳的账号武器，前有EOA为底，后有MPC为优化，更有合约钱包作为目前账户抽象AA的载体。

可拓展阅读：

其次在广大NFT玩家面前，也经常遇到各类白名单Mint，也是基于公私钥签名与解签实现的

可拓展阅读：

操作行为

Nostr的NIP是一个雷同于以太坊EIP提案的机制，而NIP-01 即说明了每个消息的内容。

咱们从用户客户端的视角出发，可以进行下列操作

• 操作1、签名发布信息：EVENT

用户想要发布信息时，则是用自己本地客户端存储的私钥，对一串内容content做签名，最终生成如下的json类型数据

这里的id其实是基于当前内容[pubkey,created_at,kind,tags,content]组合后用哈希计算得出的，因为有时间戳的参与，所以正常情况下id是不会重复的。

• 操作2、订阅目标事件：REQ

作为信息传输，有来就有回，指令REQ需要向中继器发送一个随机ID作为订阅ID，以及一个过滤器信息。目前协议可支持的设定如下，

从筛选条件来看，基本等同于关注这个功能，既不需要对方许可也能拉取到对方发布的信息（事实上本质都是公开的），而过滤器也只是更好的定义，是谁在什么时间段，发布的那一条

当然出于中继器这样的设计，有可能部分中继器并没有存储目标用户的信息，那么用户需要尝试从不同的中继器去拉取，一旦中继器挂了，甚至全部相关联的中继器都挂了，那这块信息也就损失了。

• 操作3、结束订阅：CLOSE

最后一种客户端能对中继器发起的信息便是close指令，即关闭订阅，那客户端便不会持续持续获取到最新的事件信息了。

从技术角度看，此协议使用了订阅ID的模式这意味着中继器会建立起持续的websocket链接，一旦此中继器收到被关注用户的信息，就会主动向订阅方的客户端发起请求来同步，这种模式虽然对中继器而言负载更高，但同时也能得到实时被关注数这样的数据，是一种能激励用户发布更有价值信息的方式。

并且协议出现多个”e“、”p”,这类信息虽然并不是必选项，但他能让各个中继地址在客户端之间裂变，传播，是提升抗审查性的关键。

Nostr的困境与破局之道

通过上文对Nostr协议中角色关系、账号体系、操作行为的梳理，我们已经可以基本理解这样精简而优雅的一套传输协议的运作原理了。

但是，相比大家同样也冒出了和十四君一样的疑问，就这么简单吗？是啊，笔者梳理的过程就仿佛在做大一时候初学计算机网络的编程课作业一样，实现个局域网的聊天软件。

Nostr的爆发本质上是哲学理念的成功。只定义了最小的必要元素，而放开了控制能力，任何开发者哪怕是大一二的计算机学生都可以去开发一个中继器服务，低接入门槛带来的是巨大的体验竞赛。

从文末的拓展链接中可见，截止发文已经出现228个github开源的实现案例，本次并且部分在探索商业化上也体现出十足的创意。

社交场景素来被认为是护城河最深的互联网品类。其中很多的诉求是需要基于Nostr进一步优化后才能解决的。

• 困境1、社交隐私问题

目前的Nostr 中继器只是简单 JSON 数据的转储。客户端通过过滤器获取。这使得 nostr 成为客户端之间的通用数据共享平台，那对于有隐私信息传递需求的场景而言，如何解决呢？毕竟即使是推特这样的社交广场也会有私信的需求存在。

目前较优的解决方案是，DH算法（迪菲-赫尔曼密钥交换)，这套1976年问世的算法。它是第一个实用的在非保护信道中创建共享密钥方法。只要得到共享密钥，使用Nostr的双方均可以发布加密后的信息，从而实现点对点的隐私通信。由于隐私常有阅后即焚的诉求，所以其中的服务器存储成本还能进一步降低。

• 困境2、抗DOS问题

会受到攻击的是中继器这一层，目前Nostr协议并不直接指导和确定如何让中继器抗击DOS攻击和垃圾信息，因此也是众多中继器实现的重点。

从付费出发，因为中继有着极高的自主性，那么他可以设置付费条件，即某些中继服务只允许完成付款的交易才能发布在上面，有了金融成本便是最好的垃圾信息过滤器。

从工作量证明出发，也可以提高单次发布信息的挖矿成本，虽然Nostr和区块链基本无关，但是基于公私钥以及签名的账户体系，可以让其在发布的事件中，附带上要求，比如发布某条id（基于哈希计算的结果）要达成怎样的难度（如前5位为0），这样就是一种既持有信息，又带有工作量证明的发布方式。

• 困境3、高成本存储与垃圾信息筛选问题

虽然中继器中间并不需要共享任何信息，但是他们有着共同的诉求即符合用户意愿，提升使用体验，那么他们会很乐意共享一些黑名单，以及互相通信收集更多用户发布的信息，让自己的库存越来越大。

对于付出成本的一方，必然有着利益收取的一方，因为网络视频图片等资源的成本高，且无法看到轻松降低的能力，必然会出现的是基于收费模式的小网络，最终Nostr是一个个数据孤岛，即是可到达的也是需要付出成本的。

最后

虽然眼前Nostr爆火，但笔者依旧认为创建去中心化媒体平台的核心问题不是技术难题，而是社交困境。

社交是明珠，是互联网各赛道护城河最深的品类，这是因为他具有强大的网络效应，社交图谱带来的寡头效应是特别明显的，比如包括探探、陌陌等在内大多数社交应用的社交终点其实是微信，让任何人都很难离开微信沉淀的社交关系。而网络效应和垄断优势很大程度来源于封闭和许可，用户构建起属于自己的圈子后，用户退出这些平台的代价十分高昂，因为不能带走社交关系和图谱。

而社交产品十分害怕的是失去联系，Nostr实现了抗审查的中继器逻辑，却也带来了不确定性，消息从发布端到接收端有了一层割裂，3次握手4次挥手的http稳定连接建立条件，不可能由用户手动实现。

社交的诉求中，多数用户数据的掌控诉求恐怕会弱于用户的内心需求，早些年QQ空间风靡一时，后来转入移动互联的时候，与微信朋友圈之间巨大的差异是点赞与评论两大功能上，熟人可见与全员可见泾渭分明，并且后续的结果也有目共睹。

还有更多web2社交平台的优势就不一一列举了，目前基于Nostr实现的Damus等虽然名燥一时，但整体看充斥着各种bug，良好体验之路还有很长一段路需要追赶。

参考链接：

https://github.com/nostr-protocol/nostr

https://github.com/nostr-protocol/nips/blob/master/01.md

https://bips.xyz/340

https://zh.wikipedia.org/wiki/迪菲-赫爾曼密鑰交換

https://github.com/aljazceru/awesome-nostr