Nostrプロトコルを分かりやすく説明

プロトコルはプログラムがお互いに通信する方法の規則のセットです。プラットフォームはあなたの代わりにそれらのプログラムを実行する企業です。Twitterはプラットフォームです。電子メールはプロトコルです。Nostrはプロトコルです。

この区別は重要です。なぜなら、プロトコルとプラットフォームは異なる障害モード、異なるコスト構造、異なる将来を持っているからです。このガイドでは、Nostrが特にプロトコルである理由、それが実際に何を意味するか、そしてなぜこの設計が意図的に小さく保たれているかについて説明します。

TL;DR. Nostrは暗号署名を備えたpub/subメッセージングプロトコルです。小さなイベント形式と、クライアントがrelayを通じてこれらのイベントを送受信する単純な方法を定義します。どの企業も所有していません。誰でもクライアントを書いたり、relayを実行したり、拡張機能を提案したりできます。コアスペックは数ページに収まります。

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

プロトコルが実際に何であるかについて

電子メールは良い比較です。GmailからOutlookに電子メールを送信する場合、GmailはOutlookの許可は必要ありません。両方のサービスはSMTP（電子メールプロトコル）を話し、SMTPは1つのメールサーバーが別のメールサーバーにメッセージを渡すために必要なすべてを定義します。サーバーは異なる企業です。プロトコルは中立的な合意です。

Nostrは同じ方法で機能します。Nostrイベント（投稿、いいね、フォロー）は、プロトコルで定義された特定の形状を持つJSONオブジェクトです。relayは、その形状に従うイベントを受け入れ、保存、転送することに同意する任意のサーバーです。Nostrを話す任意の2つのクライアントは、Nostrを話す任意のrelayを通じて相互作用でき、誰がそのいずれかを作ったかに関係なく。

プロトコルは中立的な合意です。実装は何でも自由です。

最も少ないセンテンスでのNostr仕様

3つのルールでほぼすべてをカバーしています。

1. イベントは、id、pubkey、created_at、kind、tags、content、sigを持つJSONオブジェクトです。idは他のフィールドのハッシュです。sigはpubkeyの秘密鍵を使用してidに対するSchnorr署名です。
2. relayはWebSocket経由で有効なイベントを受け入れ、著者、種類、タグ、または時間によってイベントをフィルタリングするサブスクリプションを提供します。
3. クライアントはイベントに署名してrelayに発行します。フィルタを持つrelayにサブスクライブすることでイベントを読みます。

これがコアプロトコルです。すべての高度な機能（長文の記事、zap、DM、コミュニティ、リスト）はこのフレームに適合し、変更することなく拡張されます。

プロトコルが小さく保たれている理由

ほとんどのプロトコルは付加によって成長します。すべてのユースケースはスペックに追加されます。毎十年、スペックは前の十年より大きくなります。HTTPは現在数百ページです。電子メールは一握りのRFCから複雑に成長しました。Nostrはデザインによってこれを回避しています。

メカニズムはNIP（Nostr Implementation Possibilities）です。新しい機能はコアスペックに追加されません。それらはオプションのNIPとして提案されます。クライアントは気にかけるNIPを実装します。他のクライアントはそれらを無視します。人気のあるNIPは十分な実装がそれを話すため、プラクティカルなプロトコルの一部になります。人気のないNIPは儀式なしで消えます。

これは、コアが永遠に小さく（重要な不変：署名付きイベント、オープンrelay、ポータブルアイデンティティ）、エッジが永遠に柔軟であることを意味します（新機能は既存のクライアントを破壊することなく進化します）。2022年のNostrクライアントは2026年でも機能します。コアが変わらなかったからです。単に新しいクライアントより少ない機能を行うだけです。

プロトコルとプラットフォーム、具体的に

ユーザーとして実感できる5つの実践的な違い。

アイデンティティ。 プラットフォームでは、あなたのアカウントは企業が所有しています。プロトコルでは、あなたのアカウントは所有する暗号アイデンティティです。誰もそれを奪うことはできません。

データ。 プラットフォームでは、あなたの投稿はそれらのデータベースに存在します。プロトコルでは、あなたの投稿は複数の独立したrelayに存在します。1つが消えても、他のものはそれらを持っています。

機能の速度。 プラットフォームでは、機能は企業が決定するときにリリースされます。プロトコルでは、機能は任意の実装者が書くときにリリースされます。これは何らかの点では遅い（中央のロードマップがない）が、別の点では速い（多くの並列実験）です。

マネタイズ。 プラットフォームでは、企業がすべてのマネタイズをキャプチャします。プロトコルでは、マネタイズはユーザーと実装者が同意することです。Nostrはzap（Lightning経由のピアツーピアチップ）を持っています。それがカルチャーに適合したからです。別のプロトコルコミュニティは異なるノルムに到達することがあります。

障害モード。 プラットフォームは完全に消えることができます。プロトコルは消えることはできません。1つの実装者が活動を続ける限り、プロトコルは存在します。Nostrは、fiatjafが（オリジナルの著者）明日消えたとしても、ネットワークは変更なしに実行を続けるように設計されています。

プロトコルが明確に行わないことについて

意図的にスペックから除外された5つのこと。

モデレーション。 プロトコルは何のコンテンツが受け入れられるかを決定しません。各relayは独自のルールを持っています。各クライアントは独自のフィルタを持っています。各ユーザーは独自のミュートリストを持っています。モデレーションはエッジで発生します。コアではありません。

検索。 プロトコル定義の検索はありません。いくつかのrelayはテキストをインデックス化します。他のものはしません。検索が必要なクライアントは、検索対応のrelayに依存するか、独自のインデックス化を実行するかのいずれかです。不在は意図的です。プロトコルを中立に保ちます。

ランキング。 「For You」フィードはありません。エンゲージメント加重はありません。クライアントはデフォルトではイベントをタイムスタンプで表示します。他の順序付けはクライアントレベルの決定です。プロトコルのものではありません。

発見。 レコメンデーションエンジンはありません。フォローする新しいアカウントの検索はクライアント機能です。プロトコル機能ではありません。いくつかのクライアントはこれに重く投資します（Primal）。他のものはユーザーに任せます（Damus）。

回復。 アカウントリセットはありません。秘密鍵を失うと、アカウントを失います。プロトコルは鍵ローテーションを含める可能性がありますが、そうしません。トレードオフは現実的であり、コミュニティは特定のメカニズムに同意していません。これは継続的な領域です（NIP-26、NIP-41ドラフト）。

各省略は選択です。プロトコルは、すべての問題をプロトコルレベルで解決することを拒否することにより、小さく保たれます。

Nostrが何になるかを決定する人

誰もいなくて、誰もが。

Nostr Foundationはありません。企業の作業グループはありません。運営委員会はありません。エコシステム内で最も集中した権限は、NIPが提案されるfiatjafのGitHubリポジトリです。それでも、それはただの調整ポイントに過ぎず、ゲートキーパーではありません。

提案されたNIPはクライアント開発者によって読まれます。人気のあるものが実装されます。3つの主要なクライアントが実装するNIPはプロトコルの一部です。1つの開発者が書いたが、他の誰も気にかけないNIPは、GitHub上のドキュメントに過ぎません。

このプロセスは混乱しています。調整の問題、重複した提案、そして時々政治があります。それはまた、特定の方法で弾力的です。単一の党がそれに悪い決定をすることで台無しにすることはできません。悪い決定は単に採用されません。プロトコルは、独裁ではなく、開発者の選択の重みによって大まかな方向に進化します。

プロトコルモデルが勝つ場合

プロトコルは特定の条件でプラットフォームを打ち負かします。

• 所有権がポーランドより重要な場合。 プロトコルは通常、プラットフォームより洗練されていません。ポーランドが与えることができない何か（永続的なアイデンティティ、検閲耐性、オープン相互運用性）を気にかけるとき、彼らは勝ちます。
• ネットワーク効果が機能である場合。 プロトコルの価値は、ユーザーだけでなく、実装者による採用とともに成長します。より多くのクライアントとrelayは、プラットフォームがコピーできない方法でネットワークを強化します。
• 長期的な視点が重要な場合。 プラットフォームは買われたり、売られたり、シャットダウンされたり、ピボットされたりします。プロトコルはあらゆる単一の実装者を上回ります。電子メールはほとんどの企業より古いです。Nostrは同じダイナミクスに賭けています。

ユースケースがこれらのいずれにも一致しない場合、プラットフォームは通常、より高速で簡単です。これは正直です。Nostrは可能なすべてのユースケースについてTwitterより普遍的に優れていません。プロトコルがプラットフォームを打ち負かす特定の方法でそれは優れています。

実際のスペックを読む

このガイドがあなたにプロトコルを直接読みたいと思わせた場合は、NIPs リポジトリに完全なリストがあります。NIP-01はコアです。その後の番号付きNIPは拡張です。Nostrを使用するために何かを理解する必要はありませんが、NIP-01を読むには約10分かかり、多くを明確にします。