Nostr NIPs explained: プロトコル仕様書

Nostr の進化は NIP を通じて起こります。NIP は誰でも提案できる短い仕様書です。zap や暗号化 DM などの新機能がプロトコルにどのように取り込まれるかを理解したい場合、NIP が答えです。

このガイドでは、NIP とは何か、ガバナンスメカニズムとしてどのように機能するか、そして技術的に知りたい場合どの NIP を読むべきかについて説明します。

NIP は GitHub 上の短い markdown ドキュメントで、Nostr 機能の実装方法を提案します。クライアント開発者はどれをサポートするかを選択します。十分な実装者が採用すると、NIP は「実現」します。広く使用されている NIP のコアセットは約30個です。完全なリストは100に近い数です。

準備ができたら、 @nostr.blog アドレスを取得 →

NIP が実際に何であるか

NIP は github.com/nostr-protocol/nips リポジトリ内の markdown ファイルです。各ファイルは特定の機能、フォーマット、または慣例を説明します。つまり、イベントに署名する方法、プロファイルメタデータイベントの外観、直接メッセージの送信方法、Lightning zap リクエストが使用する形式です。

サイズはさまざまです。最短の NIP は1ページ未満で、最長のものは数千語です。ほとんどは500〜2000語です。仕様だけで実装可能になるよう書かれているため、メッセージ形式、必須フィールド、およびイベント例が含まれています。

命名規則は NIP-XX で、XX は番号です。番号は NIP がマージされるときに割り当てられます。優先度や重要性は反映しません。NIP-05 は検証済み識別子に関するものです。NIP-04 は古い DM 標準です。NIP-01 はコアプロトコルです。番号は提案の順序を追跡し、機能の重要性ではなく、提案の順序を追跡します。

なぜ「実装の可能性」なのか

名前は意図的な選択です。他の仕様伝統と比較してください。

• RFC（インターネット プロトコルのリクエスト フォー コメント）は相互運用性のために必須になることがよくあります。
• EIP（イーサリアム改善提案）はネットワークアップグレードによって必須になることがよくあります。
• NIP は永遠にオプションです。40個の NIP を実装するクライアントと10個の NIP を実装するクライアントは両方とも有効な Nostr クライアントです。異なるサブセットのことをするだけです。

これは NIP が既存の実装を「破壊する」ことがないことを意味します。何か機能についての新しい NIP は古いクライアントに変更を強制しません。プロトコルはエッジで成長し、コアは安定しています。

NIP のライフサイクル

新しい NIP がどのように存在するようになるか：

1. 誰かがギャップまたはニーズに気付きます。 「X をする標準的な方法がありません。」クライアント開発者、リレー オペレーター、または特定の問題で不満を持つユーザーの場合があります。
2. 彼らはドラフトを書きます。 フォーマットは既存の NIP に従っています：タイトル、目的、仕様、例。
3. NIPs リポジトリにプルリクエストを送信します。
4. コミュニティがレビューします。 開発者、リレー オペレーター、および関心のあるユーザーがコメントします。ドラフトはフィードバックに基づいて修正されます。
5. マージするか放棄するか。 マージされた NIP は番号を取得し、リポジトリの一部になります。放棄されたドラフトはプルリクエスト履歴に残ります。
6. 実装に続く（またはそうでない）。 一部の NIP は数週間以内に実装されます。一部は何年も待機します。一部は広くは実装されません。

プロセスは軽量です。委員会の投票はなく、正式な承認もありません。プルリクエストが広く肯定的なフィードバックを得て、明らかなニーズに対応する場合、それはマージされます。

ユーザーとして重要な NIP

ほとんどの NIP はユーザーには見えません。少数のものがあなたの日常経験に影響します：

• NIP-01：コアプロトコル。 イベントがどのように構造化され署名されるか。それを見ることはありませんが、他のすべてはそれに依存しています。
• NIP-05：検証済み識別子。 you@domain.com の読みやすい名前を提供します。NIP-05 ガイドにはそれが含まれています。
• NIP-07：ブラウザ拡張機能の署名。 Web クライアントが秘密鍵を見ずに署名することができます。
• NIP-19：Bech32 エンコーディング。 公開鍵が生の16進数ではなく npub1... のように見える理由。
• NIP-23：長編記事。 Nostr でブログスタイルの投稿を有効にします。
• NIP-44：暗号化 DM。 最新の直接メッセージング標準（古い NIP-04 より優れています）。
• NIP-57：Zap。 公開レシートを含む Lightning チップ。
• NIP-98：HTTP 認証。 Nostr ID が通常の Web サイトに認証することを許可します。

ユーザーとして、プロトコルの詳細と相互作用することなく、これらすべてから恩恵を受けます。クライアントがプロトコル詳細を処理します。

開発者として重要な NIP

Nostr クライアントを作成または維持している場合、読む価値のある NIP は数十に増えます：

• NIP-01 から NIP-10（コア メカニクス）。
• NIP-11（リレー情報ドキュメント）。
• NIP-13（スパム耐性のための作業証明）。
• NIP-17（メタデータを隠すためのギフトラップ DM）。
• NIP-22（イベント有効期限）。
• NIP-27（テキスト ノート参照）。
• NIP-30（カスタム絵文字）。
• NIP-31（イベント種類）。
• NIP-33（パラメータ化された置き換え可能イベント）。
• NIP-42（リレーへの接続認証）。
• NIP-47（Nostr ウォレット接続）。
• NIP-50（検索機能）。
• NIP-65（リレー リスト メタデータ）。
• NIP-78（任意のカスタムアプリ データ）。

これらはほとんどの主流クライアントが実装するものです。このセットに加えて上記のユーザー向け NIP をサポートするクライアントは、典型的な使用の95% をカバーしています。

NIP の読み方

1つを直接読みたい場合、リポジトリは github.com/nostr-protocol/nips にあります。ほとんどの NIP の構造：

• タイトルと説明。 NIP が提案するもの。
• 動機。 機能が必要な理由。
• 仕様。 正確なメッセージ形式、必須フィールド、検証ルール。
• イベント例。 準拠イベントの外観を示す具体的な JSON。
• クライアント/リレー動作。 実装がイベントをどのように処理するかについて。

NIP はそれを実装する開発者が読めるようにに書かれています。仕様セクションが重要なものです。実際のプロトコルがそこに存在します。

部分的な採用を持つ NIP

一部の NIP はいますが、クライアント間で実装が矛盾しています。これにより、エクスペリエンスがクライアントによって異なるエッジ ケースが発生します。

NIP-44（暗号化 DM）。 Damus、Primal、Amethyst、および2024-2025年のほとんどの主流クライアントによって採用されました。一部の古いクライアントは NIP-04 のみをサポートしています。NIP-04 のみをサポートするクライアントを持つ人に DM を送信する場合、NIP-44 メッセージは静かに失敗します。実際的な答え：最新のクライアントを使用し、対応者も使用することを期待してください。

NIP-17（ギフトラップ DM）。 メタデータ非表示 DM。2026年の採用は増加していますが、普遍的ではありません。機能は両方の当事者のクライアントがそれをサポートする場合は素晴らしいです。そうしないと、プライバシーが低い DM に静かにフォールバックします。

NIP-46（リモート署名者）。 ハードウェア署名者またはバンカー アプリがクライアントの代わりにイベントに署名することを許可します。Amethyst でサポートされ、他の場所では部分的です。

NIP-65（ユーザーのリレーリスト）。 ユーザーが優先リレーを公開して、クライアントが自動的に正しい場所にルーティングできるようにします。採用は改善されています。古いクライアントはそれを無視します。

NIP-50（検索）。 クライアントがテキストマッチについてリレーをクエリできます。一部のリレーはそれをサポートします。多くはしません。その結果、検索品質は矛盾しています。

与えられたクライアントがどの NIP をサポートしているかをチェックすることは、何かが期待どおりに機能しない場合の便利な診断です。ほとんどのクライアントは、ドキュメントで NIP サポート マトリックスを公開しています。

NIP プロセスがプロトコルを一貫性のある方法を保つ方法

中央の権威がないため、一貫性は社会動力学から来ます。いくつかの観察：

悪い NIP は伝播しません。 既存の NIP を複製するか、間違った問題を解決する提案は最小限の採用を得て、静かに死にます。コミュニティは正式ではありませんが、意見があります。

良い NIP は独立して実装されます。 複数のクライアント開発者が提案を読み、独立して決定します。良いアイデアは採用者を蓄積します。悪いアイデアはしません。

競合する NIP が時々現れます。 同じ機能についての2つの異なる提案は、しばらくの間共存できます。通常、より多くのクライアントがそれを実装するため、実践で1つが勝ちます。時々彼らはマージします。

フォーク互換性進化。 NIP はオプションであるため、クライアントは NIP-X-v1 を実装してから NIP-X-v2 にアップグレードしてから、v1 のみをサポートする誰かを壊さずに切ることができます。プロトコルは分割されません。

これは厄介ですが機能しています。プロトコルは、社会メカニズムが「実装者が読む、実装者が決める、実装者がコーディングする」十分な一貫性を備えているため、中央ガバナンス機関なしで5年で大幅に進化しました。

独自の NIP を提案する

Nostr 機能についてのアイデアがある場合：

1. まず NIP リポジトリをチェックしてください。誰かがすでにそれを提案しているかもしれません。
2. そうでない場合は、解決している問題を説明する GitHub イシューを開きます。
3. フィードバックに基づいて、既存のフォーマットに従って完全な NIP をドラフトします。
4. プルリクエストを送信してください。
5. ディスカッションに参加してください。修正する意思を示してください。
6. マージされると、素晴らしい。そうでない場合、問題はより良い解決策を持つことができます。なぜを検討してください。

すべての良いアイデアが NIP になるわけではありません。すべての NIP が機能になるわけではありません。エコシステムには、任意の単一開発者が追跡できるよりも多くの提案があり、フィルターは「コミュニティの十分な実装ですか？」です。そのフィルターは Nostr がトップダウンなしで一貫性を保つ方法の核です。