162 / 736NOSTR

Nostr

一つのアプリに縛られない投稿と本人の識別

一般的なSNSでは、運営者がアカウントを管理します。Nostrは、利用者を識別する仕組み、アプリ、投稿を運ぶサーバーを分けています。そのため、同じ鍵を使ったままアプリを変更できます。ただし、すべての投稿が届くことや、すべてのメッセージが非公開であることまで保証するわけではありません。

Nostrは、アプリとrelay(リレー)と呼ばれるサーバーが署名付きメッセージをやり取りするための、共通ルールを定めたオープンなプロトコルです。公開鍵はプロフィールを識別する長い数値です。対応する秘密鍵は、そのプロフィールの利用者としてデジタル署名を作るための秘密の値です。独自のブロックチェーンも、全投稿を確実に収録した共通アーカイブもありません。

アンナはNostrで読みたい著者を見つけます。その後、使っているアプリが合わなくなりました。別のアプリで同じ秘密鍵、または接続した署名用デバイスを安全に使えば、同じ利用者として活動を続けられます。公開鍵は他の人がアンナを識別し、署名を確かめるためのものです。秘密鍵があれば、アンナとして署名できます。だからこそ、npubとnsecの違いが重要です。NIP-19では、これらはそれぞれ公開鍵と秘密鍵をBech32で符号化した表記です。NIPとは、Nostrのルールや拡張を説明する、番号の付いた文書です。符号化は暗号化ではありません。nsecは誰にでも渡せる単なるプロフィールのリンクではないのです。また、同じ鍵を使えても、新しいアプリが過去の全投稿を見つけたり、すべての設定を引き継いだりできるとは限りません。 [2] [7]

クライアントと呼ばれるアプリが投稿に署名し、選んだリレーに送ります。リレーはメッセージを受け取り、自分のルールに従って保存や転送を行うサーバーです。ペトルのアプリはリレーに接続し、読みたい投稿を要求します。唯一の中央サーバーはなく、各サーバーがすべてを複製する義務もありません。技術的には、接続を開いたまま通信するWebSocketを使います。EVENTはメッセージを運び、REQは購読を開始し、OKは受理または拒否を伝えます。肯定的なOKでさえ、ペトルへの配信や永久保存の確認ではありません。EOSEは、その問い合わせに対する保存済みの結果を送り終えたという印です。その後も購読を通じて新しいメッセージを受け取れます。 [1] [7]

ペトルがメッセージを受け取ると、アプリは署名が記載された公開鍵と一致し、署名対象のデータが変更されていないかを調べます。これで内容が真実だと証明されたり、著者の実社会での身元が分かったりするわけではありません。作成時刻も著者が設定するので、独立した時刻証明ではありません。技術的に知りたい人向けに説明すると、eventという記録にはpubkey、created_at、kind、tags、content、つまり鍵、時刻、種類、タグ、本文が入ります。決められた形式でこれらを並べ、SHA-256でidという短い照合用の値を作ります。これにより、署名対象のデータが変わったことを検出できます。sigには、BIP340に従いsecp256k1曲線を使うSchnorr Signature(シュノア署名)が入ります。確認できるのは「対応する鍵の持ち主がこのデータに署名した」ことであり、「この主張は信用できる」ことではありません。 [1]

長い公開鍵は覚えにくいため、NIP-05ではメールアドレスに似た識別子と結び付けられます。アプリは対象ドメインに名前と対応する鍵を問い合わせ、プロフィールの鍵と比較します。確認するのはそのドメインとの対応関係であり、本名、評判、信頼性まで自動的に確かめるものではありません。ドメイン運営者は後で対応を変更できます。アンナがすでに誰かをフォローしているなら、識別の基準は元の公開鍵のままであるべきです。同じ名前が別の鍵に割り当てられても、フォロー相手が知らないうちに変わってはいけません。仮名性とは本名の代わりに継続的な識別子を使うことで、匿名性の保証ではありません。 [3]

ペトルは全メッセージをダウンロードする必要はありません。特定の著者による特定の種類の投稿、といったフィルターを送れます。一つのフィルターに含まれる異なる条件はANDで結ばれ、すべて満たす必要があります。同じ条件で許される複数の値はOR、つまりいずれかでよく、一つのREQ内の複数フィルターもORで結ばれます。どれかのフィルターを満たせば十分です。limitは最初に返す保存済み結果を制限し、その後の購読メッセージを自動的に制限するものではありません。NIP-01のイベントやフィルターでは、利用者向けのnpubではなく、鍵を十六進数で表します。検索結果が空でも、フィルター、選択したサーバー、その保存履歴が原因かもしれません。投稿がどこにも存在しない証拠にはならないのです。 [1]

アンナがプロフィールの説明を変えたら、他の人には新しい説明を見てもらいたいはずです。そこでNostrは、リレーが何を保存するべきかを区別します。置換可能なイベントでは、同じpubkeyとkindの組について最新の記録を選びます。アドレス指定可能なイベントではdタグの値も使い、同じ著者の別々の文書などを区別します。置換可能な記録の時刻が同じなら、辞書順で小さいid、つまり文字として並べたときに先に来るものを残すことが推奨されます。一時的なephemeralイベントは、そもそも保存を前提としていません。これらは取り決めであり、リレーの動作は異なる場合があります。Nostrは、ネットワーク全体が唯一の変更不能な履歴に合意する台帳ではありません。 [1]

アンナが、非公開にするつもりの内容を投稿してしまったと気付きました。NIP-09を使えば、署名付きの削除要求を送れます。クライアントは適用前に、要求と元の投稿が同じ公開鍵に属するかを確認しなければなりません。他人がアンナの投稿を指定するだけで削除できてはいけないからです。協力するサーバーやアプリは内容を取り除いたり、表示をやめたりできます。しかし要求によって、すべてのコピー、スクリーンショット、独立したアーカイブが消えるわけではありません。一つのアプリで隠れても、別のサーバーが提供を続けている可能性があります。削除ボタンの有無より、何を公開するかが重要です。 [4]

公開投稿は、手に入れた人なら誰でも読めます。署名だけで本文は隠れません。私信には追加のルールがあります。NIP-44は本文の暗号化を、NIP-17は保護の層を加えながらメッセージを包んで届ける方法を定めます。ただし、自動的に匿名になるわけではありません。ネットワーク上のアドレス、時刻、アプリの動作から情報が漏れることはあります。また、この暗号化にはforward secrecy、つまり長期利用する鍵が後で漏れても過去の会話を守る性質がありません。必要な秘密鍵と以前記録した暗号文を得た人は、過去の通信も読めます。そのアプリが実際にどの拡張に対応しているかを確認してください。「Nostr」という名前だけでは、私信の保護水準は分かりません。 [5] [6]

理解を深めるには、この項目とあわせて次もお読みください Nostr Wallet Connect, Schnorr Signature, Private Key, Bitcoin のプライバシー, 仮名性, SHA-256. 次の項目からも参照されています Nostr Wallet Connect, Network Effect.

DOC · 001Nostr — NIP-01: Basic protocol仕様 DOC · 002Nostr — NIP-19: Encoded entities仕様 DOC · 003Nostr — NIP-05: Internet identifiers仕様 DOC · 004Nostr — NIP-09: Deletion requests仕様 DOC · 005Nostr — NIP-44: Encrypted payloads仕様 DOC · 006Nostr — NIP-17: Private messages仕様 DOC · 007fiatjaf — Original Nostr description一次資料
改訂日: 一次資料を優先 · 投資助言ではありません