lfg2025/archy

Dorian 1073d9fd2c Update Fedimint configuration and enhance onboarding process

- Upgraded Fedimint version to v0.10.0 in docker-compose.yml and manifest.yml, adding support for the built-in Guardian UI.
- Modified .gitignore to exclude deploy-config.sh script.
- Enhanced onboarding process in AuthManager to persist onboarding state and validate password strength during user setup.
- Updated API to handle onboarding completion and password change requests, ensuring a smoother user experience.
- Improved configuration management to support Nostr discovery and Tor proxy settings, enhancing node identity features.

2026-02-17 15:03:34 +00:00

2.7 KiB

Raw Blame History

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

DID Document: Could add a DID document endpoint for full Web5 resolution
DWN protocols: Define custom protocols for node-to-node sync (e.g. peer list, backup)
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

Nostr keypair: Generate and persist secp256k1 key in /var/lib/archipelago/identity/nostr_key (Nostr uses secp256k1, not Ed25519)
Publish on startup: After identity load, publish replaceable event to default relays (e.g. wss://relay.damus.io, wss://relay.nostr.info)
Discovery: Other nodes query relays for {"kinds": [30078], "#d": ["archipelago-node"]} to find peers
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

Intro → Path → DID (fetches node.did from backend) → Backup → Verify → Login
Onboarding completion is persisted to backend (auth.onboardingComplete → onboarding.json)
Returning users skip onboarding and go directly to login
State is server-side; no reliance on browser localStorage for completion status

2.7 KiB Raw Blame History