99 lines
3.8 KiB
Markdown
99 lines
3.8 KiB
Markdown
# 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`](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`](../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`](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`](../resources/nips/46.md:100).
|
|
- 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.
|