Nostr Compass #2 | Nostr Compass

Nostr Compassへおかえりなさい。Nostrプロトコルエコシステムの週刊ガイドです。

今週のハイライト: 3つのNIP-55署名アプリ実装がアップデートされました: Amberはパフォーマンスキャッシュを追加、Aegisはnostrsigner: URIサポートを獲得、Primal Androidは完全なローカル署名アプリとして参加。Shopstrはzapを通じたフラッシュセール「Zapsnags」を導入。Mostroは開発基金を追加。4つのNIP更新がランディングし、パブリックメッセージ（kind 24）とグループプライバシーの改善を含みます。NDKキャッシュクエリが162倍高速化、ApplesauceはリアクションとNIP-60ウォレットサポートを追加、TenexはAIエージェント委任のためのRALアーキテクチャを導入。詳細解説では、NIP-02（フォローリスト）とNIP-10（返信スレッディング）について説明します。これらはソーシャルタイムラインと会話を構築するための基礎的な仕様です。

ニュース

Primal AndroidがNIP-55署名アプリに - 先週のNostr Connectサポートに続き、Primalは8つのマージされたプルリクエストを通じて完全なローカル署名機能を実装しました。実装には、NIP-55仕様に従ってAndroidのコンテンツプロバイダーインターフェースを介して他のAndroidアプリに署名操作を公開する完全なLocalSignerContentProviderが含まれます。アーキテクチャは関心を明確に分離しています: SignerActivityはユーザー向けの承認フローを処理し、LocalSignerServiceはバックグラウンド操作を管理し、新しい権限システムによりユーザーはどのアプリが署名を要求できるかを制御できます。これにより、異なるNostr体験のために他のアプリを使用しながら鍵を1つのアプリに保持したいAndroidユーザーにとって、PrimalはAmberの代替となります。

Shopstr Zapsnags: Lightningを介したフラッシュセール - Nostrネイティブマーケットプレイスは「Zapsnags」を導入しました。これはソーシャルフィードから単一のzapで商品を購入できるフラッシュセール機能です。実装は#shopstr-zapsnagタグ付きのkind 1ノートをフィルタリングし、標準的なカートフローの代わりに「Zap to Buy」ボタン付きの商品カードとしてレンダリングします。購入者がzapすると、システムはNIP-57を使用して支払いリクエストを生成し、kind 9735 zapレシートをポーリングして支払いを確認し、NIP-17のgift wrappingを使用して配送情報を暗号化してから販売者にプライベートに送信します。この機能はリピート購入のために購入者の詳細をローカルに保存し、フラッシュセールリストを作成するためのマーチャントダッシュボードも含まれています。ソーシャル、決済、プライバシープリミティブの巧みな組み合わせであり、Nostrの組み合わせ可能な設計が新しい商取引パターンを可能にすることを示しています。

Mostroが開発基金を導入 - NIP-69 P2P Bitcoin取引ボットは、持続可能なメンテナンスをサポートするために設定可能な開発手数料を実装しました。運営者はMostro取引手数料の10〜100%のdev_fee_percentageを設定でき（デフォルトは30%）、成功した各取引で自動的に開発基金にルーティングされます。実装は3つのデータベースカラム（dev_fee、dev_fee_paid、dev_fee_payment_hash）を追加して貢献を追跡し、デーモン起動時にパーセンテージを検証します。docs/DEV_FEE.mdの技術ドキュメントでシステムを説明しています。このオプトインモデルにより、運営者は手数料配分の完全な透明性を維持しながら継続的な開発をサポートできます。

NIP更新

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

新しいNIP:

NIP-A4（パブリックメッセージ、kind 24） - 幅広いクライアントサポートのために設計された通知画面メッセージ用の新しいkind (#1988)。スレッド化された会話とは異なり、これらのメッセージにはチャット履歴やメッセージチェーンの概念がありません。スレッディングの複雑さを避けるためにeタグではなくqタグ（引用）を使用し、会話状態を作成することなく受信者の通知フィードに表示されるシンプルな公開通知に最適です。

重要な変更:

NIP-29 - グループセマンティクスの大幅な明確化 (#2106)。closedタグは「書き込み不可」（非メンバーは読み取り専用）を意味するようになり、参加メカニズムから分離されました。新しいhiddenタグは、リレーが非メンバーにメタデータやメンバーイベントを提供することを防ぎ、帯域外の招待なしには発見できない真にプライベートなグループを可能にします。privateタグは、発見のためのパブリックメタデータを許可しながらメッセージの可視性を制御します。
NIP-51 - キュレートされた画像セット用のkind 30006を追加 (#2170)、30004（記事）と30005（動画）のパターンに従います。すでにNostriaで実装されています。
NIP-55 - Android署名アプリの接続開始を明確化 (#2166)。マルチユーザーセッションを実装する開発者が、バックグラウンドプロセスから呼び出すことでget_public_keyを誤用していました。更新された仕様では、初期接続時に1回だけ呼び出すことを推奨し、一般的な実装の落とし穴を防ぎます。

NIP詳細解説: NIP-02とNIP-10

今週は、ソーシャル機能に不可欠な2つのNIPを取り上げます: クライアントがあなたがフォローしている人を知る方法と、会話がどのようにスレッド化されるかです。

NIP-02: フォローリスト

NIP-02はkind 3イベントを定義し、フォローリストを保存します。このシンプルなメカニズムが、タイムラインを可能にするソーシャルグラフを支えています。

構造: kind 3イベントにはフォローしているpubkeyをリストするpタグが含まれます:

{
  "id": "d7a8f...",
  "pubkey": "a3b9c...",
  "created_at": 1734912000,
  "kind": 3,
  "tags": [
    ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
    ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
    ["p", "612ae..982b", "", ""]
  ],
  "content": "",
  "sig": "e4f8a..."
}

各pタグには4つの位置があります: タグ名、フォローしているpubkey（hex）、オプションのリレーURLヒント、オプションの「petname」（ローカルニックネーム）。リレーヒントは他のクライアントにそのユーザーのイベントをどこで見つけるかを伝えます。petnameを使用すると、自己宣言した表示名に頼らずに連絡先に覚えやすい名前を割り当てることができます。

置換可能な動作: Kind 3は置換可能な範囲（0、3、10000-19999）に属するため、リレーはpubkeyごとに最新バージョンのみを保持します。新しい人をフォローすると、クライアントはすべてのフォローと新しいものを含む完全な新しいkind 3を公開します。つまり、フォローリストは毎回完全でなければならず、増分更新を公開することはできません。

タイムラインの構築: ホームフィードを構築するために、クライアントはユーザーのkind 3を取得し、すべてのpタグのpubkeyを抽出し、それらの作成者からのkind 1イベントを購読します:

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

リレーはマッチするノートを返し、クライアントはそれらをレンダリングします。kind 3のリレーヒントは、クライアントがフォローしている各ユーザーに対してどのリレーにクエリするかを知るのに役立ちます。

Petnameとアイデンティティ: petnameフィールドは分散型命名スキームを可能にします。ユーザーがプロフィールで主張する名前を信頼するのではなく、自分自身のラベルを割り当てることができます。クライアントは「alice（私の姉妹）」と表示するかもしれません。ここで「alice」は彼女のkind 0プロフィールから、「私の姉妹」はあなたのpetnameです。これはグローバルなユーザー名では提供できないコンテキストを提供します。

実践的な考慮事項: kind 3イベントは置換可能で完全でなければならないため、クライアントは更新時に不明なタグを保持する必要があります。別のクライアントがあなたのクライアントが理解しないタグを追加した場合、盲目的に上書きするとそのデータが失われます。ゼロから再構築するのではなく、新しいフォローを追加してください。

NIP-10: テキストノートのスレッディング

NIP-10はkind 1ノートが返信スレッドを形成するためにお互いを参照する方法を規定しています。会話ビューを構築するにはこれを理解することが不可欠です。

問題: 誰かがノートに返信するとき、クライアントは知る必要があります: これは何への返信か？会話のルートは何か？誰に通知すべきか？NIP-10はeタグ（イベント参照）とpタグ（pubkeyメンション）を通じてこれらの質問に答えます。

マーク付きタグ（推奨）: 現代のクライアントはeタグで明示的なマーカーを使用します:

{
  "id": "f9c2e...",
  "pubkey": "a3b9c...",
  "created_at": 1734912345,
  "kind": 1,
  "tags": [
    ["e", "abc123...", "wss://relay.example.com", "root"],
    ["e", "def456...", "wss://relay.example.com", "reply"],
    ["p", "91cf9..."],
    ["p", "14aeb..."]
  ],
  "content": "素晴らしいポイント！同意します。",
  "sig": "b7d3f..."
}

rootマーカーはスレッドを開始した元のノートを指します。replyマーカーは回答している特定のノートを指します。ルートに直接返信する場合は、rootのみを使用します（replyタグは不要）。この区別はレンダリングに重要です: replyはスレッドビューでのインデントを決定し、rootはすべての返信をグループ化します。

スレッディングルール:

ルートへの直接返信: rootマーカー付きの1つのeタグ
返信への返信: 2つのeタグ、1つはroot、1つはreply
rootはスレッド全体で一定のまま。replyは返信先に応じて変わる

通知用のPubkeyタグ: 通知されるべき全員のpタグを含めます。最低限、返信しているノートの作成者をタグ付けします。慣例として、親イベントからのすべてのpタグも含めます（会話の全員がループに留まるように）、さらにコンテンツで@メンションしたユーザーも含めます。

リレーヒント: eおよびpタグの3番目の位置には、そのイベントまたはユーザーのコンテンツが見つかる可能性のあるリレーURLを含めることができます。これにより、クライアントは元のリレーに接続していなくても参照されているコンテンツを取得できます。

非推奨の位置タグ: 初期のNostr実装では、マーカーではなくタグの位置から意味を推論していました: 最初のeタグがルート、最後がリプライ、中間がメンション。このアプローチは曖昧さを生むため非推奨です。マーカーのないeタグを見た場合、おそらく古いクライアントからのものです。現代の実装は常に明示的なマーカーを使用すべきです。

スレッドビューの構築: スレッドを表示するには、ルートイベントを取得し、そのルートを参照するeタグを持つすべてのイベントをクエリします:

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

結果をcreated_atでソートし、replyマーカーを使用してツリー構造を構築します。replyがルートを指すイベントはトップレベルの返信です。replyが別の返信を指すイベントはネストされた応答です。

リリース

Zeus v0.12.0 - 先週のNWC並列支払いサポートに続き、Lightningウォレットのメジャーリリースは、カスタムリレーサポートとバジェット追跡を備えた完全なNIP-47 Nostr Wallet Connectサービスを搭載。バジェットリロードの修正により接続が現在の制限を使用することを保証。Lightningアドレスのコピーはlightning:プレフィックスを含まなくなり、Nostrプロフィールフィールドでのペーストの問題を修正。

Amber v4.0.6 - Android NIP-55署名アプリは署名操作にパフォーマンスキャッシュを追加し、不正なコンテンツの復号時のエラー処理を改善。リレー接続イベントのリトライロジックにより接続の信頼性が向上し、無効なnostrconnect:// URIと権限画面のインタラクションに関するいくつかのクラッシュ修正が行われました。

nak v0.17.3 - コマンドラインNostrツールの最新リリースはLMDBビルドをLinuxに制限し、クロスプラットフォームのコンパイル問題を修正。

Aegis v0.3.4 - クロスプラットフォームNostr署名アプリはNIP-55で定義されたnostrsigner: URIスキームのサポートを追加し、Amberの接続フローに対応。ローカルリレーデータはバックアップ用にインポートおよびエクスポートが可能になり、リレーソケットエラーのバグ修正とローカルリレーインターフェースのUI改善が含まれています。

注目のコードとドキュメントの変更

これらはオープンプルリクエストと初期段階の作業であり、マージ前にフィードバックを得るのに最適です。気になるものがあれば、レビューやコメントを検討してください！

Damus (iOS)

ミュートリストの永続化はコールドスタート時にミュートリストがワイプされる問題を修正。修正により、アプリ初期化中の偶発的な上書きを防ぐガードを追加。プロフィールストリームのタイミングは、キャッシュされたプロフィールが表示されるまでの約1秒の遅延を排除。以前はビューが購読タスクの再開を待っていましたが、streamProfile()がNostrDBからキャッシュされたデータをすぐに返すようになり、省略されたpubkeyとプレースホルダー画像が表示されるウィンドウがなくなりました。

White Noise (暗号化メッセージング)

リアルタイムメッセージストリーミングは、以前のポーリングメカニズムをストリームベースのアーキテクチャに置き換えます。新しいChatStreamNotifierはRust SDKのメッセージストリームを直接消費し、時系列順を維持しながら増分更新を効率的に処理します。テストでは応答性の大幅な改善が示されました。チャットリストAPIは会話サマリーを取得するためのget_chat_listを追加し、安定ソートの修正はメッセージIDをタイブレーカーとしてcreatedAtを使用することでメッセージの並べ替えループを防ぎます。

NDK (ライブラリ)

2つのプルリクエストが劇的なキャッシュパフォーマンスの改善をもたらしました。PR #371はSQLiteキャッシュから読み取ったイベントがすぐに書き戻されるバグを修正し、アプリ起動時に100%の重複書き込みを引き起こしていました。修正はfromCacheガードを追加し、メモリ内Setを介したO(1)重複チェックを実装。小さな結果セット（<100イベント）では、バイナリエンコーディングのオーバーヘッドの代わりに直接JSONトランスファーを使用。PR #372はキャッシュされたイベントに対する不要なseenEvent呼び出しを削除。LRUキャッシュルックアップはイベントあたり0.24-0.64msのコストがかかり、5,700のキャッシュイベントで約1.4秒のオーバーヘッドが追加されていました。結果: キャッシュクエリが約3,690msから約22msに短縮（162倍高速化）。

rust-nostr (ライブラリ)

マルチフィルターREQサポートが以前のリファクタリングで削除された後に復元されました。SDKは購読リクエストにVec<Filter>を再び受け入れ、ORロジックで複数のフィルター条件を組み合わせる効率的なクエリを可能にします。リレー出所がstream_events*メソッドに追加され、各ストリーミングイベントには元のRelayUrlと成功または失敗を示すResultが含まれるようになり、リレーの信頼性の追跡と接続問題のデバッグに役立ちます。セキュリティ修正はRUSTSEC-2024-0421に続いてurl-fork依存関係を削除し、既知の脆弱性を排除しました。

Applesauce (ライブラリ)

noStrudelを支えるTypeScriptライブラリは今週大幅な開発が行われました。新しいモデルにはリアクションシステムとユーザーグループキャスティングが含まれます。ウォレット機能はNIP-60サポート、送信タブ、改善されたトークン回復ツールで拡張されました。新しいuser.directMessageRelays$プロパティがDMリレー設定を公開。すべてのアクションは非同期インターフェースを使用するようにリファクタリングされ（非同期ジェネレーターを削除）、バグ修正で暗号化コンテンツの復元と時間ベースのイベントフィルターのエッジケースに対処しました。

Tenex (AIエージェント)

Nostr上に構築されたマルチエージェント調整システムは5つのマージされたPRでRAL（Request-Action-Lifecycle）アーキテクチャを導入しました。RALにより、エージェントはタスクを委任するときに一時停止し、結果が到着したときに再開でき、会話スコープの状態永続化を備えています。委任ツール（delegate、ask、delegate_followup、delegate_external）はブロッキングではなくNostrイベントを公開して停止シグナルを返すようになりました。リファクタリングにはAI SDK v6マイグレーション、決定論的LLMインタラクション記録のためのVCRテストインフラストラクチャ、マルチモーダル画像サポートが含まれています。

今週は以上です。何かを構築していますか？共有したいニュースがありますか？プロジェクトを取り上げてほしいですか？NIP-17 DMでお問い合わせください。またはNostrで見つけてください。