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 仍然可以以“自帶數據庫”的方式作為這些應用程序的通用數據存儲，例如：用戶將打開一個應用程序，并以某種方式輸入他們首選的存儲中繼，這將使這些應用程序能夠在那里存儲特定于應用程序的數據。

AD：

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。