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.
This commit is contained in:
Dorian
42
docs/SECURITY-NOSTR-DISCOVERY.md
Normal file
42
docs/SECURITY-NOSTR-DISCOVERY.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# Nostr Discovery – Security & Data Exposure
|
||||
|
||||
## If Someone Saw the Published Data
|
||||
|
||||
The Nostr discovery feature previously published node identity (DID, Tor onion address, version) to public relays. If someone saw that data, here’s what they could have and how to respond.
|
||||
|
||||
### What Could Have Been Seen
|
||||
|
||||
1. **Relay operators** (relay.damus.io, relay.nostr.info):
|
||||
- Your server’s **IP address** when it connected to publish
|
||||
- The **Tor onion address** you advertised
|
||||
- **Timing** of when you published
|
||||
|
||||
2. **Anyone querying Nostr** for archipelago nodes:
|
||||
- Your **Tor onion address** (designed to be shareable)
|
||||
- Your **DID** (public identifier)
|
||||
- **Software version**
|
||||
|
||||
### Mitigations
|
||||
|
||||
| Exposure | Mitigation |
|
||||
|----------|------------|
|
||||
| **IP address** | Cannot be undone. If relay operators logged it, they still have it. Consider: moving to a new IP, using a VPN for future traffic, or treating the server as potentially identified. |
|
||||
| **Tor onion** | The revocation overwrites the Nostr event so new clients won’t see it. If someone cached the onion, they can still reach the node. To invalidate it: **rotate the Tor hidden service** (new onion, old one stops working). |
|
||||
| **DID** | Public by design; no mitigation needed. |
|
||||
| **Version** | Update to a newer version; old version info becomes less useful over time. |
|
||||
|
||||
### Rotating the Tor Hidden Service (New Onion)
|
||||
|
||||
To invalidate an exposed onion address:
|
||||
|
||||
1. Stop the Tor container.
|
||||
2. Remove the hidden service directory:
|
||||
`rm -rf /var/lib/archipelago/tor/hidden_service_archipelago`
|
||||
3. Restart the Tor container so it creates a new onion.
|
||||
4. Update any peers or links that used the old onion.
|
||||
|
||||
### Current Protections (Post-Fix)
|
||||
|
||||
- **Revocation**: On startup, the backend publishes a replacement Nostr event with empty content, so normal discovery no longer shows your node.
|
||||
- **Tor proxy**: Nostr traffic uses Tor (127.0.0.1:9050) so relay operators no longer see your IP.
|
||||
- **Opt-in defaults**: Discovery is on by default but only uses configured relays and routes through Tor.
|
||||
68
docs/WEB5_NOSTR_IDENTITY.md
Normal file
68
docs/WEB5_NOSTR_IDENTITY.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user