NIP-46は、Nostr relays越しのremote signingを定義します。clientは、一般にbunkerと呼ばれる別のsignerと通信するため、署名鍵をユーザーが今使っているappの外側へ置いておけます。

仕組み

  1. clientは、bunker session専用のローカルkeypairを生成します。
  2. 接続はbunker://またはnostrconnect:// URIで確立されます。
  3. clientとsignerは、relay上で暗号化されたkind 24133のrequestとresponse eventを交換します。
  4. 接続後、clientはget_public_keyを呼んで、実際に署名対象となるユーザーpubkeyを取得します。

接続方法

  • bunker:// - signer主導の接続
  • nostrconnect:// - QR codeまたはdeep linkによるclient主導の接続

nostrconnect://のflowには、共有secretが必須です。これによりclientは、最初のresponseが本当に意図したsignerから来たものかを検証でき、単純な接続spoofingを防げます。

対応操作

  • sign_event - 任意のイベントへ署名する
  • get_public_key - signerからユーザーpubkeyを取得する
  • nip04_encrypt/decrypt - NIP-04暗号化操作
  • nip44_encrypt/decrypt - NIP-44暗号化操作
  • switch_relays - 更新されたrelay setをsignerへ求める

多くの実装は、セットアップ時にsign_event:1やnip44_encryptのようなpermission stringも使い、全面的なアクセスではなく狭いscopeだけをsignerが承認できるようにしています。

Relayと信頼モデル

NIP-46は秘密鍵をclientの外へ移しますが、signerへの信頼自体を消すわけではありません。signerはrequestを承認、拒否、遅延できますし、clientが依頼するすべての操作を見ます。relay選択も重要で、プロトコルはrequestとresponseを両者が到達できるrelay上で配信できることに依存します。

switch_relays methodがあるのは、signerが時間とともにsessionを別のrelay setへ移せるようにするためです。これを無視するclientは、signer側のrelay設定が変わったとき信頼性が落ちます。

Primary sources:

Mentioned in:

See also: