# 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