Nostr NIPs 详解：协议的规范文档

Nostr 的演进通过 NIPs 进行，这是任何人都可以提议的简短规范文档。如果你想理解 zaps 或加密 DMs 等新功能是如何进入协议的，NIPs 就是答案。

本指南涵盖什么是 NIPs、它们如何作为治理机制工作，以及如果你开始深入研究应该阅读哪些 NIPs。

NIPs 是 GitHub 上的简短 markdown 文档，提议如何实现 Nostr 功能。客户端开发者选择支持哪些。当足够多的实现者采用一个 NIP 时，它就变成"真实的"。广泛使用的核心 NIPs 集合约有 30 个；完整列表接近 100 个。

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

NIP 实际上是什么

NIP 是 github.com/nostr-protocol/nips 仓库中的 markdown 文件。每个文件描述一个特定的功能、格式或约定：如何签名事件、配置文件元数据事件的样子、如何发送直接消息、Lightning zap 请求使用什么格式。

大小各异。最短的 NIPs 不到一页；最长的有几千字。大多数在 500 到 2000 字左右。它们的编写目的是仅从规范就可以实现，所以它们包括消息格式、必需字段和示例事件。

命名约定是 NIP-XX，其中 XX 是一个数字。数字在 NIP 合并时分配；它们不反映优先级或重要性。NIP-05 是关于验证标识符的；NIP-04 是较早的 DM 标准；NIP-01 是核心协议。这些数字跟踪提议顺序，而非功能重要性。

为什么叫"实现可能性"

这个名字是一个刻意的选择。与其他规范传统进行比较。

• RFCs（互联网协议中的"请求意见"）通常最终对互操作性成为强制性的。
• EIPs（以太坊改进提议）通常通过网络升级变成强制性的。
• NIPs 永远是可选的。一个实现 40 个 NIPs 的客户端和一个实现 10 个 NIPs 的客户端都是有效的 Nostr 客户端；它们只是做不同子集的事情。

这意味着 NIPs 永远不会"破坏"现有的实现。一个新 NIP 针对某个功能不会强制较早的客户端做出改变。协议在边缘增长，而核心保持稳定。

NIP 生命周期

一个新 NIP 是如何产生的：

1. 有人注意到一个缺口或需求。 "我们没有标准的方式来做 X。" 可能是客户端开发者、中继运营者或对特定问题感到沮丧的用户。
2. 他们写一个草案。 格式遵循现有 NIPs：标题、目的、规范、示例。
3. 他们向 NIPs 仓库提交拉取请求。
4. 社区审查。 开发者、中继运营者和感兴趣的用户发表评论。根据反馈修改草案。
5. 合并或放弃。 合并的 NIPs 获得一个数字，成为仓库的一部分。被放弃的草案停留在拉取请求历史中。
6. 实现跟随（或不跟随）。 一些 NIPs 在几周内实现。一些等待多年。一些从未被广泛实现。

这个过程很轻量级。没有委员会投票，没有正式批准。如果拉取请求获得广泛的积极反馈并解决明显的需求，它就会被合并。

作为用户需要关心的 NIPs

大多数 NIPs 对用户来说是不可见的。少数影响你的日常体验：

• NIP-01：核心协议。 事件如何被结构化和签名。你看不到它，但所有其他东西都取决于它。
• NIP-05：验证标识符。 给你 you@domain.com 这样的可读名称。我们的 NIP-05 指南涵盖了它。
• NIP-07：浏览器扩展签名。 让网络客户端在无需查看你的私钥的情况下签名。
• NIP-19：Bech32 编码。 为什么你的公钥看起来像 npub1... 而不是原始十六进制。
• NIP-23：长篇文章。 在 Nostr 上启用博客风格的帖子。
• NIP-44：加密 DMs。 现代直接消息标准（比较早的 NIP-04 更好）。
• NIP-57：Zaps。 带有公开收据的 Lightning 小费。
• NIP-98：HTTP 认证。 让 Nostr 身份对常规网站进行身份验证。

作为用户，你受益于所有这些，而无需与它们交互。客户端处理协议细节。

作为开发者需要关心的 NIPs

如果你正在编写或维护 Nostr 客户端，值得阅读的 NIPs 会增长到数十个：

• NIP-01 到 NIP-10（核心机制）。
• NIP-11（中继信息文档）。
• NIP-13（工作量证明，用于反垃圾）。
• NIP-17（礼物包装的 DMs，用于元数据隐藏）。
• NIP-22（事件过期）。
• NIP-27（文本注释引用）。
• NIP-30（自定义表情符号）。
• NIP-31（事件种类）。
• NIP-33（参数化可替换事件）。
• NIP-42（向中继连接的身份验证）。
• NIP-47（Nostr 钱包连接）。
• NIP-50（搜索功能）。
• NIP-65（中继列表元数据）。
• NIP-78（任意自定义应用数据）。

这些是大多数主流客户端实现的。一个支持这个集合加上上面用户面向 NIPs 的客户端覆盖了 95% 的典型使用。

阅读一个 NIP

如果你想直接阅读一个，仓库位于 github.com/nostr-protocol/nips。大多数 NIPs 的结构：

• 标题和描述。 NIP 提议的内容。
• 动机。 为什么需要这个功能。
• 规范。 精确的消息格式、必需字段、验证规则。
• 示例事件。 具体的 JSON，展示符合标准的事件样子。
• 客户端/中继行为。 实现应该如何处理这些事件。

NIPs 的编写方式使开发者实现它们时可以阅读。规范部分是重要的；这是实际协议所在的地方。

部分采用的 NIPs

有些 NIPs 存在，但在客户端中的实现不一致。这造成边界情况，你的体验因客户端而异。

NIP-44（加密 DMs）。 由 Damus、Primal、Amethyst 和大多数主流客户端在 2024-2025 年采用。一些较早的客户端仍然只支持 NIP-04。如果你给一个客户端只支持 NIP-04 的人发送 DM，你的 NIP-44 消息会无声地失败。实际的答案是：使用现代客户端，希望你的对应者也这样做。

NIP-17（礼物包装的 DMs）。 元数据隐藏的 DMs。2026 年的采用在增长但不普遍。在双方客户端都支持该功能的地方，该功能很好；否则它无声地回退到较少私密的 DMs。

NIP-46（远程签署者）。 让硬件签署者或 bunker 应用代表客户端签署事件。在 Amethyst 中得到支持，在其他地方部分支持。

NIP-65（用户的中继列表）。 让用户发布他们首选的中继，以便客户端可以自动路由到正确的地方。采用在改善；较早的客户端忽略它。

NIP-50（搜索）。 允许客户端查询中继进行文本匹配。一些中继支持它；许多不支持。结果是搜索质量不一致。

检查给定的客户端支持哪些 NIPs 是当某些东西不按预期工作时的有用诊断。大多数客户端在其文档中发布其 NIP 支持矩阵。

NIP 流程如何使协议保持一致

没有中央权力，所以一致性来自社交动力。一些观察：

坏的 NIPs 不会传播。 一个重复现有 NIP 或解决错误问题的提议获得最少的采用并悄悄消亡。社区不是正式的，但很有主见。

好的 NIPs 独立实现。 多个客户端开发者阅读提议并独立决定。好主意积累采用者；坏主意则不然。

有时会出现竞争的 NIPs。 对同一功能的两个不同提议可以共存一段时间。通常一个因为更多客户端实现它而赢得实践；有时他们合并。

兼容分叉的演变。 因为 NIPs 是可选的，客户端可以实现 NIP-X-v1，之后升级到 NIP-X-v2，不会破坏只支持 v1 的任何人。协议不会分裂。

这很混乱但有效。协议在五年内已经有了显著的演变，而没有中央治理机构，因为"实现者阅读、实现者决定、实现者编码"的社交机制有足够的对齐来产生一致性。

提议你自己的 NIP

如果你有一个 Nostr 新功能的想法：

1. 首先检查 NIPs 仓库。有人可能已经提议过了。
2. 如果没有，打开一个 GitHub issue 描述你正在解决的问题。
3. 根据反馈，遵循现有格式起草完整的 NIP。
4. 提交拉取请求。
5. 参与讨论。愿意修订。
6. 如果它被合并，很好。如果没有，问题可能有更好的解决方案；考虑为什么。

不是每个好主意都成为 NIP。不是每个 NIP 都成为功能。生态系统有比任何单一开发者可以跟踪的更多提议，过滤器是"社区有足够多的人实现它吗"。这个过滤器是 Nostr 如何在不是自上而下的情况下保持一致的核心。