695aff4f85
**Motivations:** - Migrer api-relay vers base de données SQLite (production) - Ajouter authentification API key pour endpoints POST (protection abus) - PersistentNonceCache pour service-login-verify (IndexedDB/localStorage) - Écran paramètres crypto avancés UserWallet - Documenter options non implémentées (Merkle, évolutions api-relay) **Root causes:** - N/A (évolutions + correctifs) **Correctifs:** - N/A **Evolutions:** - api-relay: DatabaseStorageService (SQLite), StorageAdapter (compatibilité), ApiKeyService (génération/validation), auth middleware (Bearer/X-API-Key), endpoints admin (/admin/api-keys), migration script (migrate-to-db.ts), suppression saveToDisk périodique - service-login-verify: PersistentNonceCache (IndexedDB avec fallback localStorage, TTL, cleanup), export dans index - userwallet: CryptoSettingsScreen (hashAlgorithm, jsonCanonizationStrict, ecdhCurve, nonceTtlMs, timestampWindowMs), modifications LoginScreen, LoginForm, CreateIdentityScreen, ImportIdentityScreen, DataExportImportScreen, PairingDisplayScreen, RelaySettingsScreen, ServiceListScreen, MemberSelectionScreen, GlobalActionBar - features: OPTIONS_NON_IMPLENTEES.md (analyse Merkle trees, évolutions api-relay) **Pages affectées:** - api-relay: package.json, index.ts, middleware/auth.ts, services/database.ts, services/storageAdapter.ts, services/apiKeyService.ts, scripts/migrate-to-db.ts - service-login-verify: persistentNonceCache.ts, index.ts, tsconfig.json, dist/ - userwallet: App, CryptoSettingsScreen, LoginScreen, LoginForm, CreateIdentityScreen, ImportIdentityScreen, DataExportImportScreen, PairingDisplayScreen, RelaySettingsScreen, ServiceListScreen, MemberSelectionScreen, GlobalActionBar - features: OPTIONS_NON_IMPLENTEES.md - data: sync-utxos.log
UserWallet API Relay
Serveur de relais pour le système de login décentralisé UserWallet.
Fonctionnalités
- Stockage des messages chiffrés (sans signatures ni clés)
- Stockage séparé des signatures
- Stockage séparé des clés de déchiffrement
- Relais entre pairs (inter-relay)
- Déduplication par hash
- Endpoints REST pour GET/POST
- Rate limiting (par IP)
- CORS configurable
- Logging structuré (Pino)
- Métriques Prometheus (
GET /metrics) - Compression des réponses (gzip)
- Indexation par
service_uuidpour GET /messages - Bloom filter des hash vus (
GET /bloom)
Installation
npm install
Configuration
Variables d'environnement :
PORT: Port d'écoute (défaut: 3019)HOST: Adresse d'écoute (défaut: 0.0.0.0)STORAGE_PATH: Chemin de stockage (défaut: ./data)PEER_RELAYS: Liste de relais pairs séparés par virgule (ex: http://relay1:3019,http://relay2:3019)SAVE_INTERVAL_SECONDS: Sauvegarde périodique (défaut: 300, 0 = désactivé)BODY_LIMIT: Taille max body JSON (défaut: 1mb)REQUEST_TIMEOUT_MS: Timeout requête HTTP (défaut: 30000)RATE_LIMIT_WINDOW_MS: Fenêtre rate limit (défaut: 60000)RATE_LIMIT_MAX: Requêtes max par fenêtre et par IP (défaut: 200)CORS_ORIGINS: Origines CORS autorisées, séparées par virgule (vide = toutes)LOG_LEVEL: Niveau log Pino (défaut: info, debug en dev)NODE_ENV: production | autre
Développement
npm run dev
Build
npm run build
npm start
Déploiement (systemd)
sudo cp api-relay.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable api-relay
sudo systemctl start api-relay
start.sh build puis lance node dist/index.js.
Endpoints
Health
GET /health- Vérification de santé
Messages
GET /messages?start=<timestamp>&end=<timestamp>&service=<uuid>- Récupérer les messages dans une fenêtre temporellePOST /messages- Publier un message chiffréGET /messages/:hash- Récupérer un message par hash
Signatures
GET /signatures/:hash- Récupérer les signatures pour un messagePOST /signatures- Publier une signature
Clés
GET /keys/:hash- Récupérer les clés de déchiffrement pour un messagePOST /keys- Publier une clé de déchiffrement
Métriques
GET /metrics- Métriques Prometheus (relay_storage_entries par kind)
Bloom
GET /bloom- Bloom filter (JSON) des hash vus. Les clients peuvent l’utiliser pour éviter de demander des messages déjà connus.
Architecture
Le relais respecte la séparation stricte :
- Messages publiés sans signatures ni clés
- Signatures publiées séparément
- Clés publiées séparément
La déduplication par hash évite de relayer deux fois le même message.
Stockage
Stockage en mémoire avec persistance sur disque ({STORAGE_PATH}/messages.json). Sont persistés : messages, seenHashes, signatures, clés. Sauvegarde à l’arrêt (SIGINT/SIGTERM) et périodiquement si SAVE_INTERVAL_SECONDS > 0. En production, une base de données (SQLite, PostgreSQL, etc.) est recommandée.
Documentation
docs/synthese.md: synthèse (rôle, stack, structure, endpoints, config, stockage, déploiement, liens UserWallet).features/api-relay-evolutions.md: évolutions (build ESM, rate limit, CORS, métriques, bloom, etc.).