Nostr：鍵ペアだけで成り立つ分散型ソーシャルプロトコル

「アカウント」も「サーバー」もない。Nostr（Notes and Other Stuff Transmitted by Relays）は、匿名開発者fiatjafが2020年頃に提案した、驚くほどシンプルな分散型ソーシャルネットワークプロトコルです。すべてのアイデンティティは鍵ペアそのもの、すべてのデータは署名付きのただ1つのJSON構造です。この極端な単純さが、検閲耐性と実装容易性をどのように両立させているのかを解説します。

Nostrとは: アイデンティティは鍵ペアそのもの

Nostrには、ユーザー登録を受け付け、パスワードやメールアドレスを管理する中央サーバーが存在しません。ユーザーを識別するのは、Bitcoinと同じsecp256k1の鍵ペアそのものです。公開鍵がそのままそのユーザーの一意なIDとなり、秘密鍵で署名を行うことで「これは確かに自分が発信した」ことを証明します。楕円曲線暗号は通貨の所有権ではなく、発言の真正性を担保するために使われているわけです。

生の鍵バイト列は人間にとって扱いにくいため、NIP-19では公開鍵をbech32エンコーディング（誤り検出機能を持つ文字列符号化方式）したnpub、秘密鍵を同様にエンコードしたnsecという表記が定義されています。アカウント登録もログイン画面も存在せず、鍵ペアを1つ生成した瞬間に、誰でも新しいNostrの「アカウント」を持てます。

• サーバーにパスワードやメールアドレスを預けないため、特定の運営者がアカウントを凍結・削除することは原理的に不可能。
• 同じ鍵ペアを複数のクライアント・複数のリレーで使い回せるため、特定のアプリやサービスにロックインされない。
• その裏返しとして、鍵の管理責任は完全に利用者側にある。マルチシグのように鍵の共同管理や回復を仕組み化できる暗号システムと異なり、Nostr自体には鍵の回復やローテーションのための標準機構が存在しない。

イベント: Nostrにおけるただ1つのデータ構造

Nostr上でやり取りされるデータは、種類を問わずすべてイベント（event）と呼ばれる署名付きのJSONオブジェクトです。プロフィールの更新も、投稿も、いいねも、フォローリストも、すべて同じ1つの構造で表現されます。

このid・sigの組みによって、リレーやクライアントを信頼しなくても「このイベントは確かにこの公開鍵の持ち主が作成し、以後改ざんされていない」ことを誰でも検証できます。kindというただ1つの整数でアプリケーション上の意味を切り替えられるため、テキスト投稿からLightning送金の通知、長文記事まで、新しい用途はNIPとしてkind番号を1つ追加するだけで拡張できます。

リレーとNIPs: 「ダム」な配送層の上に積み重なる拡張

Nostrのもう一つの核心がリレー（relay）です。リレーはWebSocket接続を受け付け、送られてきたイベントを保存し、条件に合う購読者へ転送するだけの、意図的に単純な、いわば「ダム」なサーバーです。イベントの真正性はすでに署名によって保証されているため、リレー自身がそれ以上の検証を担う必要はなく、実装は非常に軽量になります。

重要なのは、リレー同士が互いに通信・同期する仕組みを持たない、つまり連合（federation）しないという設計判断です。連合型アーキテクチャや、その代表例であるActivityPubではサーバー同士がプロトコルレベルで相互に情報を配送し合いますが、Nostrでは冗長性と可用性の責任がすべてクライアント側に置かれます。クライアントは同じイベントを複数のリレーへ同時に書き込み、フォローしている相手の投稿を複数のリレーから並行して購読します。あるリレーが停止しても、あるいは検閲しても、他のリレーへ切り替えるだけでネットワークから排除されずに済みます。

• リレー運営者はイベントの保存・転送を拒否する自由を持つ（自分のリレー上でのモデレーション）が、それが利用者のアイデンティティやフォロワー関係を奪うことには繋がらない。鍵と社会的グラフ（誰をフォローしているか）はクライアント側の状態であり、特定のリレーに縛られない。
• リレーは無料でも有料でも構わず、誰でも自分のリレーを立てられる。プロトコル上、リレー間に権威やヒエラルキーは存在しない。

コア仕様は意図的に最小限に留められており、拡張はNIPs（Nostr Implementation Possibilities）と呼ばれる番号付きの提案としてGitHub上で公開・議論されます。kindやタグの意味を増やすだけでプロトコル全体を変更せずに機能を追加できる点が、Nostrのエコシステムの成長を支えています。

このシンプルな土台の上に、iOS向けのDamusやAndroid向けのAmethystをはじめとする多数のクライアントが独立に実装されており、同じイベント形式とリレープロトコルさえ話せればクライアント同士は自然に相互運用できます。

利点と課題

• プロトコルの単純さ: イベント1種類・リレーの薄い役割という設計のおかげで、クライアントもリレーも比較的少ないコードで実装でき、学習コストも低い。
• アカウント凍結が原理的に不可能: アイデンティティが鍵ペアである以上、特定の運営者がアカウントを「削除」する権限を持たない。あるリレーから締め出されても鍵と社会的グラフは失われない。
• リレー移動の自由: 気に入らないリレーから別のリレーへ、ノーコストで乗り換えられる。ActivityPubではサーバー移行がアカウントの断絶を伴いがちなのと対照的である。

• 鍵の喪失・漏洩に対する回復手段がない: 秘密鍵を失えばアイデンティティ・フォロワー・投稿履歴のすべてに二度とアクセスできず、漏洩すれば別人によるなりすましを止める術がない。鍵をローテーションする標準的な仕組みも用意されていない。
• スパム対策はリレー任せ: プロトコル自体には投稿コストがないため、NIP-13のProof of Workや、書き込みを有料化するリレーなど、対策は個々のリレー運営者の裁量に委ねられている。
• 人気リレーへの事実上の集中: 理論上は誰でもリレーを立てられるが、実際には少数の大規模リレーに接続とデータが集中しやすく、可用性の高い代替リレー群を維持する経済的インセンティブは弱い。
• グローバルな検索・発見の難しさ: リレーが連合しないため「Nostr全体」を横断検索する単一の窓口が存在せず、特定の投稿やユーザーを見つけるには複数のリレーを渡り歩く必要がある。

Nostr・ActivityPub・AT Protocolの比較

3つのプロトコルはいずれも中央集権的なSNSへの対抗として生まれましたが、「何を信頼の起点に置くか」という設計判断が異なります。ActivityPubはサーバー（インスタンス）を単位とした連合、AT ProtocolはDIDという回復可能な識別子とPDSの分離、Nostrは鍵ペアそのものへの絶対的な信頼を選んでいます。検閲耐性・回復性・実装の単純さのどれを優先するかによって、選ぶべき設計は変わってきます。

関連ページ

Nostrの設計思想は、このサイトで扱う他の分散化アプローチとの対比によって際立ちます。サーバー同士が相互に情報を配送し合う連合型アーキテクチャや、その代表例であるActivityPubは、Nostrの「リレーは連合しない」という設計と好対照をなします。同じく分散型SNSであるAT Protocolは、公開鍵そのものではなく回復可能な分散識別子（DID）をアイデンティティの基盤に据えており、Nostrが抱える鍵紛失時の回復不能性という課題への1つの解答になっています。秘密鍵の保管・共同管理という論点はマルチシグにも通じ、リレー間でイベントを効率よく伝播させる発想はゴシッププロトコルによるanti-entropyの考え方とも重なります。