Nostr Compass #10 | Nostr Compass

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

今週の内容: BlossomのローカルキャッシュレイヤーがAndroid向けオフラインメディアアクセスを目指す独立プロジェクトの収束として形になっています。AlbyがNostr Wallet Connect統合のビルドとテストを実際の資金なしで行えるNWC開発者サンドボックスを立ち上げました。AIエージェント通信に関する競合提案が同じ週に2人の著者から届きました。fiatjafがリレー運営者がほとんど採用しなかった保持ポリシー、国コード、プライバシーポリシー、コミュニティ設定タグを削除し、NIP-11から未使用フィールドを除去しました。NIP-85がTrusted AssertionsのサービスプロバイダーのDiscoverability指針としてマージされました。NIP-52の新しいDタグがカレンダーイベントの日単位タイムスタンプインデックスを可能にします。新プロジェクトとして、分散型マップタイル配布のMapnolia、MLS暗号化メッセージングのPika、Android向けFROST閾値署名のKeep、Nostr統合コンテンツアドレス型ストレージのHashtree、AndroidアプリからNostrへコンテンツを共有するPrismが登場しています。Primal Androidがデュアルウォレットサポートと自動サービスライフサイクル管理を追加する11件のNWC PRをマージ。Mostro MobileがNWC統合による内蔵Lightningウォレットを出荷。NotedeckがAndroidアプリストアリリースに向けて準備し、HAVENがマルチnpubサポートとクラウドバックアップを備えたv1.2.0-rc3に到達。今週のディープダイブでは、Web of Trust計算をサービスプロバイダーに委任するNIP-85のTrusted Assertionsシステムと、日単位インデックス更新後のNIP-52カレンダーイベントプロトコルを取り上げます。

ニュース

Blossomローカルキャッシュレイヤーが登場

複数の独立プロジェクトが同じ問題に収束しています。モバイルデバイスでのBlossomメディアへのオフラインアクセスです。

Morganiteは、AmberとCitrineの開発者greenart7c3による新しいAndroidアプリで、Blossomメディアのクライアントサイドキャッシングを実装しています。ユーザーはネットワーク接続なしに以前に閲覧した画像やファイルにアクセスできます。

Aerithが画像ラベリング、一括ミラー・タグ・削除操作、ラベルとファイルタイプによるフィルタリング、初期ローカルBlossomキャッシュサポートを備えたv0.2を出荷しました。Aerithは複数のBlossomサーバーにメディアを保存するユーザーがblobを整理・ミラーリングするための管理インターフェースです。

Blossom仕様に新しいローカルキャッシュ実装ガイドが追加され、クライアントサイドのblobストレージが文書化されました。一方、Prism（Aerithと同じ開発者による）がAndroidのNostrへ共有フローにBlossomアップロード統合を追加。今週4つの独立プロジェクトが同じ問題に収束しました。専用キャッシュアプリ、メディアマネージャー、リファレンス仕様、Blossom統合を持つ共有ツールが、すべて単純なアップロード・取得を超えた永続的なローカルストレージを実装しています。

Alby NWC開発者サンドボックス

AlbyがNostr Wallet Connect（NIP-47）でビルドする開発者向けサンドボックス環境を立ち上げました。このサンドボックスはホスト型NWCウォレットサービスを提供し、開発者は実際のLightningウォレットに接続することなくテスト接続を作成してシミュレート決済を送信し、NWCイベントのリクエスト・レスポンスサイクル全体をリアルタイムで観察できます。開発者はサンドボックスからnostr+walletconnect://接続文字列を生成してクライアントに渡します。するとサンドボックスがクライアントとウォレットサービス間を流れるkind 23194リクエストとkind 23195レスポンスイベントを表示します。

これにより新しいNWC統合の参入障壁が下がります。以前はテストに個人のLightningウォレットまたはセルフホスト型NWCサービスが必要でした。サンドボックスはそれを抽象化し、pay_invoice、get_balance、make_invoice、lookup_invoice、list_transactionsメソッドをライブNWCエンドポイントに対して実装するための即時フィードバックループを開発者に提供します。

AIエージェントNIPが登場

Nostr上のAIエージェント通信に関する提案が数日以内に登場し、異なる角度から問題にアプローチしています。

joelklaboによるNIP-XX: AI Agent MessagesはAIエージェントインタラクションの完全なプロトコルを定義しています。プロンプト、レスポンス、ストリーミングデルタ、ステータス更新、ツールテレメトリ、エラー、キャンセル、機能ディスカバリー用のevent kindです。ai.infoディスカバリーイベント（kind 31340、置換可能）でエージェントがサポートするモデル、スキーマ付きツール、ストリーミングサポート、レート制限をアナウンスできます。joelklaboの提案にはプロンプトIDによるラン相関、セッション管理、シーケンス順序によるストリーム照合、メタデータプライバシー用のNIP-59ガイダンスが含まれています。

pablof7zによるNIP-AE: Agentsは異なるアプローチを取り、エージェントのインスタンス化のためのkindを定義しています。定義とレッスンです。これらはpablof7zがNostr上に構築された自律学習システムTENEXで使用するeventタイプです。同じくpablof7zによるコンパニオン提案NIP-AD: MCP Server and Skill AnnouncementsはNostr上でModel Context Protocolサーバーとスキルをアナウンスするためのeventを定義しています。NIP-22コメントがサポートされているため、コミュニティはNostr上で直接MCPサーバーについて議論・評価できます。

NIP-XXがエージェント通信全体をカバーし、NIP-AEとNIP-ADがアイデンティティとツールディスカバリーに対応します。これらの提案は統一された標準に収束するか、補完的なレイヤーとして共存するかもしれません。

リリース

HAVEN v1.2.0-rc3

Blossomメディアサーバーと4つのリレー機能をバンドルしたオールインワンパーソナルリレーのHAVENがv1.2.0-rc3に到達しました。このリリース候補では複数のnpubサポートが追加され、単一のHAVENインスタンスで複数のNostrアイデンティティを提供できます。以前のRCではクラウドバックアップ用の--from-cloudと--to-cloudフラグ（RC2）が追加され、Web of Trustの二重カウントバグが修正されました（RC1）。

Mostro Mobile v1.2.0：内蔵Lightningウォレット

Mostro P2P Bitcoin取引所のモバイルクライアントMostro Mobile（先週取り上げたv1.1.0）が、完全なNWC（NIP-47）統合による内蔵Lightningウォレットを備えたv1.2.0を出荷しました。買い手と売り手はインボイスの処理にアプリを切り替える必要がなくなりました。アプリが売り手向けにホールドインボイスを検出して接続ウォレット経由で自動的に支払い、買い手は自動的なインボイス生成を受けられます。このリリースは同週前半のv1.1.1に続くもので、信頼できるインスタンスの厳選レジストリを持つマルチMostroノードサポート、ノード表示用のkind 0メタデータ取得、pubkeyによるカスタムノード管理、選択したノードがオフラインになった際の自動フォールバックが追加されました。

サーバー側ではMostro v0.16.2がリリースされ、重複開発手数料支払いの修正、パスワード検証RPCエンドポイントのレート制限、協調キャンセル時の適切な紛争クリーンアップが含まれています。

新しいコンパニオンプロジェクトmostro-skillにより、エージェントがNostrを通じてMostroで取引できます。

Aerith v0.2

Blossom画像マネージャーのAerithが、メディア整理用の画像ラベル、サーバー間の一括ミラー・タグ・削除操作、ラベルとファイルタイプによるフィルタリング、初期ローカルキャッシュサポートを備えたv0.2を出荷しました。ローカルキャッシュトレンドの全体的な文脈についてはニュースセクションを参照してください。

Mapnolia：Nostr経由の分散型マップタイル

Mapnoliaは、PMTilesマップアーカイブを地理的地域にチャンク化し、分散型ディスカバリーのためにNostr上でアナウンスする新しい地理空間データサーバーです。kind 34444のパラメータ化された置換可能イベントをNostrリレーに公開し、マップタイルチャンクの完全なインデックス、レイヤーメタデータ、ジオハッシュ地域、ファイル参照、Blossomサーバー詳細を含みます。

クライアントは中央集権的なタイルサーバーの代わりにNostrネットワークを通じてマップデータを発見・取得します。アナウンスイベントにはリストされたBlossomサーバーから必要な地理的地域のみをリクエストするのに十分なメタデータが含まれています。Mapnoliaは地理空間データ配布をNostrにもたらす最初のプロジェクトで、オフライン対応マッピングアプリケーションの可能性を開きます。

Pika：MarmotベースのE2E暗号化メッセージング

Pikaは、Nostrリレー上にMessaging Layer Security（MLS）をレイヤー化するMarmotプロトコルを使用したiOSとAndroid向けの新しいE2E暗号化メッセージングアプリです。アーキテクチャは関心事を分離しており、Nostrリレー経由のMLSステート管理とメッセージ暗号化・復号化を処理するRustコア（pika_core）と、SwiftUI（iOS）とKotlin（Android）のシンネイティブUIシェルで構成されています。ステートはUniFIとJNIバインディングを通じてUIからRustアクターへのアクション、そして状態とリビジョン番号のスナップショットをUIに返す一方向フローで流れます。

PikaはNostrリレーをMLSで暗号化された暗号文のトランスポートレイヤーとして使用するWhite Noise、Vector、0xchatと並ぶ成長中のMLS-on-Nostrメッセンジャー分野に加わります。すべてがNostrリレーをMLSで暗号化された暗号文のトランスポートレイヤーとして使用し、リレー運営者はメッセージ内容を読めません。PikaはMLS実装にMarmot Development Kit（MDK）を、リレー接続にnostr-sdkを使用しています。

Keep：Android向けFROST閾値署名

Keepは、単一デバイスが完全な秘密鍵を保持しないFROST閾値署名のための新しいAndroidアプリケーションです。NIP-55（Android Signer）とNIP-46（リモート署名）を実装しており、互換Nostrクライアントが鍵素材をデバイス間で分散したまま署名をリクエストできます。デフォルト設定は2-of-3と3-of-5ですが、任意のt-of-n閾値がサポートされています。

KeepのDKG（分散鍵生成）セレモニーはカスタムevent kindを使用してNostrリレー上で実行されます。kind 21101はグループアナウンス、kind 21102はラウンド1コミットメント多項式（公開ブロードキャスト）、kind 21103はラウンド2シークレットシェア（参加者間のNIP-44暗号化ポイントツーポイント）です。グループ秘密鍵スカラーはDKG中にどこでも計算・組み立てられません。各デバイスは多項式評価シェアのみを保持し、任意のtシェアが2ラウンドのコミット・次に署名プロトコルを通じて有効なSchnorr署名を生成できます。結果の64バイト署名は単一署名者のSchnorr署名と区別できません。内部的にKeepはZcash Foundationのfrost-secp256k1-trクレートをTaproot調整で使用しており、グループ公開鍵がNostr npubとして直接機能します。

KeepはIgloo Desktop、Igloo for Android、Frost2x、Igloo for iOSと並ぶFrostrファミリーに加わり、Nostrにおける閾値鍵管理の選択肢を拡げます。

Prism：AndroidアプリからNostrへ何でも共有

Prismは、ユーザーが電話上の任意のアプリからテキスト、URL、画像、動画をNostrに公開できるよう、システム共有ターゲットとして登録する新しいAndroidアプリ（Kotlin/Jetpack Compose、API 26+）です。共有URLはノートに組み込まれる前にトラッキングパラメータ除去ツールを通過します。PrismはOpenGraphメタデータを取得してリッチリンクプレビューを生成し、ネイティブNostr参照（note1、nevent1）をインラインでレンダリングします。

スケジューリングエンジンはAndroidバッテリー最適化をバイパスするハイブリッドなAlarmManager/WorkManagerアプローチを使用しています。AlarmManagerが正確なウェイクアップタイミングを処理し、エクスペディットWorkManagerタスクがデリバリーを保証し、オフラインシナリオには指数バックオフリトライがあります。メディアアップロードは画像と動画フレームのサムネイル生成を備えた設定可能なBlossomサーバーを通過します。すべてのevent署名はAmberのようなNIP-55外部署名者に委任され、アイデンティティ切り替えのマルチアカウントサポートがあります。PrismはNIP-84（ハイライト）投稿もサポートしています。Aerithと同じ開発者によるものです。

Hashtree：Nostr統合コンテンツアドレス型ストレージ

Hashtreeは、MerkleルートをNostr上に公開することでミュータブルなnpub/パスアドレスを作成するファイルシステムベースのコンテンツアドレス型blobストレージシステムです。このシステムは任意のキー・バリューストアで動作する「ダムストレージ」を使用し、コンテンツをBlossomアップロードに最適化された2MBブロックにチャンク化します。BitTorrentとは異なり、アクティブなMerkle証明計算は不要で、ハッシュでblobを保存・取得するだけです。

Nostr統合により、htree://npub.../repo-nameのようなgitリモートURLでリポジトリをクローンでき、htree publish mydata <hash>のようなコマンドでnpub.../mydataアドレスにコンテンツハッシュを公開できます。包括的なCLIは暗号化（デフォルト）とパブリックストレージモード、コンテンツピン止め、Blossomサーバーへのプッシュ、Nostrアイデンティティ管理をサポートしています。各保存アイテムは生バイトまたはツリーノードで、Nostrのリレーネットワークを通じた分散型コンテンツ配布の基盤を提供します。

Espy：Shakespeare上のカラーパレットキャプチャ

Shakespeareプラットフォーム上に構築されたEspyは、ユーザーが写真からカラーパレットをキャプチャしてNostrイベントとして共有できるアプリです。ShakespeareはNIP-07ブラウザ拡張機能でユーザーを認証し、組み込みのNostrリレー接続を提供するAIパワードアプリビルダーで、開発者は独自の鍵管理やリレープールを実装せずにアプリを出荷できます。Espyはカメラ入力から支配的な色を抽出し、標準的なNostrフィードで発見可能な共有可能なパレットカードにします。

Flotilla 1.6.4

hodlbodのDiscordライクなNostrクライアントFlotillaがリレーをグループとして整理する1.6.4を出荷しました。Coracleファミリーのプロジェクトがセルフホスト型Gitea インスタンスに移行しました。このリリースはNIP-9a経由のプッシュ通知とウォレット受信フロー、分類リストとスペースURLサポートを追加。インターフェースの改善にはモーダルと通知処理のクリーンアップが含まれています。モバイルでのルームミュートとセーフエリアインセットも変更点で、SafariでのSOURCE画像アップロードとカレンダーイベント詳細の修正もあります。

Shosho v0.12.0

Nostr統合モバイルライブストリーミングアプリShoshoがv0.12.0を出荷しました。このリリースはインプレーヤーリプライとカスタム絵文字統合を備えた動画クリップを追加。スレッド保護が間接的なメンションスパムをブロックし、新しいQR共有機能でユーザーがオフラインでプロフィールを交換できます。新しいホリゾンタル再生モードでストリームにTwitchスタイルの視聴体験が生まれ、ブラウズ画面にライブストリームと並んでクリエイタークリップが表示されます。

Granary v10.0

Nostr、Bluesky、ActivityPub、その他のプラットフォーム間でデータを共通フォーマットに変換するソーシャルウェブ変換ライブラリGranaryが、重大な変更を含むv10.0を出荷しました。このリリースはNostrのデフォルトActivityStreams 1 IDをbech32からhexに切り替え、NIP-27メンション解析とarticleタグを含む拡張Nostrサポートを追加します。コンバーター全体の新しい複数出力オプションにより、開発者がプロトコル間でバッチ変換できます。

Nostr MCP Server v3.0.0

AIエージェントがNostrネットワークとインタラクションできるModel Context ProtocolサーバーのNostr MCP Serverがv3.0.0を出荷しました。このメジャーリリースはソーシャルアクション（フォロー、リアクション、リポスト、リプライ）とNIP-65サポートに加えてオプションのNIP-42認証を含むリレーリスト管理を追加します。NIP-17とNIP-44経由のダイレクトメッセージも新しく追加されました。このリリースは今週のAIエージェントNIP提案とペアになり、Nostr上で活動するエージェントの実用的なツールとなります。

Aegis v0.3.8

クロスプラットフォームNostr署名者Aegisが、多言語UIサポートと内蔵Nostrアプリブラウザーのインクリメンタルアップデートマネージャーを備えたv0.3.8を出荷しました。新しいアップデートメカニズムはローカル状態に対してインクリメンタルにdiffし、Nostrウェブアプリのアプリ内ディレクトリを低帯域幅使用量で最新に保ちます。このリリースでは連続して複数のeventに署名する際のデータベースラウンドトリップを削減するため、5分間の鍵素材キャッシングも導入されます。

SNSTR v0.3.1

NostrプロトコルのTypeScriptライブラリSNSTR（Secure Nostr Software Toolkit for Renegades）がv0.3.1を出荷しました。このリリースはすべてのエントリーポイントがnpmタービューに含まれることを確認するパッケージ検証ガードを追加し、NodeとBunのCIエンフォースメントがあります。v0.3.0も同じ週に出荷されました。

Citrine v2.0.0-pre1

greenart7c3によるAndroid NostrリレーCitrineが、最適化されたデータベースインデックスとKotlinコルーチン処理の改善によるパフォーマンス向上を含むv2.0.0-pre1をリリースしました。このリリースはウェブアプリのホスティングサポートも強化し、各アプリが独自ポートで動作するようになりました。

プロジェクトアップデート

Primal Android：NWCインフラ拡張

Primal Androidが今週11件のNWC関連PRをマージし、2週間前に開始した構築を継続しました。このバッチはデュアルウォレットNWCサポート、バックエンド通知に連動した自動サービスの開始・停止、ウォレットタイプによる接続ルーティング、ウォレット削除時の適切なデータクリーンアップを追加します。NWCサービスがウォレット接続状態に基づいて独自のライフサイクルを管理するようになり、ユーザーの手動操作が減ります。

Notedeck：Androidアプリストアの準備

DamusチームによるマルチプラットフォームNostrクライアントNotedeckが今週Androidアプリストアリリース準備をマージしました。このPRはGoogle Playが要求するUGC（ユーザー生成コンテンツ）コンプライアンスプランを追加しており、利用規約同意画面、コンテキストメニューと設定からのユーザーブロック、レポートイベントをリレーに公開するNIP-56（報告）機能、コンテンツ・安全設定セクションが含まれます。署名済みリリースAPKとAAB（Android App Bundle）を新しいMakefileターゲット経由で生成するビルドインフラも追加されました。EULAドキュメントが17歳以上の要件とNostr固有の分散型コンテンツに関する免責事項を定めています。コンプライアンス機能自体はフォローアップPRで出荷されます。このマージはドキュメントと署名の基盤を整えるものです。

Damus iOS側では、コンテンツがロード済みにもかかわらずスピナーが永続する無限ローディングスピナーのリグレッションの修正が入りました。

Nostria：ディスカバリーリレーとDM修正

クロスプラットフォームNostrクライアントNostriaが今週9件のPRをマージしました。最も注目すべきものはプロフィールルックアップ用のディスカバリーリレーの自動初期化を追加し、新規ユーザーが手動設定なしにリレー接続を得られます。その他の修正はDMテキストエリアの折り返し、フルスクリーン動画ビューポートフィル、リポストプレビューでのarticleメタデータ抽出、通知でのnostr: URI解決に対応しています。

Camelus：Riverpod v3移行

FlutterベースのNostrクライアントCamelusが今週5件のPRをマージし、Riverpod v3 API移行と汎用フィードリファクタリングを中心とした作業を行いました。組み込みノートキャッシュが引用ノートの冗長なリレー取得を回避します。

NIPアップデート

NIPsリポジトリへの最近の変更：

マージ済み：

NIP-85：サービスプロバイダーDiscoverability：vitorpamplonaがリレーヒントとアルゴリズム固有のサービスキーを含むNIP-85 Trusted Assertionsサービスプロバイダーのクライアントディスカバリープロセスに関するガイダンスを追加しました。詳細は下記のディープダイブを参照してください。
NIP-11：リレー情報のクリーンアップ：fiatjafがNIP-11からprivacy_policy、retention配列、relay_countries、コミュニティ設定ブロックを削除しました。リレー運営者はこれらのフィールドをほとんど使用せず、クライアントもそれらに基づいた動作をしていませんでした。
NIP-52：日単位タイムスタンプタグ：staabがNIP-52の時間ベースカレンダーイベント（kind 31923）に必須のDタグを追加しました。floor(unix_seconds / 86400)として計算される日単位Unixタイムスタンプを表し、複数のDタグが複数日イベントをカバーし、完全なタイムスタンプを解析せずに効率的な時間インデックスを可能にします。
NIP-47：簡素化：ニュースレター#9で取り上げた簡素化PRが今週マージされ、NIP-47（Nostr Wallet Connect）からmulti_pay_invoiceとmulti_pay_keysendが削除されました。完全なNWCプロトコルディープダイブはニュースレター#8を参照してください。

オープンPRとディスカッション：

NIP-74：ポッドキャスト：ニュースレター#8で取り上げたこのポッドキャスト仕様提案が今週活発な議論を展開しました。staabはすでに少なくとも3つの競合するポッドキャスト標準が実際に存在すると指摘し、derekrossは6ヶ月前からアクティブなアプリとポッドキャストを持つ既存の実装を示しました。実装間の収束がNIP番号を割り当てられる前に必要です。
NIP-XX：AIエージェントメッセージ：joelklaboがプロンプト、レスポンス、ストリーミング、ツールテレメトリ、エラー、機能ディスカバリー用のevent kindを持つ完全なAIエージェント通信プロトコルを提案しています。今週のすべてのAI提案のカバレッジはニュースセクションを参照してください。
NIP-PNS：プライベートノートストレージ：jb55のプライベートノートシステムは、誰が書いたかを明らかにすることなく暗号化された個人ノートをリレーに保存するためのkind 1080イベントを定義しています。このスキームはHKDFを通じてユーザーのnsecから決定論的な仮名キーペアを導出します。pns_key = hkdf_extract(ikm=device_key, salt="nip-pns")、そしてその導出キーからsecp256k1キーペアを生成します。2番目の導出が対称暗号化キーを生成します。pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2")。内部ノートはこのキーでNIP-44 v2で暗号化され、仮名pubkeyで公開されるため、リレーはユーザーのメインキーにリンクされていないアイデンティティからのkind 1080イベントを見ます。NIP-59のギフトラップとは異なり、PNSはスパム不可能（仮名キーは決定論的でランダムではない）でゼロのパブリックメタデータを持ちます（受信者がいないのでpタグが不要）。今週、jb55がNotedeck のRustバックエンド（enostr::pnsモジュール）でPNSを実装した際の所見を投稿しました。仕様のhkdf_extract呼び出しがRFC 5869 HKDFに2つのフェーズ（抽出と展開）があり異なる出力を生成し、ほとんどのライブラリが両方を期待するため曖昧であることを特定しました。pns_nip44_keyがNIP-44の通常のECDH鍵合意をバイパスして会話キーとして直接使用されることを明確化しました。これはほとんどのNIP-44ライブラリがデフォルトでECDHを使用するため実装者が知る必要がある詳細です。参照実装のTypeScriptで未定義変数も指摘しました。元々2025年4月からのこのPRが今積極的に実装されています。
NIP-AE：エージェント：pablof7zがTENEXでの作業から得たNostr上のエージェントアイデンティティのための4つのevent kindを定義しています。基本テンプレートはkind 4199（エージェント定義）で、タイトル、役割説明、システム指示、ツール宣言、バージョンを持ちます。動作モディファイアーはkind 4201（エージェントナッジ）に存在し、実行時の機能制御のためにonly-tool、allow-tool、deny-toolタグを使用します。エージェントは学習内容をkind 4129（エージェントレッスン）イベントとして公開し、eタグで親定義にリンクし、NIP-22コメントスレッドで洗練されます。所有権検証はkind 14199を使用し、エージェントpubkeyをリストする置換可能イベントで、エージェントのkind 0プロフィールのpタグと照合した際に双方向チェーンを確立します。
NIP-AD：MCPサーバーとスキルアナウンス：pablof7zがNostr上でModel Context Protocolサーバーと個々のスキルをアナウンスするためのeventを定義しています。MCPサーバーアナウンスはサーバーのエンドポイントURLとサポートされるプロトコルバージョン、入力スキーマ付きの利用可能ツールリストを持ちます。サーバーアナウンスにNIP-22コメントがサポートされているため、コミュニティはNostr上で直接MCPサーバーを議論・評価できます。
NIP-73：OSMタグkind：DestBroがISBN（書籍）、ISAN（映画）、ポッドキャストフィード（GUID）、ジオハッシュ、URLなどの外部コンテンツへのNostrイベント参照をiとkタグで標準化するNIP-73（外部コンテンツID）にOpenStreetMap識別子の追加を提案しています。提案されたOSM kindにより、イベントがOpenStreetMapのノードまたはウェイIDで特定の地図フィーチャー（建物、道路、公園）を参照でき、Nostrコンテンツをオープンな地理データベースに接続します。
NIP-XX：レスポンシブ画像バリアント：woikosがNIP-94ファイルメタデータイベントを異なる解像度のレスポンシブ画像バリアント用のタグで拡張することを提案しています。クライアントが表示サイズとネットワーク条件に基づいて適切なバリアントを選択でき、Blossomサーバーにホストされた高解像度画像を閲覧するモバイルユーザーの帯域幅を削減します。

NIPディープダイブ：NIP-85（Trusted Assertions）

NIP-85は高コストな計算を信頼できるサービスプロバイダーに委任し、そのプロバイダーが署名済みの結果をNostrイベントとして公開するシステムを定義しています。Web of Trustスコアとエンゲージメントメトリクスには多くのリレーをクロールして大量のeventボリュームを処理する必要があり、モバイルデバイスでは実行不可能な作業です。今週のマージによりこれらのプロバイダーのクライアントディスカバリープロセスに関するガイダンスが追加されました。

委任：

ユーザーのWeb of Trustスコアを計算するには多くのリレーにまたがって複数ホップのフォローグラフをクロールする必要があり、正確なフォロワー数を計算するにはリレーネットワーク全体での重複排除が必要です。モバイルデバイスとブラウザクライアントはこれらの操作を実行できませんが、その結果はスパムフィルタリングとコンテンツランキングに不可欠です。NIP-85は、ユーザーが信頼できるプロバイダーを指定して計算を実行し、結果を標準Nostrイベントとして公開することを可能にすることでこのギャップを埋めます。

プロトコル設計：

NIP-85は異なるサブジェクトタイプに関するアサーションのための4つのevent kindを使用します。ユーザーアサーション（kind 30382）はフォロワー数、投稿・リプライ・リアクション数、zap量、正規化ランク（0-100）、共通トピック、アクティブ時間を持ちます：

{
  "id": "<event hash>",
  "pubkey": "<service pubkey>",
  "created_at": 1739836800,
  "kind": 30382,
  "tags": [
    ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
    ["rank", "89"],
    ["followers", "4521"],
    ["first_created_at", "1609459200"],
    ["post_cnt", "1283"],
    ["reply_cnt", "647"],
    ["reactions_cnt", "8920"],
    ["zap_amt_recd", "850000"],
    ["zap_amt_sent", "320000"],
    ["zap_cnt_recd", "412"],
    ["zap_cnt_sent", "198"],
    ["zap_avg_amt_day_recd", "1150"],
    ["zap_avg_amt_day_sent", "430"],
    ["reports_cnt_recd", "2"],
    ["reports_cnt_sent", "0"],
    ["t", "nostr"],
    ["t", "bitcoin"],
    ["active_hours_start", "14"],
    ["active_hours_end", "22"]
  ],
  "content": "",
  "sig": "<service key signature>"
}

イベントアサーション（kind 30383）はコメント数、引用数、リポスト数、リアクション数、zapデータで個々のノートを評価します：

{
  "id": "<event hash>",
  "pubkey": "<service pubkey>",
  "created_at": 1739836800,
  "kind": 30383,
  "tags": [
    ["d", "<target event id>"],
    ["rank", "72"],
    ["comment_cnt", "45"],
    ["quote_cnt", "12"],
    ["repost_cnt", "89"],
    ["reaction_cnt", "310"],
    ["zap_cnt", "23"],
    ["zap_amount", "125000"]
  ],
  "content": "",
  "sig": "<service key signature>"
}

アドレス指定可能なイベント（長文記事、wikiページ）については、kind 30384がすべてのバージョンにわたって同じエンゲージメントメトリクスを適用します。Kind 30385はiとkタグでNostrイベントが外部コンテンツを参照する方法を標準化するNIP-73（外部コンテンツID）を通じて参照される外部識別子（書籍、映画、ウェブサイト、場所、ハッシュタグ）を評価します：

{
  "id": "<event hash>",
  "pubkey": "<service pubkey>",
  "created_at": 1739836800,
  "kind": 30385,
  "tags": [
    ["d", "isbn:9780765382030"],
    ["k", "isbn"],
    ["rank", "94"],
    ["comment_cnt", "67"],
    ["reaction_cnt", "203"]
  ],
  "content": "",
  "sig": "<service key signature>"
}

各アサーションはdタグにサブジェクト（pubkey、event ID、eventアドレス、またはNIP-73識別子）を含む置換可能なアドレス指定可能イベントです。サービスプロバイダーはこれらのイベントに独自のキーで署名し、クライアントは信頼関係に基づいて評価します。

プロバイダーディスカバリー：

ユーザーはkind 10040イベントを公開することで信頼するアサーションプロバイダーを宣言します。各エントリーはプロバイダーpubkeyとリレーヒント、オプションのアルゴリズムバリアントとともにアサーションタイプを指定します：

{
  "id": "<event hash>",
  "pubkey": "<user pubkey>",
  "created_at": 1739836800,
  "kind": 10040,
  "tags": [
    ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
    ["30382:rank", "3d842afe...", "wss://nostr.wine"],
    ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
    ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
  ],
  "content": "",
  "sig": "<user signature>"
}

ユーザーはプロバイダー設定を非公開にするため、NIP-44を使用して.contentのタグリストを暗号化できます。クライアントはフォローしたアカウントが信頼するプロバイダーを確認することでプロバイダーリストを構築し、アサーションプロバイダー自体の分散型レピュテーションレイヤーを作ります。

セキュリティモデル：

プロバイダーは異なるアルゴリズムには異なるサービスキーを使用しなければならず、アルゴリズムがユーザーごとにパーソナライズされる場合はユーザーごとにユニークなキーが必要で、ユーザー間のクエリのクロス相関を防ぎます。各サービスキーにはアルゴリズムの動作を説明するkind 0メタデータイベントがあり、ユーザーが何を信頼しているかを透明にします。アサーションイベントは基礎となるデータが実際に変化した場合にのみ更新されるべきで、不必要なリレートラフィックを防ぎ、クライアントが結果を自信を持ってキャッシュできるようにします。

現在の採用状況：

NIP-85は非公式にすでに生まれつつあったパターンを正式化しています。PrimalのキャッシュサーバーがエンゲージメントメトリクスとWeb of Trustスコアを計算しています。ニュースレター#9で取り上げたAntiprimalがNIP-85のevent kindを使用してこれらの計算を標準Nostrクライアントに橋渡ししています。Nostr.bandは仕様の例で参照されているwss://nip85.nostr.bandリレーを運営し、検索インデックスデータのアサーションイベントを提供しています。クライアント側では、Amethyst（このNIPを書いたvitorpamplonaが開発）がアサーションイベントとサービスプロバイダー宣言を解析するquartzライブラリで実験的なTrusted Assertionsサポートを持っています。Vertexは同様のWeb of Trustメトリクスを計算していますが、ディスカバリー問題とアサーションベースのアーキテクチャの計算オーバーヘッドを理由に、NIP-85イベントの代わりに直接APIを使用する異なるアプローチを選択しました。NIP-85があれば、クライアントは標準のeventフォーマットを通じて任意のプロバイダーからアサーションを消費でき、プロバイダーは精度で競争し、ユーザーが誰を信頼するかを選択します。

NIPディープダイブ：NIP-52（カレンダーイベント）

NIP-52はNostr上のカレンダーイベントを定義し、クライアントが特定の瞬間または瞬間の間の出来事を標準的な方法で表現・発見できます。今週のDタグマージにより日単位インデックスが追加され、仕様のクエリインフラの欠落していたピースが完成しました。

2つのeventタイプ：

NIP-52は時間精度に基づいてカレンダーイベントを2つのkindに分けます。日付ベースイベント（kind 31922）は祝日や複数日フェスティバルのような終日の出来事を表します。startとオプションのendタグにISO 8601日付文字列を使用し、タイムゾーンは考慮しません：

{
  "id": "<event hash>",
  "pubkey": "<event creator pubkey>",
  "created_at": 1735689600,
  "kind": 31922,
  "content": "Annual celebration of Bitcoin's genesis block",
  "tags": [
    ["d", "bitcoin-independence-day-2026"],
    ["title", "Bitcoin Independence Day"],
    ["start", "2026-01-03"],
    ["end", "2026-01-04"],
    ["location", "Worldwide"],
    ["g", "u4pruydqqv"],
    ["t", "bitcoin"],
    ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
    ["r", "https://bitcoinindependenceday.com"]
  ],
  "sig": "<event creator signature>"
}

時間ベースイベント（kind 31923）はstartとオプションのendタグにUnixタイムスタンプを持つ特定の瞬間を表し、表示用のIANAタイムゾーン識別子（start_tzid、end_tzid）も持ちます。両kindはパラメータ化された置換可能イベントで、主催者は同じdタグで新しいイベントを公開することで詳細を更新できます。

カレンダーとRSVP：

Kind 31924イベントはコレクションとしてカレンダーを定義し、kind 31922またはkind 31923イベントをそのアドレス座標で指すaタグでイベントを参照します：

{
  "id": "<event hash>",
  "pubkey": "<calendar owner pubkey>",
  "created_at": 1739836800,
  "kind": 31924,
  "content": "Nostr community events worldwide",
  "tags": [
    ["d", "nostr-community-calendar"],
    ["title", "Nostr Community Events"],
    ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
    ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
  ],
  "sig": "<calendar owner signature>"
}

ユーザーは複数のカレンダー（個人、仕事、コミュニティ）を維持でき、クライアントは特定のpubkeyからカレンダーを購読できます。カレンダーイベントはカレンダーを参照するaタグを含めることで参加リクエストを送れ、複数のユーザーが所有していないカレンダーにイベントを追加する協力的なカレンダー管理を可能にします。

RSVPはkind 31925を使用し、ユーザーがオプションの空き・ビジーインジケーターとともに出席ステータスを公開します：

{
  "id": "<event hash>",
  "pubkey": "<attendee pubkey>",
  "created_at": 1739836800,
  "kind": 31925,
  "content": "Looking forward to it",
  "tags": [
    ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
    ["e", "<kind 31923 event id>", "wss://relay.example.com"],
    ["d", "<unique-rsvp-id>"],
    ["status", "accepted"],
    ["fb", "busy"],
    ["p", "<organizer-pubkey>", "wss://relay.example.com"]
  ],
  "sig": "<attendee signature>"
}

有効なstatus値は「accepted」「declined」「tentative」で、オプションのfbタグでその期間のユーザーの空き・ビジー状態を示します。RSVPイベントはカレンダーイベントのaタグを参照し、主催者のpタグを持つため、主催者のクライアントがリレーをまたいでレスポンスを集約できます。

Dタグの追加：

今週のマージ以前は、日付範囲でイベントをクエリするクライアントがpubkeyまたはカレンダーからすべてのイベントを取得してクライアントサイドでフィルタリングする必要がありました。時間ベースイベント（kind 31923）の新しい必須Dタグにはfloor(unix_seconds / 86400)として計算された日単位Unixタイムスタンプが含まれます。複数日イベントには1日1つの複数のDタグが付きます。リレーがこれで日単位でイベントをインデックス化し、フィルタリングされたクエリに効率的に応答できるようになり、クライアントサイドのフィルタリング問題がリレーサイドのインデックスルックアップに変わります。

{
  "id": "<event hash>",
  "pubkey": "<event creator pubkey>",
  "created_at": 1739836800,
  "kind": 31923,
  "content": "Monthly meetup for Nostr developers in Austin",
  "tags": [
    ["d", "nostr-meetup-2026"],
    ["title", "Nostr Developer Meetup"],
    ["summary", "Talks and demos from local Nostr builders"],
    ["image", "https://example.com/meetup-banner.jpg"],
    ["start", "1740067200"],
    ["end", "1740078000"],
    ["start_tzid", "America/New_York"],
    ["end_tzid", "America/New_York"],
    ["D", "20139"],
    ["location", "Bitcoin Commons, Austin TX"],
    ["g", "9v6knb2pg"],
    ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
    ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
    ["t", "nostr"],
    ["t", "meetup"],
    ["r", "https://bitcoincommons.com"]
  ],
  "sig": "<event creator signature>"
}

D値の20139はfloor(1740067200 / 86400)に等しく、このイベントを2025年2月20日に配置します。「今週のすべてのイベント」をクエリするクライアントは対応するD範囲でフィルターを送信し、リレーは一致するイベントのみを返します。

設計上の決定：

NIP-52は繰り返しイベントを意図的に省略しています。仕様は繰り返しルール（iCalendarからのRRULE）を完全に除外し、その複雑さをクライアントに委ねています。主催者は各出来事ごとに個別のイベントを公開し、リレーサイドのデータモデルをシンプルに保ちます。参加者タグはオプションのロール（「host」「speaker」「attendee」）を持ち、locationタグは人間が読めるアドレスと並んで空間クエリ用のジオハッシュgタグを含めることができます。

実装：

FlockstrはNIP-52上に構築された主要なカレンダークライアントです。Coracleがソーシャルフィードでカレンダーイベントを表示します。今週のDタグ追加により、両クライアントが特定の日付範囲でイベントをクエリする際の帯域幅削減に活用できるリレーサイドの時間インデックスが可能になります。

今週は以上です。構築中のプロジェクトや共有したいニュースがあれば、NIP-17 DMでお問い合わせください。Nostrでもお待ちしています。