NIP( Nostr implementation possibilities) 即有可能的Nostr实现。这是一份到目前为止全部被merge的中文NIP教程。

策展点：追踪和传播NIP最新进展

策展人：Nostr CN-Sherry

更多探讨：Discord Curation-Nostr 频道

• 策展集阅读：https://daorayaki.org/topic/641c85ed3b5a92b5fbf0ec17

• 英文原文：https://github.com/nostr-protocol/nips

• 中文翻译原文：https://github.com/pqingshuang/nostrCN/blob/main/SUMMARY.md

NIP 1：基本协议流程描述

定义了每个人都应该执行的基本协议。新的 NIP 可以向此处描述的结构和流程添加新的可选（或强制）字段、消息和功能。

NIP 2：联系人列表和昵称

具有 KIND 3 的特殊事件，即"联系人列表"，被定义为具有标签列表 p，每个标签对应于一个正在跟随的/已知的配置文件。用途：联系人列表备份、配置文件发现和上下文增强、中继共享、宠物名称方案。

NIP3：OpenTimeStamps 事件证明

_事件ID_必须用作要包含在 OpenTimeStamps Merkle 树中的原始哈希。

证明可以由中继自动提供（OTS 二进制内容仅附加到其接收的事件），也可以由客户端在首次将事件上传到中继时自行提供，并由客户端用于显示事件实际上"至少与 [OTS 日期] 一样旧"。

NIP4：加密的直接消息

带有 kind 4 的特殊事件，表示"加密的直接消息"。它应该具有以下属性：

** content **必须等于用户想要写入的任何内容的 base64 编码、AES-256-CBC 加密字符串，使用接收方的公钥和发送方的私钥组合生成的共享密码进行加密；

** tags **必须包含标识消息接收者的条目（以便中继可以自然地将此事件转发给它们）；

** tags **可能包含一个条目，该条目标识对话中的前一条消息或我们明确回复的消息（以便可能发生上下文相关的、更有组织的对话）。

NIP5：将 NOSTR 密钥映射到基于 DNS 的 Internet 标识符

在 kind 0（ set_metadata）事件上，可以使用互联网标识符（类似于电子邮件的地址）作为值来指定键 "nip05"。客户端将标识符拆分为和，并使用这些值向 https:///.well-known/nostr.json?name=发出 GET 请求。结果应该是一个带有 "names" 密钥的 JSON 文档对象，该密钥应该是名称到十六进制格式公钥的映射。如果给定的公钥与事件中 set_metadata 的 pubkey 匹配，则客户端断定给定的公钥确实可以由其标识符引用。

客户端可以支持从_internet identifiers_ 查找用户的公钥，流程与上面相同，但相反：首先客户端获取_well-known_ URL 并从那里获取用户的公钥，然后它尝试 为该用户获取类型为“0”的事件，并检查它是否具有匹配的“nip05”。

NIP6: 从助记种子短语推导基本关键字

BIP39用于生成助记种子单词并从中导出二进制种子。

BIP32用于派生路径 m/44'/1237'/0'/0/0（根据上SLIP44的 NOSTR 条目）。

这是基本、普通、单键客户端的默认设置。

其他类型的客户端仍然可以变得花哨，并将其他派生路径用于自己的其他目的。

NIP7: Web 浏览器的 window.nostr 功能

该 window.nostr 对象可以通过网络浏览器或扩展变得可用，并且网站或网络应用程序可以在检查其可用性之后使用它。实施：

• Nos2x（Chrome 及其衍生产品）

• Alby（Chrome 及其衍生产品、Firefox、Safari）

• Blockcore（Chrome 及其衍生产品）

• nos2x-fox（Firefox）

• Flamingo（Chrome 及其衍生产品）

NIP8: 处理提及

本文档标准化了客户端对 S 内容 text_note 中的其他事件和公钥的内联提及的处理。想要允许标记的提及的客户端必须在用户开始键入特殊键（例如"@"）或按下某个按钮以包括提及等时显示自动完成组件或类似的组件--或者这些客户端可以想出其他方法来明确区分提及和正常文本。一旦标识了提及，客户端必须将该 pubkey 添加到带有标记 p 的中 .tags，然后将其文本引用（内部 .content）替换为其中" index "等于标记数组中相关标记的基于 0 的索引的符号 #[index]。

同样的过程也适用于提及事件 ID。

NIP9: 事件删除

表示"删除"的具有种类 5 的特殊事件被定义为具有一个或多个 e 标签的列表，每个标签引用作者请求删除的事件。每个标签条目必须包含要删除的" E "事件 ID。事件 content 字段可能包含描述删除原因的文本注释。

中继应删除或停止发布与删除请求相同 id 的任何引用事件。

客户端应隐藏或以其他方式指示引用事件的删除状态。

NIP10: 文本事件中的" e "和" p "标签（类型 1）

这个 NIP 描述了如何在文本事件中使用" e "和" p "标签，特别是那些对其他文本事件的回复。它帮助客户端将回复串接到以原始事件为根的树中。

" e "已被弃用，因为当一个事件引用另一个事件但不是回复时，它会产生难以解决或无法解决的歧义。

标有" E "的标签是首选方案，因为它允许事件提及其他事件，而不会将它们与或混淆。

" P "标签在文本事件中使用，包含用于记录谁参与了回复线程的公钥列表。

NIP 11: 中继信息文档

中继可以向客户端提供服务器元数据，以向它们通知能力、管理联系人和各种服务器属性。这是通过 HTTP 以 JSON 文档的形式提供的，与中继的 WebSocket 在相同的 URI 上。

当中继接收到对支持 WebSocket 升级的 URI 具有 Accept 标头 application/nostr+json 的 HTTP（S）请求时，它们应该返回包含"name"、  "description"、  "pubkey"、  "contact"、  "supported_nips"、  "software"、 "version"的文档。详见原文。

NIP 12:通用标记查询

中继可以支持任意标签上的订阅。NIP-01 要求中继响应对 e 和 p 标记的查询。此 NIP 允许查询事件中存在的任何单字母标记。

NIP-01 中描述的对象将扩展为包含带 # 前缀的任意键。筛选器中以 # 开头的任何单字母键都是标记查询，并且必须具有字符串数组的值。如果事件具有相同名称的标记，并且至少有一个与筛选器和事件相同的标记值，则筛选条件匹配。标记名是不带 # 的字母，标记值是第二个元素。出于标记查询的目的，将忽略后续元素。

NIP 13: 工作证明

定义了一种为 NOSTR Notes 生成和解释工作证明的方法。工作量证明（Proof of Work，POW）是一种将计算工作量的证明添加到笔记的方法。这是一个承载证明，所有中继和客户端都可以使用少量代码进行普遍验证。这种证明可以作为垃圾邮件威慑的一种手段。difficulty 定义为 ID 中 NIP-01 的前导零位的数量。

NIP14: 文本事件中的主题标记

定义了文本（种类：1）事件中"主题"标记的使用。浏览器通常显示消息的线程列表。主题标签的内容可以在这样的列表中使用，而不是使用消息的前几个词的更特别的方法。这与电子邮件浏览器按主题而不是按内容显示传入电子邮件列表的方式非常相似。

NIP15: 存储事件结束通知

中继可以支持在发送了所有存储的事件时通知客户端。

如果中继支持此 NIP，则中继应在发送了其保留的所有事件后，以此格式 ["EOSE",] 向客户端发送一条 EOSE 消息，并指示此消息之后的所有事件都是新发布的。

NIP16: 事件处理

Relay可决定允许可更换和/或短暂事件，包括定期活动、可替换事件、短暂事件以及客户行为。

NIP19: BECH32 编码实体

对 BECH32 格式的字符串进行了标准化，这些字符串可用于在客户端中显示密钥、ID 和其他信息。这些格式并不意味着在核心协议中的任何地方使用，它们仅用于向用户显示、复制粘贴、共享、呈现 QR 码和输入数据。

建议以十六进制或二进制格式存储 ID 和密钥，因为这些格式更接近于核心协议必须实际使用的格式。

NIP20: 命令结果

将事件提交到中继时，客户端目前无法知道事件是否已成功提交到数据库。该 NIP 引入了命令结果的概念，除了提供有关事件是否被接受或拒绝的更多信息外，命令结果与通知类似。

NIP21：Nostr: URL 方案

该 NIP 对通用 URL 方案的使用进行了标准化，以实现网络中的最大互操作性和开放性。

NIP22：事件 created_at 限制

中继可定义其认为事件 created_at 可接受的上限和下限。上限和下限必须是中NIP-01定义的 UNIX 时间戳（以秒为单位）。

如果中继支持此 NIP，则中继应向客户端NIP-20发送命令结果，说明由于 created_at 时间戳不在允许的限制范围内，因此未存储事件。

NIP23：长格式内容

该 NIP 定义了 kind:30023（根据 NIP-33 的参数化可替换事件）长格式文本内容，通常称为“文章”或“博客帖子”。

NIP25：反应（reactions）

反应是 kind 7 用来对其他标注作出反应的标注（note）。

由 + 字符串的 content 集合表示的一般反应应解释为“喜欢”或“赞成”。

设置为 - 的反应 content 应解释为“不喜欢”或“投反对票”。

这 content 可能是一个表情符号，在这种情况下，它可能被解释为“喜欢”或“不喜欢”，或者客户可以在帖子上显示这个表情符号的反应。

NIP26：委托事件签名

此 NIP 定义了如何委托事件，以便它们可以由其他密钥对签名。

该提议的另一个应用是在与客户端交互时抽象出“根”密钥对的使用。例如，用户可以为他们希望使用的每个客户端生成新的密钥对，并授权这些密钥对代表他们的根 pubkey 生成事件，其中根密钥对存储在冷存储中。

NIP28：公共聊天

该 NIP 为公共聊天频道、频道消息和基本客户端审核定义了新的事件类型。

它保留了五种事件类型（40-44）以供立即使用：

●  40-创建频道

●  41-通道元数据

●  42-通道消息

●  43-隐藏消息

●  44-静音用户

以客户端为中心的审核使客户端开发人员可以自行决定他们希望在应用程序中包含哪些类型的内容，同时不会对中继提出额外的要求。

NIP33：参数化可替换事件

该 NIP 添加了一个新的事件范围，允许替换具有相同 d 标签和种类的事件，而不像 NIP-16 仅替换为种类。

NIP36：敏感内容/内容警告

content-warning 标签使用户能够指定事件的内容是否需要读者批准才能显示。客户端可以隐藏内容，直到用户对其进行操作。

NIP39：配置文件中的外部身份

NOSTR 协议用户可能具有其他在线身份，例如用户名、配置文件页面、密钥对等。他们可能希望将这些数据包含在他们的配置文件元数据中，以便客户端可以解析、验证和显示这些信息。

NIP40：过期时间戳

expiration 标记使用户能够指定一个 UNIX 时间戳，在该时间戳时，消息应被视为过期（由中继和客户端），并且应由中继删除。

NIP42：客户端到中继的身份验证

该 NIP 为客户端定义了一种通过签署临时事件来对中继进行身份验证的方法。中继可能需要客户端进行身份验证才能访问受限资源。例如，付费白名单、聊天交换中涉及的各方、订阅等。

NIP46：NOSTR 连接

应用程序并且签名者使用选择的中继，使用种类 24133 向彼此发送短暂的加密消息。尽可能少地暴露私钥给系统（应用程序、操作系统、设备），因为每个系统都会增加攻击面。

NIP50：搜索能力

除了通过标签或 ID 进行结构化查询之外，许多 NOSTR 用例还需要某种形式的通用搜索功能。搜索算法的细节因事件类型而异，本 NIP 仅描述了用于执行此类查询的通用可扩展框架。

NIP51：列表

“列表”事件被定义为具有公共和/或私有标签的列表。公共标签将在事件 tags 中列出。私人标签将在事件 content 中加密。私有标签的加密将使用NIP-04-加密直接消息加密，使用列表作者的私钥和公钥作为共享密钥。应为创建的每个列表类型使用不同的事件种类。

如果列表类型只应为每个用户定义一次（如“静音”列表），则列表类型的事件应遵循的规范NIP-16-可替换事件。这些列表可以称为“可替换列表”。

否则，列表类型的事件应遵循的规范NIP-33-参数化可替换事件，其中列表名称将用作“d ”参数。这些列表可以称为“参数化可替换列表”。

NIP56：报告

报告是 kind 1984 用于报告垃圾邮件、非法和明确内容的其他注释的注释。

该内容可以包含由报告该内容的实体提交的附加信息。

NIP57：闪电击中

这个 NIP 定义了一种新的笔记类型，称为闪电类型 9735。这些表示由名为的 zapper Lightning 节点发送的已支付的 Lightning 发票收据。我们还定义了另一种笔记类型 9734，即 zap request 笔记。

在 NOSTR 上拥有闪电收据允许客户显示来自网络上实体的闪电付款。这些可以用于娱乐或垃圾邮件威慑。

NIP58：徽章

三个特殊事件用于定义、授予和显示用户配置文件中的徽章：

1. “徽章定义”事件被定义为参数化可替换事件 其中种类 30009 具有 d 标签，该标签具有唯一地标识由徽章发行者发布的徽章（例如 bravery）的值。可以更新徽章定义。

2. “徽章奖励”事件是一种 8 具有单个 a 标签引用的事件 “定义徽章”事件和一个或多个 p 标签，每个标签对应于徽章颁发者希望授予的每个公钥。a 标记的值必须遵循中NIP-33定义的格式。授予的徽章是不可改变和不可转让的。

3. “配置文件徽章”事件定义为参数化可替换事件 带有类型 30008 和 d 带有值 profile_badges 的标记。配置文件徽章包含和 e 标记对 a 的有序列表，这些标记引用 Badge Definition 要显示的每个徽章的和 Badge Award。

NIP65：中继列表元数据

这个 NIP 的目的是帮助客户找到他们关注的人的事件，帮助标记的事件到达标记的人，并帮助 NOSTR 更好地扩展。

表示“中继列表元数据”的特殊可替换事件被定义为具有标签列表的 r 事件 10002，作者用于读取或写入的每个中继都有一个标签。

NIP58：徽章

三个特殊事件用于定义、授予和显示用户配置文件中的徽章：

1. “徽章定义”事件被定义为参数化可替换事件 其中种类 30009 具有 d 标签，该标签具有唯一地标识由徽章发行者发布的徽章（例如 bravery）的值。可以更新徽章定义。

2. “徽章奖励”事件是一种 8 具有单个 a 标签引用的事件 “定义徽章”事件和一个或多个 p 标签，每个标签对应于徽章颁发者希望授予的每个公钥。a 标记的值必须遵循中NIP-33定义的格式。授予的徽章是不可改变和不可转让的。

3. “配置文件徽章”事件定义为参数化可替换事件 带有类型 30008 和 d 带有值 profile_badges 的标记。配置文件徽章包含和 e 标记对 a 的有序列表，这些标记引用 Badge Definition 要显示的每个徽章的和 Badge Award。

NIP65：中继列表元数据

这个 NIP 的目的是帮助客户找到他们关注的人的事件，帮助标记的事件到达标记的人，并帮助 NOSTR 更好地扩展。

表示“中继列表元数据”的特殊可替换事件被定义为具有标签列表的 r 事件 10002，作者用于读取或写入的每个中继都有一个标签。

NIP78：任意自定义应用程序数据

此 NIP 的目标是为不关心互操作性的自定义应用程序启用远程存储类似的功能。

尽管互操作性很好，但有些应用程序不想或不需要互操作性，这对它们来说没有意义。然而，NOSTR 仍然可以以“自带数据库”的方式作为这些应用程序的通用数据存储，例如：用户将打开一个应用程序，并以某种方式输入他们首选的存储中继，这将使这些应用程序能够在那里存储特定于应用程序的数据。

DAOrayaki策展

DAOrayaki策展是DAOrayaki社区专注于讨论和策展创意的地方。我们鼓励所有社区成员在这里分享自己的想法、观点及探讨社区中出色的作品和策展历程。

无论你是读者、创作者、策展人或者投资者，欢迎加入DAOrayaki策展，让我们一起打造一个「充满创意、永续存在、社区拥有」的dMedia！

🧐如果你想：

1. 成为话题策展人，获得策展资助

2. 成为策展话题的创作者，获得创作资助

3. 资助感兴趣的策展话题

4. 加入设计和运营策展话题

5. 分享创意和观点

微信联系DAOrayaki-media，或者

加入新平台开始阅读创作：www.daorayaki.org

加入Discord开始讨论分享：https://discord.com/invite/BFeRN57XGE

PC端等着你，移动端稍后就来！

DAOrayaki是一个代表社区意志的去中心化媒体平台。通过构建基础且关键的去中心化媒体组件，链接社区内资助者、创作者、策展者和读者，使其自由的策展、研究、创作、出版和报道各类话题。欢迎通过以下方式提交星际移民、量子计算、DAO、Web3等的相关策展、研究并提案获得资助！

官方网站：daorayaki.org

Discord server: https://discord.gg/wNUPmsGsa4

Medium: https://medium.com/@daorayaki

Email: daorayaki@dorafactory.org

微信助手：DAOrayaki-Media

Twitter: @daorayaki_

小宇宙：DAOrayaki

NIP( Nostr implementation possibilities) 即有可能的Nostr实现。这是一份到目前为止全部被merge的中文NIP教程。

策展点：追踪和传播NIP最新进展

策展人：Nostr CN-Sherry

更多探讨：Discord Curation-Nostr 频道

• 策展集阅读：https://daorayaki.org/topic/641c85ed3b5a92b5fbf0ec17

• 英文原文：https://github.com/nostr-protocol/nips

• 中文翻译原文：https://github.com/pqingshuang/nostrCN/blob/main/SUMMARY.md

NIP 1：基本协议流程描述

定义了每个人都应该执行的基本协议。新的 NIP 可以向此处描述的结构和流程添加新的可选（或强制）字段、消息和功能。

NIP 2：联系人列表和昵称

具有 KIND 3 的特殊事件，即"联系人列表"，被定义为具有标签列表 p，每个标签对应于一个正在跟随的/已知的配置文件。用途：联系人列表备份、配置文件发现和上下文增强、中继共享、宠物名称方案。

NIP3：OpenTimeStamps 事件证明

_事件ID_必须用作要包含在 OpenTimeStamps Merkle 树中的原始哈希。

证明可以由中继自动提供（OTS 二进制内容仅附加到其接收的事件），也可以由客户端在首次将事件上传到中继时自行提供，并由客户端用于显示事件实际上"至少与 [OTS 日期] 一样旧"。

NIP4：加密的直接消息

带有 kind 4 的特殊事件，表示"加密的直接消息"。它应该具有以下属性：

** content **必须等于用户想要写入的任何内容的 base64 编码、AES-256-CBC 加密字符串，使用接收方的公钥和发送方的私钥组合生成的共享密码进行加密；

** tags **必须包含标识消息接收者的条目（以便中继可以自然地将此事件转发给它们）；

** tags **可能包含一个条目，该条目标识对话中的前一条消息或我们明确回复的消息（以便可能发生上下文相关的、更有组织的对话）。

NIP5：将 NOSTR 密钥映射到基于 DNS 的 Internet 标识符

在 kind 0（ set_metadata）事件上，可以使用互联网标识符（类似于电子邮件的地址）作为值来指定键 "nip05"。客户端将标识符拆分为和，并使用这些值向 https:///.well-known/nostr.json?name=发出 GET 请求。结果应该是一个带有 "names" 密钥的 JSON 文档对象，该密钥应该是名称到十六进制格式公钥的映射。如果给定的公钥与事件中 set_metadata 的 pubkey 匹配，则客户端断定给定的公钥确实可以由其标识符引用。

客户端可以支持从_internet identifiers_ 查找用户的公钥，流程与上面相同，但相反：首先客户端获取_well-known_ URL 并从那里获取用户的公钥，然后它尝试 为该用户获取类型为“0”的事件，并检查它是否具有匹配的“nip05”。

NIP6: 从助记种子短语推导基本关键字

BIP39用于生成助记种子单词并从中导出二进制种子。

BIP32用于派生路径 m/44'/1237'/0'/0/0（根据上SLIP44的 NOSTR 条目）。

这是基本、普通、单键客户端的默认设置。

其他类型的客户端仍然可以变得花哨，并将其他派生路径用于自己的其他目的。

NIP7: Web 浏览器的 window.nostr 功能

该 window.nostr 对象可以通过网络浏览器或扩展变得可用，并且网站或网络应用程序可以在检查其可用性之后使用它。实施：

• Nos2x（Chrome 及其衍生产品）

• Alby（Chrome 及其衍生产品、Firefox、Safari）

• Blockcore（Chrome 及其衍生产品）

• nos2x-fox（Firefox）

• Flamingo（Chrome 及其衍生产品）

NIP8: 处理提及

本文档标准化了客户端对 S 内容 text_note 中的其他事件和公钥的内联提及的处理。想要允许标记的提及的客户端必须在用户开始键入特殊键（例如"@"）或按下某个按钮以包括提及等时显示自动完成组件或类似的组件--或者这些客户端可以想出其他方法来明确区分提及和正常文本。一旦标识了提及，客户端必须将该 pubkey 添加到带有标记 p 的中 .tags，然后将其文本引用（内部 .content）替换为其中" index "等于标记数组中相关标记的基于 0 的索引的符号 #[index]。

同样的过程也适用于提及事件 ID。

NIP9: 事件删除

表示"删除"的具有种类 5 的特殊事件被定义为具有一个或多个 e 标签的列表，每个标签引用作者请求删除的事件。每个标签条目必须包含要删除的" E "事件 ID。事件 content 字段可能包含描述删除原因的文本注释。

中继应删除或停止发布与删除请求相同 id 的任何引用事件。

客户端应隐藏或以其他方式指示引用事件的删除状态。

NIP10: 文本事件中的" e "和" p "标签（类型 1）

这个 NIP 描述了如何在文本事件中使用" e "和" p "标签，特别是那些对其他文本事件的回复。它帮助客户端将回复串接到以原始事件为根的树中。

" e "已被弃用，因为当一个事件引用另一个事件但不是回复时，它会产生难以解决或无法解决的歧义。

标有" E "的标签是首选方案，因为它允许事件提及其他事件，而不会将它们与或混淆。

" P "标签在文本事件中使用，包含用于记录谁参与了回复线程的公钥列表。

NIP 11: 中继信息文档

中继可以向客户端提供服务器元数据，以向它们通知能力、管理联系人和各种服务器属性。这是通过 HTTP 以 JSON 文档的形式提供的，与中继的 WebSocket 在相同的 URI 上。

当中继接收到对支持 WebSocket 升级的 URI 具有 Accept 标头 application/nostr+json 的 HTTP（S）请求时，它们应该返回包含"name"、  "description"、  "pubkey"、  "contact"、  "supported_nips"、  "software"、 "version"的文档。详见原文。

NIP 12:通用标记查询

中继可以支持任意标签上的订阅。NIP-01 要求中继响应对 e 和 p 标记的查询。此 NIP 允许查询事件中存在的任何单字母标记。

NIP-01 中描述的对象将扩展为包含带 # 前缀的任意键。筛选器中以 # 开头的任何单字母键都是标记查询，并且必须具有字符串数组的值。如果事件具有相同名称的标记，并且至少有一个与筛选器和事件相同的标记值，则筛选条件匹配。标记名是不带 # 的字母，标记值是第二个元素。出于标记查询的目的，将忽略后续元素。

NIP 13: 工作证明

定义了一种为 NOSTR Notes 生成和解释工作证明的方法。工作量证明（Proof of Work，POW）是一种将计算工作量的证明添加到笔记的方法。这是一个承载证明，所有中继和客户端都可以使用少量代码进行普遍验证。这种证明可以作为垃圾邮件威慑的一种手段。difficulty 定义为 ID 中 NIP-01 的前导零位的数量。

NIP14: 文本事件中的主题标记

定义了文本（种类：1）事件中"主题"标记的使用。浏览器通常显示消息的线程列表。主题标签的内容可以在这样的列表中使用，而不是使用消息的前几个词的更特别的方法。这与电子邮件浏览器按主题而不是按内容显示传入电子邮件列表的方式非常相似。

NIP15: 存储事件结束通知

中继可以支持在发送了所有存储的事件时通知客户端。

如果中继支持此 NIP，则中继应在发送了其保留的所有事件后，以此格式 ["EOSE",] 向客户端发送一条 EOSE 消息，并指示此消息之后的所有事件都是新发布的。

NIP16: 事件处理

Relay可决定允许可更换和/或短暂事件，包括定期活动、可替换事件、短暂事件以及客户行为。

NIP19: BECH32 编码实体

对 BECH32 格式的字符串进行了标准化，这些字符串可用于在客户端中显示密钥、ID 和其他信息。这些格式并不意味着在核心协议中的任何地方使用，它们仅用于向用户显示、复制粘贴、共享、呈现 QR 码和输入数据。

建议以十六进制或二进制格式存储 ID 和密钥，因为这些格式更接近于核心协议必须实际使用的格式。

NIP20: 命令结果

将事件提交到中继时，客户端目前无法知道事件是否已成功提交到数据库。该 NIP 引入了命令结果的概念，除了提供有关事件是否被接受或拒绝的更多信息外，命令结果与通知类似。

NIP21：Nostr: URL 方案

该 NIP 对通用 URL 方案的使用进行了标准化，以实现网络中的最大互操作性和开放性。

NIP22：事件 created_at 限制

中继可定义其认为事件 created_at 可接受的上限和下限。上限和下限必须是中NIP-01定义的 UNIX 时间戳（以秒为单位）。

如果中继支持此 NIP，则中继应向客户端NIP-20发送命令结果，说明由于 created_at 时间戳不在允许的限制范围内，因此未存储事件。

NIP23：长格式内容

该 NIP 定义了 kind:30023（根据 NIP-33 的参数化可替换事件）长格式文本内容，通常称为“文章”或“博客帖子”。

NIP25：反应（reactions）

反应是 kind 7 用来对其他标注作出反应的标注（note）。

由 + 字符串的 content 集合表示的一般反应应解释为“喜欢”或“赞成”。

设置为 - 的反应 content 应解释为“不喜欢”或“投反对票”。

这 content 可能是一个表情符号，在这种情况下，它可能被解释为“喜欢”或“不喜欢”，或者客户可以在帖子上显示这个表情符号的反应。

NIP26：委托事件签名

此 NIP 定义了如何委托事件，以便它们可以由其他密钥对签名。

该提议的另一个应用是在与客户端交互时抽象出“根”密钥对的使用。例如，用户可以为他们希望使用的每个客户端生成新的密钥对，并授权这些密钥对代表他们的根 pubkey 生成事件，其中根密钥对存储在冷存储中。

NIP28：公共聊天

该 NIP 为公共聊天频道、频道消息和基本客户端审核定义了新的事件类型。

它保留了五种事件类型（40-44）以供立即使用：

●  40-创建频道

●  41-通道元数据

●  42-通道消息

●  43-隐藏消息

●  44-静音用户

以客户端为中心的审核使客户端开发人员可以自行决定他们希望在应用程序中包含哪些类型的内容，同时不会对中继提出额外的要求。

NIP33：参数化可替换事件

该 NIP 添加了一个新的事件范围，允许替换具有相同 d 标签和种类的事件，而不像 NIP-16 仅替换为种类。

NIP36：敏感内容/内容警告

content-warning 标签使用户能够指定事件的内容是否需要读者批准才能显示。客户端可以隐藏内容，直到用户对其进行操作。

NIP39：配置文件中的外部身份

NOSTR 协议用户可能具有其他在线身份，例如用户名、配置文件页面、密钥对等。他们可能希望将这些数据包含在他们的配置文件元数据中，以便客户端可以解析、验证和显示这些信息。

NIP40：过期时间戳

expiration 标记使用户能够指定一个 UNIX 时间戳，在该时间戳时，消息应被视为过期（由中继和客户端），并且应由中继删除。

NIP42：客户端到中继的身份验证

该 NIP 为客户端定义了一种通过签署临时事件来对中继进行身份验证的方法。中继可能需要客户端进行身份验证才能访问受限资源。例如，付费白名单、聊天交换中涉及的各方、订阅等。

NIP46：NOSTR 连接

应用程序并且签名者使用选择的中继，使用种类 24133 向彼此发送短暂的加密消息。尽可能少地暴露私钥给系统（应用程序、操作系统、设备），因为每个系统都会增加攻击面。

NIP50：搜索能力

除了通过标签或 ID 进行结构化查询之外，许多 NOSTR 用例还需要某种形式的通用搜索功能。搜索算法的细节因事件类型而异，本 NIP 仅描述了用于执行此类查询的通用可扩展框架。

NIP51：列表

“列表”事件被定义为具有公共和/或私有标签的列表。公共标签将在事件 tags 中列出。私人标签将在事件 content 中加密。私有标签的加密将使用NIP-04-加密直接消息加密，使用列表作者的私钥和公钥作为共享密钥。应为创建的每个列表类型使用不同的事件种类。

如果列表类型只应为每个用户定义一次（如“静音”列表），则列表类型的事件应遵循的规范NIP-16-可替换事件。这些列表可以称为“可替换列表”。

否则，列表类型的事件应遵循的规范NIP-33-参数化可替换事件，其中列表名称将用作“d ”参数。这些列表可以称为“参数化可替换列表”。

NIP56：报告

报告是 kind 1984 用于报告垃圾邮件、非法和明确内容的其他注释的注释。

该内容可以包含由报告该内容的实体提交的附加信息。

NIP57：闪电击中

这个 NIP 定义了一种新的笔记类型，称为闪电类型 9735。这些表示由名为的 zapper Lightning 节点发送的已支付的 Lightning 发票收据。我们还定义了另一种笔记类型 9734，即 zap request 笔记。

在 NOSTR 上拥有闪电收据允许客户显示来自网络上实体的闪电付款。这些可以用于娱乐或垃圾邮件威慑。

NIP58：徽章

三个特殊事件用于定义、授予和显示用户配置文件中的徽章：

1. “徽章定义”事件被定义为参数化可替换事件 其中种类 30009 具有 d 标签，该标签具有唯一地标识由徽章发行者发布的徽章（例如 bravery）的值。可以更新徽章定义。

2. “徽章奖励”事件是一种 8 具有单个 a 标签引用的事件 “定义徽章”事件和一个或多个 p 标签，每个标签对应于徽章颁发者希望授予的每个公钥。a 标记的值必须遵循中NIP-33定义的格式。授予的徽章是不可改变和不可转让的。

3. “配置文件徽章”事件定义为参数化可替换事件 带有类型 30008 和 d 带有值 profile_badges 的标记。配置文件徽章包含和 e 标记对 a 的有序列表，这些标记引用 Badge Definition 要显示的每个徽章的和 Badge Award。

NIP65：中继列表元数据

这个 NIP 的目的是帮助客户找到他们关注的人的事件，帮助标记的事件到达标记的人，并帮助 NOSTR 更好地扩展。

表示“中继列表元数据”的特殊可替换事件被定义为具有标签列表的 r 事件 10002，作者用于读取或写入的每个中继都有一个标签。

NIP58：徽章

三个特殊事件用于定义、授予和显示用户配置文件中的徽章：

1. “徽章定义”事件被定义为参数化可替换事件 其中种类 30009 具有 d 标签，该标签具有唯一地标识由徽章发行者发布的徽章（例如 bravery）的值。可以更新徽章定义。

2. “徽章奖励”事件是一种 8 具有单个 a 标签引用的事件 “定义徽章”事件和一个或多个 p 标签，每个标签对应于徽章颁发者希望授予的每个公钥。a 标记的值必须遵循中NIP-33定义的格式。授予的徽章是不可改变和不可转让的。

3. “配置文件徽章”事件定义为参数化可替换事件 带有类型 30008 和 d 带有值 profile_badges 的标记。配置文件徽章包含和 e 标记对 a 的有序列表，这些标记引用 Badge Definition 要显示的每个徽章的和 Badge Award。

NIP65：中继列表元数据

这个 NIP 的目的是帮助客户找到他们关注的人的事件，帮助标记的事件到达标记的人，并帮助 NOSTR 更好地扩展。

表示“中继列表元数据”的特殊可替换事件被定义为具有标签列表的 r 事件 10002，作者用于读取或写入的每个中继都有一个标签。

NIP78：任意自定义应用程序数据

此 NIP 的目标是为不关心互操作性的自定义应用程序启用远程存储类似的功能。

尽管互操作性很好，但有些应用程序不想或不需要互操作性，这对它们来说没有意义。然而，NOSTR 仍然可以以“自带数据库”的方式作为这些应用程序的通用数据存储，例如：用户将打开一个应用程序，并以某种方式输入他们首选的存储中继，这将使这些应用程序能够在那里存储特定于应用程序的数据。

DAOrayaki策展

DAOrayaki策展是DAOrayaki社区专注于讨论和策展创意的地方。我们鼓励所有社区成员在这里分享自己的想法、观点及探讨社区中出色的作品和策展历程。

无论你是读者、创作者、策展人或者投资者，欢迎加入DAOrayaki策展，让我们一起打造一个「充满创意、永续存在、社区拥有」的dMedia！

🧐如果你想：

1. 成为话题策展人，获得策展资助

2. 成为策展话题的创作者，获得创作资助

3. 资助感兴趣的策展话题

4. 加入设计和运营策展话题

5. 分享创意和观点

微信联系DAOrayaki-media，或者

加入新平台开始阅读创作：www.daorayaki.org

加入Discord开始讨论分享：https://discord.com/invite/BFeRN57XGE

PC端等着你，移动端稍后就来！

DAOrayaki是一个代表社区意志的去中心化媒体平台。通过构建基础且关键的去中心化媒体组件，链接社区内资助者、创作者、策展者和读者，使其自由的策展、研究、创作、出版和报道各类话题。欢迎通过以下方式提交星际移民、量子计算、DAO、Web3等的相关策展、研究并提案获得资助！

官方网站：daorayaki.org

Discord server: https://discord.gg/wNUPmsGsa4

Medium: https://medium.com/@daorayaki

Email: daorayaki@dorafactory.org

微信助手：DAOrayaki-Media

Twitter: @daorayaki_

小宇宙：DAOrayaki