Nostr 协议详解

协议是一套程序相互通信的规则。平台是一家代表你运行这些程序的公司。Twitter 是平台。电子邮件是协议。Nostr 是协议。

这个区别很重要，因为协议和平台有不同的失败方式、不同的成本结构和不同的未来。本指南解释了是什么使 Nostr 特别成为一个协议，这在实践中意味着什么，以及为什么设计有意保持精简。

TL;DR。 Nostr 是一个带有密码学签名的发布/订阅消息协议。它定义了一个小的事件格式和一个简单的方式供客户端通过 relay 发送和接收这些事件。没有公司拥有它。任何人都可以编写客户端、运行 relay 或提议扩展。核心规范只需几页。

准备好后， 领取你的 @nostr.blog 地址 →

协议实际上是什么

电子邮件是一个很好的比较。当你从 Gmail 向 Outlook 发送电子邮件时，Gmail 不需要 Outlook 的许可。两项服务都说 SMTP（电子邮件协议），SMTP 定义了一个邮件服务器向另一个邮件服务器传递消息所需的一切。服务器来自不同公司。协议是一个中立的协议。

Nostr 的工作方式相同。Nostr 事件（一条帖子、一个赞、一个关注）是一个 JSON 对象，其形状由协议定义。Relay 是任何同意接受、存储和转发符合该形状的事件的服务器。任何两个说 Nostr 的客户端都可以通过任何说 Nostr 的 relay 进行交互，无论谁制造了这三者中的任何一个。

协议是一个中立的协议。实现是自由的。

Nostr 规范，用最少的句子

三条规则涵盖了几乎所有内容。

1. 事件是一个 JSON 对象，包含 id、pubkey、created_at、kind、tags、content、sig。id 是其他字段的哈希；sig 是使用 pubkey 的私钥副本对 id 的 Schnorr 签名。
2. Relay 通过 WebSocket 接受有效事件，并提供按作者、kind、标签或时间过滤事件的订阅。
3. 客户端签名事件并将其发布到 relay；通过使用过滤器订阅 relay 来读取事件。

这就是核心协议。每个高级功能（长文章、zap、私信、社区、列表）都是一个扩展，它适应这个框架而不改变它。

为什么协议保持精简

大多数协议通过积累而增长。每个用例都会增加规范；每个十年规范都比前一个十年更大。HTTP 现在有数百页。电子邮件从少数 RFC 增长到一个复杂的网络。Nostr 通过设计避免了这一点。

机制是 NIP（Nostr Implementation Possibilities，Nostr 实现提案）。新功能不会添加到核心规范中；它们被提议为可选的 NIP。客户端实现它们关心的 NIP。其他客户端忽略它们。一个流行的 NIP 因为足够多的实现说它而成为实际协议的一部分；一个不受欢迎的 NIP 毫无仪式地消退。

这意味着核心永远很小（重要的不变量：已签名事件、开放 relay、便携身份）和边缘永远灵活（新功能在不破坏现有客户端的情况下演进）。2022 年的 Nostr 客户端在 2026 年仍然有效，因为核心没有改变；它只是做的事情比更新的客户端少。

协议与平台，具体来说

五个你作为用户可以感受到的实际差异。

身份。 在平台上，你的账户由公司拥有。在协议上，你的账户是你拥有的密码学身份。没有人可以把它夺走。

数据。 在平台上，你的帖子存在于他们的数据库中。在协议上，你的帖子存在于多个独立的 relay 上。如果其中一个消失，其他的仍然有。

功能速度。 在平台上，功能在公司决定时推出。在协议上，功能在任何实现者编写时推出。这在某些方面更慢（没有中央路线图），在其他方面更快（许多平行实验）。

货币化。 在平台上，公司获取所有货币化。在协议上，货币化是用户和实现者同意的任何方式。Nostr 有 zap（通过 Lightning 的对等小费），因为这符合文化；不同的协议社区可能会得到不同的规范。

失败模式。 平台可能完全消失。协议不能；只要一个实现者保持活跃，协议就活着。Nostr 的设计使得即使 fiatjaf（原始作者）明天消失，网络也会继续运行而不改变。

协议明确不做的事

五个故意从规范中遗漏的事。

审核。 协议不决定什么内容是可接受的。每个 relay 有自己的规则；每个客户端有自己的过滤器；每个用户有自己的静音列表。审核发生在边缘，而不是核心。

搜索。 没有协议定义的搜索。有些 relay 索引文本；其他的不索引。想要搜索的客户端要么依赖有搜索功能的 relay，要么运行自己的索引。这个缺失是刻意的；它使协议对什么被发现保持中立。

排名。 没有"为你推荐"提供。没有参与加权。客户端默认按时间戳显示事件；任何其他排序都是客户端级别的决定，而不是协议级别的。

发现。 没有推荐引擎。找到新账户关注是一个客户端功能，而不是协议功能。有些客户端在这方面投入大量资源（Primal）；其他的留给用户（Damus）。

恢复。 没有账户重置。丢失私钥，丢失账户。协议可能包括密钥轮换，但不包括，因为权衡是真实的，社区还没有就具体机制达成一致。这是一个正在进行的领域（NIP-26、NIP-41 草案）。

每个遗漏都是一个选择。协议通过拒绝在协议级别解决每个问题来保持精简。

谁决定 Nostr 成为什么

没人和所有人。

没有 Nostr 基金会。没有企业工作组。没有指导委员会。生态系统中最集中的权力在 fiatjaf 的 GitHub repo，其中提议 NIP，即使那也只是一个协调点，而不是看门人。

提议的 NIP 被客户端开发者阅读。受欢迎的被实现。被三个主要客户端实现的 NIP 实际上是协议的一部分；一个开发者编写但没有其他人关心的 NIP 只是 GitHub 上的文档。

这个过程很混乱。有协调问题、重复提议和偶尔的政治。它也以特定的方式具有弹性：没有任何一方可以通过做出坏决定来破坏它，因为坏决定只是不被采纳。协议通过开发者选择的权重大致向前发展，而不是通过权令。

协议模型何时获胜

协议在特定条件下击败平台：

• 当所有权比完善更重要时。 协议通常不如平台完善。当你关心完善无法给你的东西时它们获胜（永久身份、审查阻力、开放互操作性）。
• 当网络效应是功能时。 协议的价值通过实现者的采纳而增长，而不仅仅是用户。更多客户端和 relay 以平台无法复制的方式加强网络。
• 当长期前景很重要时。 平台被购买、出售、关闭或转向。协议比任何单一实现者都长命。电子邮件比大多数公司都古老；Nostr 打赌同样的动态。

如果你的用例与这些都不匹配，平台通常更快更容易。这是诚实的。Nostr 对于每个可能的用例都不是普遍优于 Twitter。它在协议击败平台的特定方式上更好。

阅读实际规范

如果本指南激励你直接阅读协议，NIP 存储库有完整列表。NIP-01 是核心；之后的编号 NIP 是扩展。你不需要理解任何内容来使用 Nostr，但阅读 NIP-01 只需大约十分钟，会澄清很多。