69 lines
2.7 KiB
Markdown
69 lines
2.7 KiB
Markdown
|
# Web5 & Nostr Node Identity
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
Archipelago establishes node identity using **did:key** (W3C) from the persistent Ed25519 key. This enables Web5/DID interoperability and provides an extensible foundation for Nostr discovery.
|
||
|
|
|
||
|
|
## DID/Web5 Integration
|
||
|
|
|
||
|
|
### Current Implementation
|
||
|
|
|
||
|
|
- **Node identity**: Persistent Ed25519 key in `/var/lib/archipelago/identity/`
|
||
|
|
- **DID format**: `did:key:z<base58btc(multicodec_ed25519_pub + 32-byte pubkey)>`
|
||
|
|
- **RPC**: `node.did` returns `{ did, pubkey }` for the node
|
||
|
|
- **Onboarding**: DID generation is wired to the backend during onboarding; the node's DID is established at first boot
|
||
|
|
|
||
|
|
### TBD Web5 Protocols
|
||
|
|
|
||
|
|
The node identity is compatible with TBD Web5:
|
||
|
|
|
||
|
|
- **did:key** is supported by `@web5/dids` and `@tbd54566975/web5`
|
||
|
|
- **DWN integration**: Future apps (web5-dwn, did-wallet) can resolve our DID for data exchange
|
||
|
|
- **Node address**: `archipelago://<onion>#<pubkey>` format for peer discovery
|
||
|
|
|
||
|
|
### Extensibility
|
||
|
|
|
||
|
|
1. **DID Document**: Could add a DID document endpoint for full Web5 resolution
|
||
|
|
2. **DWN protocols**: Define custom protocols for node-to-node sync (e.g. peer list, backup)
|
||
|
|
3. **did:dht**: Migrate to did:dht for DHT-based resolution if needed
|
||
|
|
|
||
|
|
## Nostr Integration
|
||
|
|
|
||
|
|
### Recommended Approach
|
||
|
|
|
||
|
|
**NIP-33 Replaceable Events** (kind 30078) for Archipelago node discovery:
|
||
|
|
|
||
|
|
```
|
||
|
|
{
|
||
|
|
"kind": 30078,
|
||
|
|
"pubkey": "<nostr_secp256k1_pubkey>",
|
||
|
|
"content": JSON.stringify({
|
||
|
|
"did": "did:key:z6Mk...",
|
||
|
|
"node_address": "archipelago://xxx.onion#pubkey",
|
||
|
|
"version": "0.1.0"
|
||
|
|
}),
|
||
|
|
"tags": [["d", "archipelago-node"]]
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
### Implementation Plan
|
||
|
|
|
||
|
|
1. **Nostr keypair**: Generate and persist secp256k1 key in `/var/lib/archipelago/identity/nostr_key` (Nostr uses secp256k1, not Ed25519)
|
||
|
|
2. **Publish on startup**: After identity load, publish replaceable event to default relays (e.g. wss://relay.damus.io, wss://relay.nostr.info)
|
||
|
|
3. **Discovery**: Other nodes query relays for `{"kinds": [30078], "#d": ["archipelago-node"]}` to find peers
|
||
|
|
4. **RPC**: `node.nostr-publish` to manually re-publish; `node.nostr-pubkey` to get our Nostr pubkey for following
|
||
|
|
|
||
|
|
### Why Separate Keys?
|
||
|
|
|
||
|
|
- **Ed25519** (did:key): Web5, DWN, VC signing
|
||
|
|
- **secp256k1** (Nostr): Nostr protocol requirement; bridges to Nostr ecosystem
|
||
|
|
|
||
|
|
The DID remains the canonical identity; Nostr pubkey is a discovery/signaling channel.
|
||
|
|
|
||
|
|
## Onboarding Flow
|
||
|
|
|
||
|
|
1. **Intro** → **Path** → **DID** (fetches `node.did` from backend) → **Backup** → **Verify** → **Login**
|
||
|
|
2. Onboarding completion is persisted to backend (`auth.onboardingComplete` → `onboarding.json`)
|
||
|
|
3. Returning users skip onboarding and go directly to login
|
||
|
|
4. State is server-side; no reliance on browser localStorage for completion status
|