Nostr

イベントには pubkey、created_at、kind、tags、content、id、sig が含まれます。NIP-01 は厳密な直列化結果から SHA-256 で id を作り、secp256k1 上の BIP340 署名を使います。クライアントは完全性と鍵による承認を確認します。created_at は作者の申告であり、独立した時刻証明でも内容の真実の証拠でもありません。 [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

クライアントは WebSocket で EVENT を公開し、REQ で購読します。OK はそのリレーによる受理や拒否を示します。EOSE は保存済みイベントの一覧終了を表し、新規イベントの購読終了とは限りません。いずれも宛先への到着、全ネットワークへの複製、永久保存を確認するものではありません。 [Nostr — NIP-01: Basic protocol]

一つのフィルター内では全条件を満たす必要があり、作者と種類は AND です。一つの REQ 内の複数フィルターは OR で、どれか一つで十分です。limit は初期一覧を制限し、将来のイベント数は制限しません。検索結果がない理由はリレーの履歴不足かもしれず、イベントが存在しないとは限りません。 [Nostr — NIP-01: Basic protocol]

置換可能イベントは pubkey と kind、アドレス指定可能イベントはさらに d タグで比較されます。新しい版が古い版を置き換え、同時刻なら辞書順で小さい id が優先されます。一時的イベントは保存を想定しません。これはリレーの規則であり、不変の世界的アーカイブではなく、実装に差もあります。 [Nostr — NIP-01: Basic protocol]

NIP-19 は表示用に Bech32 を使い、npub は公開鍵、nsec は秘密鍵を表します。符号化は暗号化ではありません。nsec の共有は単なるプロフィールリンクではなく秘密鍵の引き渡しです。NIP-01 のイベントとフィルターは公開鍵の十六進表現を使い、npub 表示は使いません。 [Nostr — NIP-19: Encoded entities]

NIP-05 はドメインの応答に基づき、メール風の名前と公開鍵を関連付けます。示すのは関連であり、本当の身元や誠実さではありません。クライアントは元の鍵を追跡すべきです。ドメインが名前を別の鍵に付け替えても、フォロー済みプロフィールを自動的に新しい鍵へ置換してはいけません。 [Nostr — NIP-05: Internet identifiers]

NIP-09 は作者が自分のイベントの削除を求める方法を定義します。非表示にする前に、クライアントは元イベントと要求の公開鍵が同じか確認すべきです。リレーとクライアントは処理できますが、ダウンロード済みなどの全コピーをプロトコルが消すことはできません。一画面での削除は世界全体からの消去の証明ではありません。 [Nostr — NIP-09: Deletion requests]

NIP-44 は暗号化 payload の仕様で、私信システム全体ではありません。NIP-17 が包みと配達規則を加えます。NIP-44 単独では後の鍵漏えいに対する forward secrecy を提供しません。暗号化してもネットワークアドレス、時刻、クライアントの挙動は重要です。各 NIP の対応はアプリ別に確認する必要があります。 [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]