laantungir/n_signer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 40 Wiki Activity
Files
d28f691aae38321a7e821300532d0b5c0d94fc52
n_signer/plans/nip46_bunker_mode.md

3.8 KiB
Raw Blame History

Plan: Deferred NIP-46 bunker transport mode

Status: deferred (design only, not in current implementation scope)

This document records a future transport mode where n_signer can operate as a NIP-46-compatible bunker over relays, while keeping the current local/TCP framed JSON-RPC path intact.

Current implementation priority remains plans/caller_token_identity.md: required per-request caller authentication for TCP/URL using signed auth envelopes and existing n_signer request flow.

1. Why this is deferred

NIP-46 adds more than caller authentication:

  • Relay session lifecycle and routing
  • NIP-44 encrypted request/response payloads
  • connect ceremony and secret verification
  • Signer service identity (remote-signer-pubkey) management
  • Compatibility behavior for nostrconnect:// and bunker://

That is a separate subsystem from the immediate bugfix (stable, authenticated caller identity over TCP reconnects). Combining both now would increase risk and delay rollout.

2. Future objective

Add an optional mode (example: --listen nip46) that accepts NIP-46 kind:24133 requests and returns NIP-46 kind:24133 responses as defined in resources/nips/46.md.

This mode should:

  1. Authenticate client requests using NIP-46 client keypairs and encrypted content.
  2. Map NIP-46 caller identity to the same deny-by-default approval model already used by current transports.
  3. Reuse existing dispatcher/enforcement/policy machinery after transport decoding.

3. Compatibility stance (future)

  • Keep current framed JSON-RPC transports (AF_UNIX, qrexec, tcp) as first-class for local deployments.
  • Add NIP-46 as additional transport, not replacement.
  • Shared internal core: once a request is decoded into (caller_id, method, params, selector), the same policy and enforcement pipeline runs.

4. Planned phases

Phase A — Transport shell

  • Add nip46 listen mode and relay I/O loop.
  • Parse and validate incoming kind:24133 envelope.
  • Decrypt NIP-44 payload and extract JSON-RPC-like method + params.

Phase B — Identity + approval binding

  • Derive caller identity from NIP-46 client-pubkey.
  • Represent as caller_id = pubkey:<hex> to align with the current TCP auth direction in plans/caller_token_identity.md.
  • Route to existing policy checks and prompt behavior.

Phase C — Response path

  • Convert dispatcher results into NIP-46 response payloads.
  • Encrypt via NIP-44 and emit kind:24133 response event.
  • Preserve request id correlation and error mapping.

Phase D — Connect / secret / perms polish

  • Implement full connect handshake semantics from resources/nips/46.md.
  • Validate optional secret behavior.
  • Support requested permissions metadata and signer-side policy translation.

Phase E — Operational hardening

  • Relay switching behavior (switch_relays), lifecycle recovery.
  • Rate limits and replay protections specific to relay transport.
  • Audit/event logs for NIP-46 connections and requests.

5. Open design questions (for later)

  1. Should NIP-46 mode require a dedicated signer identity key, or may it reuse the user signing identity?
  2. How should connect permissions map to n_signer role/selector approvals?
  3. Should NIP-46 callers and TCP-auth callers share the same pubkey:<hex> approval namespace by default?
  4. Do we support both relay-initiated and direct-client initiation flows from day one?
  5. What minimum relay trust assumptions are required in documents/SECURITY.md?

6. Out of scope for current code work

The current implementation task does not include:

  • Adding relay networking
  • NIP-44 tunnel encryption for requests
  • NIP-46 connect handshake
  • nostrconnect:// URI flow

Those remain deferred to this plan.