DAOrayaki策展｜EP23：有可能的Nostr實現 --NIP中文教程 （已全部合並）

發表於 2023-03-28 11:25 作者： 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策展｜EP23：有可能的Nostr實現 --NIP中文教程 （已全部合並）

地址：https://www.coinsdeep.com/article/11779.html

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。