NIP( Nostr implementation possibilities) 即有可能的Nostr實(shí)現(xiàn)。這是一份到目前為止全部被merge的中文NIP教程。

策展點(diǎn)：追蹤和傳播NIP最新進(jìn)展

策展人：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：基本協(xié)議流程描述

定義了每個(gè)人都應(yīng)該執(zhí)行的基本協(xié)議。新的 NIP 可以向此處描述的結(jié)構(gòu)和流程添加新的可選（或強(qiáng)制）字段、消息和功能。

NIP 2：聯(lián)系人列表和昵稱

具有 KIND 3 的特殊事件，即”聯(lián)系人列表”，被定義為具有標(biāo)簽列表 p，每個(gè)標(biāo)簽對應(yīng)于一個(gè)正在跟隨的/已知的配置文件。用途：聯(lián)系人列表備份、配置文件發(fā)現(xiàn)和上下文增強(qiáng)、中繼共享、寵物名稱方案。

NIP3：OpenTimeStamps 事件證明

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

證明可以由中繼自動提供（OTS 二進(jìn)制內(nèi)容僅附加到其接收的事件），也可以由客戶端在首次將事件上傳到中繼時(shí)自行提供，并由客戶端用于顯示事件實(shí)際上”至少與 [OTS 日期] 一樣舊”。

NIP4：加密的直接消息

帶有 kind 4 的特殊事件，表示”加密的直接消息”。它應(yīng)該具有以下屬性：

** content **必須等于用戶想要寫入的任何內(nèi)容的 base64 編碼、AES-256-CBC 加密字符串，使用接收方的公鑰和發(fā)送方的私鑰組合生成的共享密碼進(jìn)行加密；

** tags **必須包含標(biāo)識消息接收者的條目（以便中繼可以自然地將此事件轉(zhuǎn)發(fā)給它們）；

** tags **可能包含一個(gè)條目，該條目標(biāo)識對話中的前一條消息或我們明確回復(fù)的消息（以便可能發(fā)生上下文相關(guān)的、更有組織的對話）。

NIP5：將 NOSTR 密鑰映射到基于 DNS 的 Internet 標(biāo)識符

在 kind 0（ set_metadata）事件上，可以使用互聯(lián)網(wǎng)標(biāo)識符（類似于電子郵件的地址）作為值來指定鍵 “nip05″。客戶端將標(biāo)識符拆分為和，并使用這些值向 https:///.well-known/nostr.json?name=發(fā)出 GET 請求。結(jié)果應(yīng)該是一個(gè)帶有 “names” 密鑰的 JSON 文檔對象，該密鑰應(yīng)該是名稱到十六進(jìn)制格式公鑰的映射。如果給定的公鑰與事件中 set_metadata 的 pubkey 匹配，則客戶端斷定給定的公鑰確實(shí)可以由其標(biāo)識符引用。

客戶端可以支持從_internet identifiers_ 查找用戶的公鑰，流程與上面相同，但相反：首先客戶端獲取_well-known_ URL 并從那里獲取用戶的公鑰，然后它嘗試 為該用戶獲取類型為“0”的事件，并檢查它是否具有匹配的“nip05”。

NIP6: 從助記種子短語推導(dǎo)基本關(guān)鍵字

BIP39用于生成助記種子單詞并從中導(dǎo)出二進(jìn)制種子。

BIP32用于派生路徑 m/44’/1237’/0’/0/0（根據(jù)上SLIP44的 NOSTR 條目）。

這是基本、普通、單鍵客戶端的默認(rèn)設(shè)置。

其他類型的客戶端仍然可以變得花哨，并將其他派生路徑用于自己的其他目的。

NIP7: Web 瀏覽器的 window.nostr 功能

該 window.nostr 對象可以通過網(wǎng)絡(luò)瀏覽器或擴(kuò)展變得可用，并且網(wǎng)站或網(wǎng)絡(luò)應(yīng)用程序可以在檢查其可用性之后使用它。實(shí)施：

• Nos2x（Chrome 及其衍生產(chǎn)品）

• Alby（Chrome 及其衍生產(chǎn)品、Firefox、Safari）

• Blockcore（Chrome 及其衍生產(chǎn)品）

• nos2x-fox（Firefox）

• Flamingo（Chrome 及其衍生產(chǎn)品）

NIP8: 處理提及

本文檔標(biāo)準(zhǔn)化了客戶端對 S 內(nèi)容 text_note 中的其他事件和公鑰的內(nèi)聯(lián)提及的處理。想要允許標(biāo)記的提及的客戶端必須在用戶開始鍵入特殊鍵（例如”@”）或按下某個(gè)按鈕以包括提及等時(shí)顯示自動完成組件或類似的組件–或者這些客戶端可以想出其他方法來明確區(qū)分提及和正常文本。一旦標(biāo)識了提及，客戶端必須將該 pubkey 添加到帶有標(biāo)記 p 的中 .tags，然后將其文本引用（內(nèi)部 .content）替換為其中” index “等于標(biāo)記數(shù)組中相關(guān)標(biāo)記的基于 0 的索引的符號 #[index]。

同樣的過程也適用于提及事件 ID。

NIP9: 事件刪除

表示”刪除”的具有種類 5 的特殊事件被定義為具有一個(gè)或多個(gè) e 標(biāo)簽的列表，每個(gè)標(biāo)簽引用作者請求刪除的事件。每個(gè)標(biāo)簽條目必須包含要刪除的” E “事件 ID。事件 content 字段可能包含描述刪除原因的文本注釋。

中繼應(yīng)刪除或停止發(fā)布與刪除請求相同 id 的任何引用事件。

客戶端應(yīng)隱藏或以其他方式指示引用事件的刪除狀態(tài)。

NIP10: 文本事件中的” e “和” p “標(biāo)簽（類型 1）

這個(gè) NIP 描述了如何在文本事件中使用” e “和” p “標(biāo)簽，特別是那些對其他文本事件的回復(fù)。它幫助客戶端將回復(fù)串接到以原始事件為根的樹中。

” e “已被棄用，因?yàn)楫?dāng)一個(gè)事件引用另一個(gè)事件但不是回復(fù)時(shí)，它會產(chǎn)生難以解決或無法解決的歧義。

標(biāo)有” E “的標(biāo)簽是首選方案，因?yàn)樗试S事件提及其他事件，而不會將它們與或混淆。

” P “標(biāo)簽在文本事件中使用，包含用于記錄誰參與了回復(fù)線程的公鑰列表。

NIP 11: 中繼信息文檔

中繼可以向客戶端提供服務(wù)器元數(shù)據(jù)，以向它們通知能力、管理聯(lián)系人和各種服務(wù)器屬性。這是通過 HTTP 以 JSON 文檔的形式提供的，與中繼的 WebSocket 在相同的 URI 上。

當(dāng)中繼接收到對支持 WebSocket 升級的 URI 具有 Accept 標(biāo)頭 application/nostr json 的 HTTP（S）請求時(shí)，它們應(yīng)該返回包含”name”、  “description”、  “pubkey”、  “contact”、  “supported_nips”、  “software”、 “version”的文檔。詳見原文。

NIP 12:通用標(biāo)記查詢

中繼可以支持任意標(biāo)簽上的訂閱。NIP-01 要求中繼響應(yīng)對 e 和 p 標(biāo)記的查詢。此 NIP 允許查詢事件中存在的任何單字母標(biāo)記。

NIP-01 中描述的對象將擴(kuò)展為包含帶 # 前綴的任意鍵。篩選器中以 # 開頭的任何單字母鍵都是標(biāo)記查詢，并且必須具有字符串?dāng)?shù)組的值。如果事件具有相同名稱的標(biāo)記，并且至少有一個(gè)與篩選器和事件相同的標(biāo)記值，則篩選條件匹配。標(biāo)記名是不帶 # 的字母，標(biāo)記值是第二個(gè)元素。出于標(biāo)記查詢的目的，將忽略后續(xù)元素。

NIP 13: 工作證明

定義了一種為 NOSTR Notes 生成和解釋工作證明的方法。工作量證明（Proof of Work，POW）是一種將計(jì)算工作量的證明添加到筆記的方法。這是一個(gè)承載證明，所有中繼和客戶端都可以使用少量代碼進(jìn)行普遍驗(yàn)證。這種證明可以作為垃圾郵件威懾的一種手段。difficulty 定義為 ID 中 NIP-01 的前導(dǎo)零位的數(shù)量。

NIP14: 文本事件中的主題標(biāo)記

定義了文本（種類：1）事件中”主題”標(biāo)記的使用。瀏覽器通常顯示消息的線程列表。主題標(biāo)簽的內(nèi)容可以在這樣的列表中使用，而不是使用消息的前幾個(gè)詞的更特別的方法。這與電子郵件瀏覽器按主題而不是按內(nèi)容顯示傳入電子郵件列表的方式非常相似。

NIP15: 存儲事件結(jié)束通知

中繼可以支持在發(fā)送了所有存儲的事件時(shí)通知客戶端。

如果中繼支持此 NIP，則中繼應(yīng)在發(fā)送了其保留的所有事件后，以此格式 [“EOSE”,] 向客戶端發(fā)送一條 EOSE 消息，并指示此消息之后的所有事件都是新發(fā)布的。

NIP16: 事件處理

Relay可決定允許可更換和/或短暫事件，包括定期活動、可替換事件、短暫事件以及客戶行為。

NIP19: BECH32 編碼實(shí)體

對 BECH32 格式的字符串進(jìn)行了標(biāo)準(zhǔn)化，這些字符串可用于在客戶端中顯示密鑰、ID 和其他信息。這些格式并不意味著在核心協(xié)議中的任何地方使用，它們僅用于向用戶顯示、復(fù)制粘貼、共享、呈現(xiàn) QR 碼和輸入數(shù)據(jù)。

建議以十六進(jìn)制或二進(jìn)制格式存儲 ID 和密鑰，因?yàn)檫@些格式更接近于核心協(xié)議必須實(shí)際使用的格式。

NIP20: 命令結(jié)果

將事件提交到中繼時(shí)，客戶端目前無法知道事件是否已成功提交到數(shù)據(jù)庫。該 NIP 引入了命令結(jié)果的概念，除了提供有關(guān)事件是否被接受或拒絕的更多信息外，命令結(jié)果與通知類似。

NIP21：Nostr: URL 方案

該 NIP 對通用 URL 方案的使用進(jìn)行了標(biāo)準(zhǔn)化，以實(shí)現(xiàn)網(wǎng)絡(luò)中的最大互操作性和開放性。

NIP22：事件 created_at 限制

中繼可定義其認(rèn)為事件 created_at 可接受的上限和下限。上限和下限必須是中NIP-01定義的 UNIX 時(shí)間戳（以秒為單位）。

如果中繼支持此 NIP，則中繼應(yīng)向客戶端NIP-20發(fā)送命令結(jié)果，說明由于 created_at 時(shí)間戳不在允許的限制范圍內(nèi)，因此未存儲事件。

NIP23：長格式內(nèi)容

該 NIP 定義了 kind:30023（根據(jù) NIP-33 的參數(shù)化可替換事件）長格式文本內(nèi)容，通常稱為“文章”或“博客帖子”。

NIP25：反應(yīng)（reactions）

反應(yīng)是 kind 7 用來對其他標(biāo)注作出反應(yīng)的標(biāo)注（note）。

由 字符串的 content 集合表示的一般反應(yīng)應(yīng)解釋為“喜歡”或“贊成”。

設(shè)置為 – 的反應(yīng) content 應(yīng)解釋為“不喜歡”或“投反對票”。

這 content 可能是一個(gè)表情符號，在這種情況下，它可能被解釋為“喜歡”或“不喜歡”，或者客戶可以在帖子上顯示這個(gè)表情符號的反應(yīng)。

NIP26：委托事件簽名

此 NIP 定義了如何委托事件，以便它們可以由其他密鑰對簽名。

該提議的另一個(gè)應(yīng)用是在與客戶端交互時(shí)抽象出“根”密鑰對的使用。例如，用戶可以為他們希望使用的每個(gè)客戶端生成新的密鑰對，并授權(quán)這些密鑰對代表他們的根 pubkey 生成事件，其中根密鑰對存儲在冷存儲中。

NIP28：公共聊天

該 NIP 為公共聊天頻道、頻道消息和基本客戶端審核定義了新的事件類型。

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

●  40-創(chuàng)建頻道

●  41-通道元數(shù)據(jù)

●  42-通道消息

●  43-隱藏消息

●  44-靜音用戶

以客戶端為中心的審核使客戶端開發(fā)人員可以自行決定他們希望在應(yīng)用程序中包含哪些類型的內(nèi)容，同時(shí)不會對中繼提出額外的要求。

NIP33：參數(shù)化可替換事件

該 NIP 添加了一個(gè)新的事件范圍，允許替換具有相同 d 標(biāo)簽和種類的事件，而不像 NIP-16 僅替換為種類。

NIP36：敏感內(nèi)容/內(nèi)容警告

content-warning 標(biāo)簽使用戶能夠指定事件的內(nèi)容是否需要讀者批準(zhǔn)才能顯示。客戶端可以隱藏內(nèi)容，直到用戶對其進(jìn)行操作。

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

NOSTR 協(xié)議用戶可能具有其他在線身份，例如用戶名、配置文件頁面、密鑰對等。他們可能希望將這些數(shù)據(jù)包含在他們的配置文件元數(shù)據(jù)中，以便客戶端可以解析、驗(yàn)證和顯示這些信息。

NIP40：過期時(shí)間戳

expiration 標(biāo)記使用戶能夠指定一個(gè) UNIX 時(shí)間戳，在該時(shí)間戳?xí)r，消息應(yīng)被視為過期（由中繼和客戶端），并且應(yīng)由中繼刪除。

NIP42：客戶端到中繼的身份驗(yàn)證

該 NIP 為客戶端定義了一種通過簽署臨時(shí)事件來對中繼進(jìn)行身份驗(yàn)證的方法。中繼可能需要客戶端進(jìn)行身份驗(yàn)證才能訪問受限資源。例如，付費(fèi)白名單、聊天交換中涉及的各方、訂閱等。

NIP46：NOSTR 連接

應(yīng)用程序并且簽名者使用選擇的中繼，使用種類 24133 向彼此發(fā)送短暫的加密消息。盡可能少地暴露私鑰給系統(tǒng)（應(yīng)用程序、操作系統(tǒng)、設(shè)備），因?yàn)槊總€(gè)系統(tǒng)都會增加攻擊面。

NIP50：搜索能力

除了通過標(biāo)簽或 ID 進(jìn)行結(jié)構(gòu)化查詢之外，許多 NOSTR 用例還需要某種形式的通用搜索功能。搜索算法的細(xì)節(jié)因事件類型而異，本 NIP 僅描述了用于執(zhí)行此類查詢的通用可擴(kuò)展框架。

NIP51：列表

“列表”事件被定義為具有公共和/或私有標(biāo)簽的列表。公共標(biāo)簽將在事件 tags 中列出。私人標(biāo)簽將在事件 content 中加密。私有標(biāo)簽的加密將使用NIP-04-加密直接消息加密，使用列表作者的私鑰和公鑰作為共享密鑰。應(yīng)為創(chuàng)建的每個(gè)列表類型使用不同的事件種類。

如果列表類型只應(yīng)為每個(gè)用戶定義一次（如“靜音”列表），則列表類型的事件應(yīng)遵循的規(guī)范NIP-16-可替換事件。這些列表可以稱為“可替換列表”。

否則，列表類型的事件應(yīng)遵循的規(guī)范NIP-33-參數(shù)化可替換事件，其中列表名稱將用作“d ”參數(shù)。這些列表可以稱為“參數(shù)化可替換列表”。

NIP56：報(bào)告

報(bào)告是 kind 1984 用于報(bào)告垃圾郵件、非法和明確內(nèi)容的其他注釋的注釋。

該內(nèi)容可以包含由報(bào)告該內(nèi)容的實(shí)體提交的附加信息。

NIP57：閃電擊中

這個(gè) NIP 定義了一種新的筆記類型，稱為閃電類型 9735。這些表示由名為的 zapper Lightning 節(jié)點(diǎn)發(fā)送的已支付的 Lightning 發(fā)票收據(jù)。我們還定義了另一種筆記類型 9734，即 zap request 筆記。

在 NOSTR 上擁有閃電收據(jù)允許客戶顯示來自網(wǎng)絡(luò)上實(shí)體的閃電付款。這些可以用于娛樂或垃圾郵件威懾。

NIP58：徽章

三個(gè)特殊事件用于定義、授予和顯示用戶配置文件中的徽章：

1. “徽章定義”事件被定義為參數(shù)化可替換事件 其中種類 30009 具有 d 標(biāo)簽，該標(biāo)簽具有唯一地標(biāo)識由徽章發(fā)行者發(fā)布的徽章（例如 bravery）的值。可以更新徽章定義。

2. “徽章獎勵”事件是一種 8 具有單個(gè) a 標(biāo)簽引用的事件 “定義徽章”事件和一個(gè)或多個(gè) p 標(biāo)簽，每個(gè)標(biāo)簽對應(yīng)于徽章頒發(fā)者希望授予的每個(gè)公鑰。a 標(biāo)記的值必須遵循中NIP-33定義的格式。授予的徽章是不可改變和不可轉(zhuǎn)讓的。

3. “配置文件徽章”事件定義為參數(shù)化可替換事件 帶有類型 30008 和 d 帶有值 profile_badges 的標(biāo)記。配置文件徽章包含和 e 標(biāo)記對 a 的有序列表，這些標(biāo)記引用 Badge Definition 要顯示的每個(gè)徽章的和 Badge Award。

NIP65：中繼列表元數(shù)據(jù)

這個(gè) NIP 的目的是幫助客戶找到他們關(guān)注的人的事件，幫助標(biāo)記的事件到達(dá)標(biāo)記的人，并幫助 NOSTR 更好地?cái)U(kuò)展。

表示“中繼列表元數(shù)據(jù)”的特殊可替換事件被定義為具有標(biāo)簽列表的 r 事件 10002，作者用于讀取或?qū)懭氲拿總€(gè)中繼都有一個(gè)標(biāo)簽。

NIP58：徽章

三個(gè)特殊事件用于定義、授予和顯示用戶配置文件中的徽章：

1. “徽章定義”事件被定義為參數(shù)化可替換事件 其中種類 30009 具有 d 標(biāo)簽，該標(biāo)簽具有唯一地標(biāo)識由徽章發(fā)行者發(fā)布的徽章（例如 bravery）的值。可以更新徽章定義。

2. “徽章獎勵”事件是一種 8 具有單個(gè) a 標(biāo)簽引用的事件 “定義徽章”事件和一個(gè)或多個(gè) p 標(biāo)簽，每個(gè)標(biāo)簽對應(yīng)于徽章頒發(fā)者希望授予的每個(gè)公鑰。a 標(biāo)記的值必須遵循中NIP-33定義的格式。授予的徽章是不可改變和不可轉(zhuǎn)讓的。

3. “配置文件徽章”事件定義為參數(shù)化可替換事件 帶有類型 30008 和 d 帶有值 profile_badges 的標(biāo)記。配置文件徽章包含和 e 標(biāo)記對 a 的有序列表，這些標(biāo)記引用 Badge Definition 要顯示的每個(gè)徽章的和 Badge Award。

NIP65：中繼列表元數(shù)據(jù)

這個(gè) NIP 的目的是幫助客戶找到他們關(guān)注的人的事件，幫助標(biāo)記的事件到達(dá)標(biāo)記的人，并幫助 NOSTR 更好地?cái)U(kuò)展。

表示“中繼列表元數(shù)據(jù)”的特殊可替換事件被定義為具有標(biāo)簽列表的 r 事件 10002，作者用于讀取或?qū)懭氲拿總€(gè)中繼都有一個(gè)標(biāo)簽。

NIP78：任意自定義應(yīng)用程序數(shù)據(jù)

此 NIP 的目標(biāo)是為不關(guān)心互操作性的自定義應(yīng)用程序啟用遠(yuǎn)程存儲類似的功能。

盡管互操作性很好，但有些應(yīng)用程序不想或不需要互操作性，這對它們來說沒有意義。然而，NOSTR 仍然可以以“自帶數(shù)據(jù)庫”的方式作為這些應(yīng)用程序的通用數(shù)據(jù)存儲，例如：用戶將打開一個(gè)應(yīng)用程序，并以某種方式輸入他們首選的存儲中繼，這將使這些應(yīng)用程序能夠在那里存儲特定于應(yīng)用程序的數(shù)據(jù)。

AD：

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。