Nostrの実際の仕組み：プロトコル、難しい用語なし

Nostrの説明のほとんどは「分散型ソーシャルプロトコルである」で終わり、興味深い部分は言わずじまいです。興味深い部分は、プロトコル全体が短いドキュメントに収まることです。賢い仕掛けはありません。隠れた複雑さもありません。ただいくつかのプリミティブが一緒に動作しているだけです。

このガイドは、実際にNostrを使うときに現れる順序でこれらのプリミティブをウォークスルーします。イベントがどのように構築されるか、どのように署名されるか、どのようにリレーに到達するか、クライアントがどのようにサブスクライブするか、投稿に「いいね」をする、返信を得る、またはzapを受け取るときのフローがどのようなものかです。ブロックチェーン比較はありません。大きな物語もありません。ただのメカニクスです。

TL;DR。 Nostrは、暗号化署名を備えたWebSocket上のパブサブです。クライアントは署名されたJSONオブジェクト（イベント）をリレー（小規模なサーバー）に発行し、他のクライアントは望むイベントに一致するフィルタを使用してリレーにサブスクリプションします。署名は偽造を防ぎます。複数のリレーは単一障害点を防ぎます。これがプロトコル全体です。それ以外はすべて、異なる種類のコンテンツ用のフォーマット規約です。

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

基本ブロック：イベント

Nostr上のすべてはイベントです。投稿はイベントです。反応はイベントです。プロフィール更新はイベントです。ダイレクトメッセージはイベントです。zapレシートはイベントです。

イベントは、正確にこの形のJSONオブジェクトです：

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

6つのフィールドが意味のある働きをします。idはイベント自身のコンテンツのハッシュです。イベントを一意に識別します。pubkeyは著者です（64文字の16進数公開鍵）。created_atはUnixタイムスタンプです。kindは、そのイベントが何を表しているかを説明する整数です（詳細は以下）。tagsはハッシュタグ（t）、メンション（pは公開鍵、eはイベント）、その他数十個など、構造化された注釈のリストです。contentは通常テキストである自由形式のペイロードです。

sigは、著者の秘密鍵でidのハッシュ上で作られたSchnorr署名です。これは偽造を防ぐフィールドです。誰でもハッシュを計算できますが、秘密鍵の所有者だけがそれ上の有効な署名を生成できます。

「kind」とは何か

kindフィールドは、イベントの解釈方法をクライアントに伝えます。数値は意味的な型全体です。

活発に使用されている数個のkind：

新しいkindはNIP（Nostr Implementation Possibilities）を通じて提案され、標準化されます。誰でも提案できます。広く採用されるものはプロトコルの事実上の一部になります。採用されないものは単に何も壊すことなくニッチなままです。

イベントがどのように発行されるか

Nostrクライアントで「投稿」をタップすると、次のシーケンスが実行されます：

1. クライアントはJSONを組み立てます。 pubkey、created_at、kind、tags、contentを入力します。
2. クライアントはidを計算します。 これらのフィールドの正規シリアライゼーション上でSHA-256を実行します。これが署名がカバーするハッシュです。
3. クライアントは秘密鍵でidに署名します。 secp256k1上のSchnorr署名。Bitcoinが使用する同じ曲線です。64バイトの署名はsigフィールドになります。
4. クライアントは各設定リレーへのWebSocket接続を開きます。 またはそれらがライブの場合は既存の開いているものを再利用します。
5. クライアントイベントをメッセージとして送信します。 配信形式はJSONの配列です：["EVENT", {...event...}]。
6. 各リレーは署名を検証します。 署名が要求された公開鍵に対して検証されない場合、イベントを拒否します。そうでない場合は受け入れて保存します。
7. 各リレーはサブスクライバーにイベントをプッシュします。 フィルタがこのイベントに一致する開いたサブスクリプションを持つクライアントは、リアルタイムで配信されたイベントを取得します。

往復全体には、リレーの位置によって50〜300ミリ秒かかります。任意のリレーが遅い、またはオフラインの場合、他のリレーは引き続きイベントを発行します。イベントがネットワークに存在するために、1つのリレーが受け入れるだけで十分です。

クライアントが投稿をフェッチする方法

読むことは発行の鏡です。

あなたのクライアントはリレーのリストへのWebSocket接続を開きます。各リレーについて、サブスクリプションメッセージを送信します：

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

これは、リストの著者から、kind 1（短いノート）またはkind 6（再投稿）の最大50イベントをリレーに要求します。リレーは：

1. ローカルデータベースで一致するイベントをクエリし、デフォルトでは古い順から新しい順へ、制限までクライアントにEVENTメッセージとして送り返します。
2. EOSE（保存されたイベントの終了）メッセージを送信し、クライアントが履歴ダンプが完了したことを知ります。
3. サブスクリプションを開いたままにします。 フィルタに一致する新しいイベント（後で他の誰かによって発行された）がリアルタイムでクライアントにプッシュされます。

これがあなたのフィードがライブになる方法です。ポーリングしていません。リレーがストリーミングしています。

クライアントは設定済みのすべてのリレーで並列に実行します。応答の和集合があなたのタイムラインです。idで重複するイベントは重複排除されます。

署名が実際に偽造をどのように防ぐか

これはほとんどの説明がざっくり説明する部分です。

クライアントがイベントを受け取ると、正規シリアライゼーション上のハッシュを再計算し（発行者が行ったのと同じ方法で）、Schnorr検証を実行します。pubkey、id、sigが与えられたとき、署名は暗号化的にチェックアウトしますか？

はいの場合、イベントは認証です。このイベントの著者は、署名の時点でその公開鍵の所有者でした。すべてのクライアントはすべてのイベントでこのチェックを実行します。不正な署名を持つ偽造イベントを送付するリレーは、それを見るすべてのクライアントによってサイレントに削除されるだけです。

これは重要です。リレーが信頼されていないことを意味するからです。悪意のあるリレーはあなたの言葉を言わせることができません。あなたの投稿の配信を拒否することはできます。他の人の（合法的な）投稿をあなたのフィードに注入することはできます。しかし秘密鍵がなくてあなたによって署名された有効な投稿を生成することはできず、署名を破壊することなく既存の投稿を変更することもできません。

このプロパティのコストはちょうど1つのSchnorr検証です。これは非常に高速で、モバイルクライアントでも毎秒数万個のイベントを処理するのに十分な速さです。

リレーが実際に行うこと

リレーは、3つのジョブを持つダムで高速なパイプです：

1. イベントを受け入れて署名を検証します。 検証されないか、ポリシーチェック（スパムフィルタ、サイズ制限、ブロック済み公開鍵）に失敗したものを拒否します。
2. イベントを保存します。 通常、id、pubkey、kind、タグ値によってインデックスされたSQLiteまたはPostgreSQLデータベース。
3. サブスクリプションを提供します。 着信REQフィルタをデータベース（履歴用）およびライブイベント（リアルタイム用）に対してマッチします。

それだけです。リレーはランク付け、推奨、キュレーション、マネタイズ、広告の表示、アルゴリズムの適用、またはプラットフォームが行うことはしません。署名されたバイトを転送するだけです。

これらの他のジョブの欠如により、リレーは非常に小さいことができます。月額$5のVPSで単一のリレーを実行でき、数百人のアクティブユーザーをサービスすることができます。Twitterのスケールで同じ機能は数十億ドルがかかります。なぜなら、Twitterはこれらのすべての他のことをするからです。

リレーポリシーは異なります。許可なしで署名されたイベントを提供するものもあります。支払いが必要なもの（「有料リレー」モデル）、特定のコミュニティ（企業の従業員、Discordサーバーのメンバー）に制限するもの、スパムフィルタリングに積極的なものがあります。使用するリレーを選択します。選択は、どの投稿が見えるか、どの投稿があなたのフォロワーに到達するかに影響を与えます。

完全な例：誰かがあなたの投稿に「いいね」する

すべてを一緒にまとめると、AliceがBobが書いた投稿に「いいね」するときに何が起こるかのエンドツーエンドです。

1. Bobが発行します。 Bobのクライアントはコンテンツ「hello world」を持つkind:1イベントを構築し、署名して、Bobの5つの設定リレーに送信します。各リレーは受け入れて保存します。
2. Aliceがサブスクリプションします。 Aliceのクライアントは、Bobの公開鍵をauthorsに含むフィルタを持つ2つのリレーの開いたサブスクリプションを持っています。リレーはBobのイベントをサブスクリプションの下に押します。Aliceのクライアントはタイムラインで投稿を表示します。
3. Aliceが「いいね」をタップします。 Aliceのクライアントはコンテンツ「+」（Nostr「いいね」慣例）を持つkind:7イベントを構築し、それが反応する投稿（["e", "bob_post_id"]）と著者（["p", "bob_pubkey"]）にタグを付けます。署名してAliceの5つの設定リレーに発行します。
4. 反応が伝播します。 フィルタ{ "#e": ["bob_post_id"], "kinds": [7] }に一致するアクティブなサブスクリプション（Bobのクライアントが自分の投稿への反応を監視するために使用するもの）を持つリレーは、反応をBobにプッシュします。Bobのクライアントは「いいね」を集約し、投稿の下にカウントを表示します。

何が起こらなかったかに注意してください。集中型の「いいねボタン」サービスはピングされませんでした。バックエンドは「いいね」がカウントされるかどうかを決定しませんでした。「いいね」は単なる署名されたイベントで、投稿自体と同じチャネルで発表されます。

Nostrが明示的に行わないこと

プロトコルの共有ワイヤ形式ではなく、クライアントまたはリレーに属するため、コアプロトコルから意図的に除外された5つのこと。

• 識別検証。 Nostrは「この公開鍵はこの投稿に署名した」ことだけを証明します。その公開鍵が特定の人間に属しているかどうかは、NIP-05とオフチェーンコンテキストで回答される別の質問です。
• コンテンツモデレーション。 プロトコルは何が見えるかを決定しません。クライアント、リレー、ユーザーがフィルタリングします。各層は独立して。
• 検索。 グローバル検索エンドポイントはありません。一部のリレーは、ローカルイベントプール上のテキスト検索をサポートしています。任意のリレーが任意の投稿を見つけることができるというプロトコル保証はありません。
• アルゴリズムランキング。 プロトコル内に「あなた用」フィードはありません。ランキングはクライアント（あれば）で発生します。
• アカウント復旧。 メールリセット、電話リセット、中央紛争システムはありません。秘密鍵を失い、識別情報を失います。これは欠陥ではなく、トレードオフです。

これらの欠在はプロトコルを小さくするものです。また、集中型プラットフォーム上で1つを構築するよりも、上に洗練されたユーザー体験を構築するのを難しくするものです。これは誠実なコストです。

デザインがすべて機能する理由

デザインは1つの単純なプロパティに依存しています：署名は検証が安い、秘密鍵なしの偽造は不可能、リレーは自由に交換できます。

これら3つの事実は複合しています。安い検証はすべてのクライアントがすべてのイベントをチェックできることを意味します。不可能な偽造はリレーを信頼する必要がないことを意味します。無料交換は単一のリレーが誰にも権力を持たないことを意味します。

一緒に置くと、プラットフォーム層が交換可能で識別層がユーザーによって所有されるソーシャルネットワークが得られます。これが「分散型」が実践で実際に意味することです。マーケティングは通常その言葉をどのように使用するのかではなく。

ユーザー側からのフロー全体を見たい場合（キーペア、NIP-05識別、リレーリスト、ウォレット、投稿の準備完了）、nostr.blogのサインアップはこれらのステップを1ページに折りたたみます。ここで説明されているメカニクスは、実際にそのフロー下で実行されています。