# Seed Phrase Use Catalog for n_signer

This document catalogs potential uses of a single memorized BIP-39 seed phrase when mediated through `n_signer` role/purpose/curve controls.

It is intentionally expansive: some entries are immediate, others are future-facing.

## 1. Core idea

A single mnemonic can deterministically derive many key families. `n_signer` treats those as distinct role entries with explicit metadata:

- purpose
- curve
- derivation selector/path
- policy scope

This prevents "same seed means same trust domain" mistakes by separating identities at the policy layer.

## 2. Immediate and near-term domains

### 2.1 Nostr identities (`purpose="nostr"`)

- Curve: `secp256k1`
- Typical shorthand: `nostr_index` -> `m/44'/1237'/<index>'/0/0`
- Uses:
  - main pub identity
  - throwaway anti-correlation identity
  - per-app/per-origin identities
  - delegated service identities for local systems

### 2.2 Bitcoin keys (`purpose="bitcoin"`)

- Curve: `secp256k1`
- Typical path families (examples):
  - BIP44 legacy account trees
  - BIP49 wrapped-segwit
  - BIP84 native segwit
  - BIP86 taproot keypath flows
- Uses:
  - deterministic receive/change branches
  - per-context account segregation
  - deterministic recovery for wallet setups

### 2.3 Lightning-related identity material

- Curve: usually `secp256k1`
- Uses vary by node software and key hierarchy model.
- Practical use with `n_signer` should be constrained to explicit purpose-bound role entries, not shared with general signing identities.

### 2.4 Mesh/service identities (`purpose="fips"` and similar)

- Curve: primarily `secp256k1` in current planning
- Uses:
  - deterministic node identity roots
  - stable key-derived addressing inputs
  - service bootstrapping in reproducible deployments

## 3. Additional potential domains

### 3.1 SSH identity material (`purpose="ssh"`)

- Candidate curves: `ed25519` (primary), potentially others
- Uses:
  - deterministic host/user key regeneration
  - environment-specific SSH key derivation without storing private keys on disk

### 3.2 age-style encryption identities (`purpose="age"`)

- Candidate curves: `x25519` / age-native identity mapping
- Uses:
  - deterministic file encryption identity recovery
  - reproducible offline decryption setups

### 3.3 WireGuard-like transport identities

- Candidate curves: curve25519 family
- Uses:
  - deterministic tunnel identity generation
  - ephemeral/per-peer derivation schemes (policy-gated)

### 3.4 PGP/OpenPGP-like profiles (future)

- Possible but operationally complex due to multipurpose key lifecycles and tooling expectations.
- Better treated as explicit, isolated purpose entries if ever added.

### 3.5 Deterministic password or secret derivation (future)

- Could derive app/site secrets from role-scoped KDF outputs.
- Must never blur boundaries with signing keys; separate purpose namespace and strict export policy required.

### 3.6 API/service auth tokens (future)

- Per-service deterministic auth keys (HMAC or asymmetric challenge keys depending on service model).
- Strongly policy-scoped to avoid accidental cross-service linkage.

## 4. Curve and derivation notes

`n_signer` currently models curve metadata from day one:

- `secp256k1`
- `ed25519`
- `x25519`

Not every purpose should be valid on every curve. Enforcement should be explicit in policy/runtime validation.

## 5. Operational caveats

1. **One seed phrase is one root compromise domain**
   - If the mnemonic is exposed, every derivable domain is exposed.

2. **Purpose isolation is mandatory**
   - Reusing one role across unrelated domains collapses privacy and security boundaries.

3. **Pre-registration requirement matters**
   - Arbitrary ad-hoc `role_path` requests are too permissive; only pre-registered paths should be derivable by clients.

4. **Policy must constrain verbs + purposes + roles**
   - A caller authorized for Nostr signing should not implicitly gain rights for Bitcoin or SSH derivations.

5. **Auditability and naming discipline are crucial**
   - Human-readable role names should clearly encode domain intent to avoid operator mistakes.

## 6. Practical guidance

Recommended baseline for early deployments:

- keep `purpose="nostr"` roles as primary production scope
- add non-Nostr purposes only when a concrete consumer exists
- require explicit approval to register new purpose+path combinations
- test recovery procedures per purpose before relying on them operationally

## 7. Relationship to main docs

- Product behavior contract: [`README.md`](../README.md)
- Implementation sequencing: [`plans/nsigner.md`](nsigner.md)
- Browser integration planning: [`plans/nsigner_browser_extension.md`](nsigner_browser_extension.md)