Nostr Compassへようこそ。Nostrの週刊ガイドです。

今週: Shopstrがリモートsignerとwalletの秘密情報をブラウザストレージの外に保ち、Routstr SDKがrelay由来のプロバイダディスカバリを検証、Postrが小さなAndroid投稿アプリとして登場、Infansが育児記録と共同養育者間の同期を暗号化、walls.ripがPGP暗号化チャットを公開Nostr relay経由で運び、pakstrがZapstore公開を明示化します。nostr-toolsはgift wrapのrumorをそのsealに結び付けます。リリースはsubscriptionの分離、プロフィールステータス、relay単位の退出マーカーを扱います。protocol関連の動きはコメントスレッドの実装展開、wallet connectの手数料上限と支払い照会のドラフト、napplet向けディスプレイ要求、同一アカウントからの実験的な参加登録に及びます。今号はNostr の 6 年間の 8 月で締めくくります。

トップストーリー

Postrが小さなAndroid投稿アプリとして登場

Postrは、kind 1ノート向けに意図的に小さく作られたAndroid投稿アプリです。秘密鍵の保管はAmber、すなわちAndroidのNIP-55（ローカルsigner）およびNIP-46 signerに残ります。バージョン1.0.0は、接続断やプロセス終了に耐える永続的なoutbox、アカウントごとの非公開下書き、検証済みハッシュとスコープ付きアップロード認可を備えたBlossom添付を搭載します。

投稿が成功と見なされるのは、Postrが同一の署名済みイベントを読み戻し、その署名を確認した後です。再試行は同じevent idを保ちます。公開には著者のNIP-65（relayリスト）書き込みrelayと暗号化されたブートストラップrelay、またはアカウントごとの独自リストを使います。署名済みのNIP-34（git over Nostr）リポジトリ告知と対応するkind 0プロジェクトプロフィールはrelay.ngit.devで公開されます。フィード、アナリティクス、広告、鍵の保管はアプリの外に置かれます。

InfansがNostr上で育児記録と共同養育者間の同期を暗号化

共同養育者は授乳、睡眠、成長の記録を自分の端末に保ちながら、育児データ事業者を介さずに共有できます。InfansはAndroidの育児記録アプリで、ローカルのRoomデータベースを唯一の正とみなし、バックアップとパートナー同期のために暗号化されたkind 30078のNIP-78（アプリケーション固有データ）イベントを公開します。リポジトリはローカルの暗号方式をNIP-44（ペイロード暗号化）と表記していますが、実装はAES-256-GCMを使っており、NIP-44 v2はChaCha20とHMAC-SHA256を要求します。したがってローカルモードのペイロードをNIP-44互換として示すべきではありません。

パートナー同期はd-tag baby-tracker-syncを使い、自己バックアップはbaby-tracker-backupを使います。非同期のメモはパートナー向けペイロードの内側を通ります。文書化されたAmber NIP-55（ローカルsigner）経路は署名と暗号化をsignerに委譲しますが、リポジトリはすべてのバックアップおよびパートナー同期経路がNIP-44 v2の暗号文を生成することを示す相互運用テストを提供していません。リポジトリは医療機器としての主張も第三者によるセキュリティレビューも提示していません。

walls.ripのGhost Chatが公開Nostr relayにPGP暗号化チャットを持ち込む

walls.ripは匿名コミュニケーションのツール群で、そのGhost Chatモードはブラウザ内でOpenPGP identityを作成または取り込みます。オープンソースのクライアントは各メッセージを受信者のPGP公開鍵で暗号化します。読める会話は端末上のローカルセッションストレージに留まり、アプリにはチャットアカウントも中央のメッセージデータベースもありません。

トランスポートは本物のNostrですが、意図的にアプリ固有です。Ghost Chatはarmored暗号文をkind 1イベントとして公開し、5つの既定relayへ送り、各イベントに受信者のPGPフィンガープリントから導かれた安定したルームtagを付けます。これは開発者にとって、relayを検閲耐性のあるメッセージトランスポートとして使う具体例になると同時に、分散配信だけではメタデータが守られず、NIP-17ダイレクトメッセージとの相互運用性も得られない理由を示しています。

pakstr 0.13.0から0.15.0がZapstore公開を明示化

7月の0.3.1におけるパッケージングとAmber対応を経て、pakstrはwebアセットのフォルダを署名済みAndroid APKに変換し、Nostr鍵でZapstoreへ公開するCLIです。0.13.0はリリースの自動バージョニングを追加します。0.13.1から0.13.3の後続版はBlossom公開を修復します。認可がbase64urlを使うようになり、アップロードがContent-Digestを持ち、Zapstoreのapplicationイベントがアップロードより前に公開されます。

0.14.0は公開処理を進める前にZapstoreの発行者を検証します。0.15.0は掲載メタデータをkind 32267のapplicationイベントに書き込み、リリースノートをkind 30063のreleaseイベントのcontentに入れます。これによりパッケージ化したアプリのZapstore掲載は、別途の手作業なしに名称、概要、ノートを持てます。

Heterodyneが可搬なpersonaと暗号化されたソーシャル通信を仕様化

Heterodyneは、可搬なpersona、認証付き通信、自己端末の制御、ソーシャル交流のための仕様先行のprotocolファミリーです。現在のREADMEは既存の4層を組み合わせます。署名済みNostrイベント、永続保存としてのRadicle（ピアツーピアgit）、暗号化された個別・グループ会話のためのMarmot（Nostr上のMLSグループメッセージング）、そしてidentityのローテーションのためのKERI（Key Event Receipt Infrastructure）key-event logです。personaはコールドルートのNostr npubと承認済みKERI logの組み合わせとして記述され、日常の署名はローテーションするエポック鍵を使い、Radicleノードのidentityは二重証明で委任されます。

ファミリーはこの作業を独立にバージョン管理される4つの0.xドラフトに分けています。Coreはidentity、key-event logの検証、正規化されたNostrバイト列、Radicleリポジトリ基盤を担い、CommsはNostrネイティブなエンベロープ、プライバシー階層、公開、Marmot会話を担い、Socialは公開フォロー、インタラクション、リストを担います。自己端末の登録と権限付与を担うControlは未完成で、実現済みとは主張できません。これらの文書は1.0前に壊れる可能性のあるドラフトであり、今号はHeterodyneクライアントのリリースが出る前の段階でこのファミリーを紹介しています。

リリース

Nostr Java v2.0.8: subscriptionの分離と可搬なNIP-44

5件のイベントを持つrelayに対するgift wrapのクエリが0件、2件、6件をばらばらに返していました。原因はNostr Java、relayとの通信とNostrペイロードの暗号化を行うJavaライブラリが、受信したすべてのフレームを接続上のすべてのlistenerに配っていたことです。バージョン2.0.8はEVENT、EOSE、CLOSEDをそれらのフレームが指すsubscriptionへルーティングするので、あるクエリの保存済みイベント終了シグナルが別のクエリを閉じることはなくなりました。NOTICE、OK、AUTHのような接続スコープのフレームは引き続きすべてのlistenerに届きます。

同じリリースのNIP-44（ペイロード暗号化）は、プロセスに登録されたJCE providerを必要としなくなりました。以前は当該JVMで鍵を生成した後でしか暗号化が動かず、その副作用としてBouncyCastleが登録されていました。また"BC"という名前のproviderを追加しても無効なAndroidでは失敗していました。両方のcipher経路はBouncyCastleの軽量ChaCha20エンジンを使うようになり、鍵生成がプロセス全体のJCE状態を変えることもなくなりました。providerの登録をライブラリに任せていた呼び出し側は自分で登録する必要があります。これが閉じるissueはNIP-44のJCE provider依存です。

NoorNote v1.3.6: プロフィールステータスとclassified listing

NoorNoteはデスクトップ、web、Android向けのNostrクライアントです。1.3.4が暗号化されたコミュニティ参加を追加した1週間後、バージョン1.3.6はプロフィールのNIP-05（ドメイン検証済み）名の下にNIP-38（ユーザーステータス）を表示します。これは1行の一般ステータスまたは音楽ステータスを持つ、任意で期限切れになるkind 30315のaddressableイベントです。その行をクリックすると閲覧者自身のステータスが設定されます。

NIP-99（kind 30402のマーケットプレイス出品）のclassified listingがアプリ全体で描画されるようになったため、マーケットプレイスのアドオンは売買のときだけ必要になりました。プロフィール上の非公開のpetnameメモも警告色のオレンジで表示され、塗りつぶしのメモアイコンとオレンジのアバターリングが付きます。

nostrord v2.9.0: relay単位のグループ状態とメディア

あるホストでNIP-29（relay管理グループ）のグループを退出すると、以前は他のすべてのrelayで同じグループidが抑止されていました。nostrord、relayホスト型コミュニティ向けのクロスプラットフォームクライアントが、退出と削除のマーカーを素のidでキー付けしていたためです。relay単位にスコープされた退出・削除マーカーは、その抑止を生成したホストに留めるので、2つのrelayでidを共有するグループが対で退出・破棄されることはなくなりました。すでにメンバーであるためにrelayが拒否する参加は成功として扱われ、ローカルのマーカーを消去します。これは以前は吸収状態でした。自己修復が一方のスロットを消す一方で、コールドスタートがもう一方を復元していたのです。

バージョン2.9.0は、他のクライアントが![alt](url)と書くmarkdownの画像埋め込みも描画するようになり、すでに検出済みのURLの周りにmarkdownの記号を表示しなくなりました。ダイレクトメッセージはNIP-17（gift wrapされた非公開DM）のkind 15ファイルrumorに対応したので、Jumbleから送られた暗号化添付がダウンロード、復号、表示され、送信する添付はアップロード前に暗号化されます。このタグは先週取り上げたNIP-4e暗号鍵の作業を実際に出荷します。提案は未マージのままで、nostrordはドラフトと異なる部分では実運用のJumbleの挙動に従うと述べています。

未リリースの変更

Shopstrがリモートsignerとwalletの秘密情報をブラウザストレージの外に保つ

ShopstrはNIP-99 classified listing向けのwebマーケットプレイスです。先月の支払い整合性の作業に続き、シリアライズしたbunker signerの秘密情報をlocalStorageに書き込むのをやめました。NIP-46（リモート署名）のbunkerペイロードには稼働中のbunker:// URLと生成されたアプリ秘密鍵が含まれていたため、Shopstrのoriginで動く任意のスクリプトがリモート署名セッションを再開できました。bunkerデータは現在のセッションのあいだメモリ上に留まり、残っていたbunkerペイロードは見つかった時点で削除され、bunker以外のsignerタイプは以前の保存挙動を保ちます。

対応するNWCの変更はNIP-47（wallet connect）の資格情報に同じ処理を行います。Shopstrはwallet操作に使う秘密を含むnostr+walletconnect://文字列全体を通常のブラウザデータとして保存し、決済時に再利用していました。接続文字列とwalletメタデータは現在メモリ上に留まり、古い保存済みコピーはローカルデータの読み取り時に削除されます。アクティブなセッション中にすでにShopstrのoriginで動いているスクリプトは、メモリ上のそれらの値を依然として見ることができます。

Routstrがrelay由来のプロバイダディスカバリを検証

以前は単一の悪意あるrelayが、Routstrクライアントが信頼する推論プロバイダを決められました。Routstr SDKは、Nostr上でAIプロバイダを見つけてCashuで支払うマーケットプレイスRoutstrの背後にあるTypeScriptライブラリです。今週のディスカバリ修正は、relayが届けたすべてのプロバイダ告知、モデル一覧、レビュー（kind 38421、38423、38425）を利用側が見る前に検証するので、信頼済みのpubkeyを名乗りながら不正な署名を持つレビューがランキングに入ることはなくなりました。

遠い未来のタイムスタンプは「最新レビュー」の選択前に破棄されます。ローカル時計より15分以上先のイベントはライブ経路と永続ストアの読み取り時に除去されるので、偽造されたcreated_atが再起動をまたいで正しく署名されたレビューを上回ることはできません。信頼できるレビューが得られない場合、レビューのゲートはfail-closedとなり、レビューが届くまで未レビューのプロバイダを支払いランキングから除外します。運用者は手動でプロバイダを有効化することもできます。

nostr-toolsがgift wrapのrumorをそのsealに結び付ける

NIP-59（gift wrap）イベントのunwrapは、以前はwrapを復号し、sealを復号して、sealが誰から来たかを確認せずに内側のrumorを返していました。nostr-toolsはNostr protocolのヘルパーを集めたJavaScriptライブラリです。今週のunwrap修正は、wrapがkind 1059であること、sealが有効な署名を持つkind 13であること、そしてrumorのpubkeyがsealのpubkeyと一致することを要求します。sealの復号自体がseal.pubkeyの管理を証明しています。最後の確認がなければ、誰でも他人を著者と名乗るrumorをsealでき、クライアントにそのメッセージをその被害者に帰属させられてしまいます。

NIP-17（gift wrapされた非公開DM）は同じunwrap経路を使うため、この結び付けは非公開DMにも適用されます。バッチunwrapは、これらの確認に失敗したwrapで例外を投げるのではなくスキップするようになりました。gift wrapは未承諾で届くものであり、1件の敵対的なイベントがrelayクエリの残りを捨ててしまうからです。

Havenが署名付きrelay管理とローカルのノートブラウザを追加

HavenはセルフホストのNostr relayかつBlossomメディアサーバーです。新たにマージされた管理コンソールは各relayエンドポイントでNIP-86の管理呼び出しを公開し、すべてのリクエストは設定されたオーナーのNIP-98イベントで認証されます。運用者はrelayに署名鍵を渡すことなく、BAN、許可リスト、kindのルール、relay名、保存メディアを管理できます。読み取り専用のノートブラウザは暗号化されたkindを不透明なまま保ち、リモートメディアはクリック後にのみ読み込むので、運用者のIPアドレスを外部ホストに漏らす自動リクエストを避けられます。

同じHavenの変更は永続的なトラフィックグラフを追加し、既定のLMDBで保存イベントの数え上げが無限ループしてCPUコアを占有し、その後の統計呼び出しを止めてしまう不具合を修正します。Havenは終了が保証される場合はバックエンドのカウンタを使い、それ以外では上限付きのイベント走査を使います。プロジェクトはイベントのページング、削除、メトリクスの永続化、オーナー確認、URLに束縛されたリクエスト署名について最初の23件のテストを追加しました。

AmethystがBlossom認可を画像読み込みスレッドから外す

Amethyst、AndroidのNostrクライアントは、OkHttpのdispatcherスレッド上でBlossom読み取り認可を待つのをやめました。interceptorはネットワークスレッドから離れて署名を開始し、画像fetcherはホストごとに共有される1つの署名を待って保護されたblobリクエストを再試行します。これにより、signerが応答している間に認可付き画像の集中が各ホストの接続スロットを埋め尽くすことはなくなりました。

同じAmethystのパッチはトークンのエンコードをBUD-11に合わせます。パディングなしのBase64url、serverスコープ、blob固有のx tagなしとし、1つのトークンが同一ホスト上の複数のblobを対象にできます。新しい並行性テストはキャッシュ、期限切れ、署名付き再試行、1つの署名を共有する16の同時呼び出しを検証します。

プロトコルと仕様作業

NIP

SnortとDittoは通常のテキスト返信にNIP-22（コメントスレッド）を使うようになり、互換経路を保ちながらkind 1111に収束しています。これはprotocol全体で単一の返信kindを定めるものではありません。6月の修正がkind 1ノートに対してNIP-22を使う禁止を取り除いた後、NIP-30（カスタム絵文字）へのマージ済みの追記がkind 1111をemoji tagを持てるイベントの一覧に加え、content内のショートコードがそのtagで解決されるようになりました。Snort、webのNostrクライアントは、すべての返信をkind 1111として書き、大文字のE/A root scope tagを通じてそのコメントを読み込み、古いノートに対しては任意でNIP-10（kind 1返信tag）経路も受け入れます。Ditto、MastodonサーバーとNostr relayを兼ねる実装は、すべての返信をNIP-22コメントとして公開し、テキストはkind 1111、音声はkind 1244とし、既存のkind 1返信も引き続き描画します。NIP-10しか理解しないクライアントは新しい形式を見られません。トップレベルの投稿はkind 1のままです。

NIP-47（Nostr Wallet Connect）のpay_invoiceリクエストには、クライアントがルーティング手数料の上限を指定する標準的な手段が今のところありません。手数料上限のオープンな提案は、pay_invoiceにミリサトシ単位の任意パラメータmax_feeを追加します。この予算を尊重するwalletは、ルーティング費用がamount + max_feeを超える支払いを送ってはならず（MUST NOT）、引き落としも支払い試行もない状態として定義されるFEE_LIMIT_EXCEEDEDを返さなければなりません（MUST）。対応する実装はクライアントが照合できるよう応答にfees_paidを含めなければなりません（MUST）。手数料上限に未対応の実装は未知のパラメータを無視し、クライアントはfees_paidフィールドの欠落を上限が適用されていない可能性のしるしとして扱うべきです。この変更はイベントkindを追加せず、マージされるまで提案のままです。

NIP-32の言語ラベルに関するオープンな提案は、著者が宣言するテキスト言語のために["l", "<BCP-47>", "lang"]を標準化します。1文字のl tagはすでにrelayでインデックス可能なので、クライアントはrelayの更新やダウンロード後の当てにならない言語判定なしに{"#l":["ja"]}で日本語フィードを要求できます。ドラフトはNIP-66のrelayレポート、NIP-68の画像メタデータ、NIP-71の音声トラックにある言語の例も同じ名前空間へ移します。ラベルは検証されていない著者の主張のままで、この変更はマージされていません。

Nostr Wallet Connect

タイムアウト、再接続、通知の取りこぼしの後、wallet connectクライアントは、どのBitcoin支払いprotocolがそれを作ったか知らないまま1件の支払い記録を問い合わせる手段を必要とします。NWC拡張リポジトリの支払い照会のオープンなドラフトは、NIP-47コアと並ぶ任意のNWC-09 lookup_paymentを定義します。リクエストはちょうど1つのセレクタを使います。walletスコープで安定したtransaction_id、lookup_invoiceがすでに使うBOLT11互換のpayment_hashおよび/またはinvoiceフィールド、あるいはpayment_typeと別の拡張が定義する型付きlookupオブジェクトです。成功した結果は共通のエンベロープ（transaction_id、type、state、payment_type、msat単位のamount、タイムスタンプ、任意のfees_paidとmetadata、および判別付きdetailsオブジェクト）を返し、その接続から見える記録ちょうど1件に解決しなければなりません（MUST）。walletはアクセスできない記録が存在するかどうかを明かしてはならず（MUST NOT）、複数の可視記録に一致するセレクタはMULTIPLE_MATCHESを返します。状態はpending、accepted、settled、failed、expired、canceledです。同じ提案はそのエンベロープを再利用するNWC-12のBOLT12 offerと支払い詳細も追加します。どちらの文書もまだドラフトです。

NAP

オープンなNAP-DISPLAYのドラフトは、nappletがホストに対して使用を許されたピクセルディスプレイを問い合わせられるようにします。これは別途進む未マージのNIP-5D web appletsの提案の上に築かれており、その提案はNewsletter #17で紹介され、マージ済みNIPの集合の外にとどまっています。ドラフトはdisplay.listを定義し、論理的な幅と高さ、実行時に選ばれる種別（lcd、eink、led-matrix、other）を伴う不透明で安定した識別子を返します。またdisplay.pushは、座標指定された3バイトのsRGBピクセルの空でないバッチを送ります。実行時ディスカバリは論理RGBをネイティブの色深度、向き、リフレッシュへ対応付け、更新の回転、並べ替え、量子化、ディザリング、統合を行ってもよい（MAY）とされます。shellのポリシーはnappletが列挙または書き込みできるディスプレイを制御し、バッチを拒否、レート制限、上限設定してもよい（MAY）。ピクセルを適用する前にランタイムはバッチ全体を検証するので、失敗したpushは端末上で何も変えません。成功はバッチが受理されたことを意味し、ハードウェアのリフレッシュが完了したことは意味しません。

Marmot

Marmotのオープンな実験は、同一アカウントからの参加登録について、取り下げられたExternal Commitのドラフトを上限付きのCommit形式に置き換えます。Marmot、Nostr上のMLSグループメッセージングprotocolは、そのドラフトでデータなしコンポーネント0x800d（marmot.same-account-membership.v1）をネゴシエート済みの挙動マーカーとして割り当てます。それが必須である間、現在のleafはインラインの同一アカウントAddをちょうど1つ、またはインラインの兄弟Removeを1つから4つ作成でき、いずれも通常のUpdatePathと通常の収束優先度を持ち、すべてのCommitは1アカウントあたり最大5つの現在leafを残さなければなりません（MUST）。ペアリングはスポンサーが表示する短命のQR（marmot-pairing-v1:）を使い、その秘密がキャリア非依存のチャネル上でHKDF-SHA256とChaCha20-Poly1305に供給されます。ローカル限定のkind 453証明はセッションを共有アカウント鍵に束縛し、relayへ送られることはありません。一致するWelcomeの後、参加者の最初のアプリケーションペイロードは、WelcomeとGroupInfoのダイジェストに束縛された非描画のkind 452確認応答であり、バイト単位で同一のWelcomeをKeyPackageを再消費せずに復元できます。ペアになったスポンサーはその枝における参加者の信頼の起点であり、グローバルな確定性を証明しません。付随するアカウント同期の文書は探索的で相互運用性がありません。この実験は採用済みのベースプロファイルには含まれません。

Nostr の 6 年間の 8 月

8月は1つの相互運用性の問題をたどります。クライアントがどのように対象を名指し、それにフィードバックを付けるかという問題です。元のprotocolリポジトリは2021年8月のコミットを記録しておらず、署名済みイベントの中核は動きませんでした。NIP-25（リアクション）は2022年にkind 1限定の枠を離れます。通常のreplaceableレコードは2023年に空の識別子を持つnaddrとaの座標を得ました。2024年には、別枠のparameterized-replaceableという分類がaddressable eventへ改称され、wire formatは変わりませんでした。リアクションは2025年に外部メディアへ移りました。NIP-22（コメントスレッド）のkind 1111は2026年に実際に書き込むクライアントへ届きました。この流れは、止まったprotocol文書から、ノート、replaceableレコード、ネットワーク外の対象をまたいで機能する共通の返信・リアクション語彙へと向かっています。

2021年8月

元のprotocolリポジトリの2021年8月のコミット窓は空です。その不活発な月の直前の変更は6月18日のNIP-05ドラフトで、公開鍵への人間可読なポインタとしてDNSドメイン識別子を追加しました。NIP-05（ドメイン識別子）は後にwell-known JSONファイルへ移りますが、2021年半ばではまだDNS TXTの参照でした。8月はその識別子の作業を広げることも、新しいイベントkindやrelayメッセージを追加することもありませんでした。

同じ空の窓は、仕様の隣にすでに存在していたツールにも現れます。2021年1月に作られたコマンドラインクライアントのnosclは8月のコミットを記録せず、go-nostrもnostr-toolsも同様でした。protocolの動きは年末になって再開し、リポジトリがNIP-09（イベント削除要求）を割り当て、DNS方式をwell-known JSONの識別子ファイルに置き換えました。2021年8月は、6月の識別子ドラフトと12月の削除およびwell-known JSONの作業のあいだにある不活発な段階であり、その間署名済みイベントとrelayのモデルは書かれたとおりに保たれていました。

2022年8月

8月19日、NIP-25の編集がkind 7リアクションの対象をkind 1テキストノートから他のノートへ広げました。kind 7イベントと+/-の慣習はすでにドラフトにありました。この相互運用性の変更により、いいね、よくない、絵文字がプロフィール、フォローリスト、あるいは同じeとp tagを再利用する後年のどのイベントkindにも付けられるようになりました。

現在のNIP-25仕様はこの一般化を保っています。リアクションは他のイベントに対するユーザーの反応を示し、addressableな対象にはkind:pubkey:d-tag座標を持つa tagも付きます。AndroidクライアントのAmethystはリアクションのbuilderでこの契約を実装しています。builderは任意のイベントを受け取り、e、p、k tagを書き、対象がaddressable eventのときはa tagを加えます。これによりリアクションの対象はkind 1を超えて一般化されました。後の8月の変更は安定した座標とコメントの文脈tagを加えていきます。

relayソフトウェアもtagの規則をストレージの挙動に落とし込んでいました。8月17日、nostr-rs-relayは16進数に見えるすべてのtag値をバイナリのインデックスキーとして扱うのをやめました。その最適化を1文字のtagと小文字の16進値に限定し、フィルタが一致させられない形式へデコードするのではなく通常のテキストtagを保ちました。同じ月は相互運用性の両面を結び付けたことになります。仕様はインタラクションが指し得る対象を広げ、relayはその対象tagのインデックス付けと取得の仕方を正しました。

2023年8月

8月24日、NIP-19（bech32識別子）は非parameterizedなreplaceable eventをnaddrとしてエンコードする方法を定めました。識別子フィールドであるd tagは、メタデータや連絡先リストのようにpubkeyとkindだけで置き換わるkindでは空文字列になりました。5日後、NIP-01（基本のイベントとrelay protocol）が対応するa-tag形式を追加しました。末尾のコロンを持ち識別子のないkind:pubkey:です。これによりクライアントは、次の置き換えで無効になる特定のevent idを待たずにreplaceableレコードを指せるようになりました。

現在のNIP-19の本文は、それらのreplaceable eventには空文字列を使うよう実装者に伝えています。JavaScriptの識別子ライブラリnostr-toolsはnaddrEncodeでそのフィールドをエンコードするので、呼び出し側は空の識別子を渡して共有可能な座標を作れます。2023年8月の作業は、replaceableな状態を、基となるイベントが置き換えられた後でもコメントやリアクション、共有リンクが名指せるものに変えました。翌年の8月は関連するparameterized-replaceableという分類の用語を標準化し、後のコメントtagはその座標文法をAとaとして再利用します。

同じ時期に非公開のペイロードも可搬になりつつありました。8月24日、rust-nostrはJavaScriptバインディングにNIP-44の暗号化・復号関数を追加し、バージョン付きのconversation key方式をネイティブRustの呼び出し側と並んでwebアプリケーションにも公開しました。8月22日、AmethystはNIP-44の暗号化をメッセージングイベント形式から分離し、内容をどう暗号化するかとアプリケーションがそれをどう運ぶかというprotocolの分離を反映しました。安定した座標は公開の対象を参照しやすくし、再利用可能な暗号化APIは非公開の内容を1つのメッセージkindに縛らずに実装間で移しやすくしました。

同じ月は、隣接する鍵の分離、インターフェース、教育の作業にも資金をもたらしました。8月17日のOpenSats助成ラウンドは、Nostr Fundの助成をAmber、共有のNostrインターフェース設計、Nostrの利用例の教育に配分しました。Amberの助成はNIP-46を通じて署名鍵を専用のAndroidアプリケーションに保つことに集中し、設計と教育の助成はオンボーディングと再利用可能なアプリケーションのパターンに取り組みました。より広いNostrのシステムは、仕様のコミット、鍵の分離、インターフェースの作業、そして共有インフラとして資金提供された開発者教育を通じて前進していました。

2024年8月

8月20日、仕様は「parameterized replaceable event」を「addressable event」へ改称しました。NIP-01と他の16の文書にまたがり、長文記事、ライブアクティビティ、リスト、カレンダー、classified listingを含みます。wire formatは変わりませんでした。kind:pubkey:d-tagが座標であり続けました。変わったのは、その座標をすでに使っていたすべての仕様が同じ語でそれを呼ぶようになったことです。

その語彙は現在の実装が出荷しているものです。NIP-01はaddressable eventをkind、pubkey、d tagごとの最新レコードとして保存します。NIP-19はnaddrを"a nostr addressable event coordinate"と呼びます。上で引いたAmethystのリアクション経路は、a tagを書く前に対象をAddressableEventとして型付けします。2023年の座標拡張と2024年の用語変更はどちらもkind:pubkey:d-tagという座標文法を使い、NIP-01は通常のreplaceable eventとaddressable eventの区別を続けています。したがって後のコメントは、その番地を今どのevent idが占めているかを気にせず、大文字のAでaddressableな議論を取得できます。

ストレージのprotocolも明示的な識別子への同じ好みを適用していました。8月27日、BlossomのBUD-04は1つの認可イベントが複数のblobハッシュx tagを持てるようにしました。これによりクライアントは、ハッシュが1つの対象を表しているかのように装わずに、上限付きのアップロード、ミラー、削除のバッチを認可できました。4日後、プロジェクトはblob descriptorを明確化し例を追加しました。Nostrイベントは内容アドレス指定されたメディアの操作を調整し、バイト列はメディアサーバーに留まって、署名された認可とストレージのトランスポートが分離されました。

8月29日、リモート署名は不完全なrelay集合に対して寛容になりました。go-nostrはNIP-46クライアントを変更し、1つの不調なrelayが他の設定済みrelay経由で送られるリクエストを妨げられないようにしました。relay接続と公開試行は独立に動き、いずれかの接続が成功すれば呼び出しは進みます。8月19日、OpenSatsはAmethystの作者Vitor Pamplonaへの長期支援も発表し、NIP-17の非公開メッセージ、クロスプラットフォームのライブラリ、outboxモデルの作業を含めました。protocolの語彙、粘り強いトランスポート、プライバシーの作業、そして継続的な保守資金は同じ目標へ収束していました。端末をまたぎ、まちまちなrelayの状況でも動き続けられるクライアントです。

2025年8月

8月22日、NIP-25は外部コンテンツへのリアクションを得ました。ネイティブなNostrイベントではないものへのリアクションはkind 17でなければならず、NIP-73（外部コンテンツ識別子）のkとi tagを持たなければならず、以前のwebサイト用r tagを置き換えます。マージされた本文の例はweb URL（k=web）と、番組GUIDと項目GUIDで識別されるポッドキャストのエピソードで、FountainのURLがヒントとして添えられます。リアクションは2022年にkind 1を離れました。今度はNostrのイベント集合そのものを離れたのです。

2025年8月15日に公開されたFountain 1.3は、仕様のマージより先にそれらのいいねを出荷し、他のポッドキャストアプリが読めるようNostrで動くと述べました。今日のNIP-25の文書はいまもFountainのポッドキャストGUIDの例を使っています。2025年8月までに、リアクションの座標は、コメントが後に外部rootに対して使うのと同じ識別子文法で、ポッドキャストのエピソードやwebページを名指せるようになっていました。

2026年8月

この8月は、通常の返信を書くクライアントにコメントスレッドを持ち込みました。後にマージされた6月の修正は、短いノートにNIP-22コメントを使わないようクライアントに伝えていた行を削除しました。続いてNIP-30（カスタム絵文字）がkind 1111を追加し、ノート、リアクション、ユーザーステータスと並べたので、コメントもそれらのkindが既に使っていた同じ絵文字tagを持てます。仕様の作業は許可です。クライアントの作業は展開です。

webクライアントのSnortは、kind 1の対象に対して既定でNIP-22コメントを公開し、大文字のE/A root tagでスレッドを購読し、通知でkind 1111を受け入れます。コミュニティ向けwebクライアントのDittoは、kind 1ノートへの返信も含めてすべての返信をNIP-22コメントとして公開し、テキストはkind 1111、音声は1244としつつ、NIP-10（ノートのスレッド化）の返信も読み続けます。6年間の移り変わりはこれらの既定に現れています。2022年はリアクションを一般化し、2023年と2024年は座標を名付け、2025年はリアクションをネットワーク外へ向け、2026年はコメントをそれら同じ対象に対する共通の返信イベントにしました。

非公開グループの基盤は、復旧を相互運用性の要件として定義していました。Marmotの8月13日の永続性と再起動の契約は、どのローカルMLSおよび公開の状態が再起動を生き延びなければならないかを定め、クライアントがグループ操作を続ける前に永続化された状態を突き合わせることを求めます。これは8月の流れを対象の名指しの先へ広げます。成熟したクライアントは、中断の後で安全に再開できるだけの暗号と配信の状態も保たなければなりません。共通のイベント形式が役に立つのは、実装がそれを使うために必要な状態を復元できるときだけです。

Nostr Compassプロジェクトを通じてプロジェクトやニュースを共有するには、NIP-17 DMを送ってください。