cad73cb265
**Motivations:** - Ajouter dates manquantes dans hash_list.txt et compléter historique - Compléter blockTime manquants dans utxo_list.txt et compléter historique - Récupérer frais depuis transactions d'ancrage (OP_RETURN) et les stocker - Bouton UI pour déclencher récupération frais - Diagnostic Bloc Rewards (pourquoi ~4700 BTC au lieu de 50 BTC) **Root causes:** - hash_list.txt sans date (format ancien) - utxo_list.txt blockTime souvent vide - Frais absents du fichier (métadonnées OP_RETURN non stockées) - Pas de moyen de récupérer/compléter frais depuis UI **Correctifs:** - hash_list.txt : format étendu avec date (rétrocompatible) - utxo_list.txt : blockTime complété automatiquement lors écritures - fees_list.txt : nouveau fichier pour stocker frais - updateFeesFromAnchors() : récupère frais depuis OP_RETURN ancrages - Endpoint /api/utxo/fees/update pour déclencher récupération - Bouton "Récupérer les frais depuis les ancrages" dans section Frais (spinner) - Scripts batch : complete-hash-list-dates.js, complete-utxo-list-blocktime.js - Script diagnostic : diagnose-bloc-rewards.js (subsidy, coinbase, listunspent) **Evolutions:** - Frais chargés depuis fees_list.txt dans getUtxoList - Complétion automatique dates/blockTime lors écritures futures **Pages affectées:** - signet-dashboard/src/bitcoin-rpc.js - signet-dashboard/src/server.js - signet-dashboard/public/utxo-list.html - scripts/complete-hash-list-dates.js - scripts/complete-utxo-list-blocktime.js - scripts/diagnose-bloc-rewards.js - features/utxo-list-fees-update-and-historical-completion.md
117 lines
6.0 KiB
Markdown
117 lines
6.0 KiB
Markdown
# Synthèse structurée – UserWallet & API Relay
|
||
|
||
**Author:** Équipe 4NK
|
||
**Date:** 2026-01-26
|
||
|
||
## 1. userwallet/docs
|
||
|
||
### ports.md
|
||
|
||
- **UserWallet (Vite)** : port **3018** (`vite.config.ts`).
|
||
- **api-relay (Express)** : port **3019** (ou `PORT`), défaut 3019 dans `index.ts`. Le README api-relay indique 3019.
|
||
- **Ports à éviter** : 3007, 8080, 3015–3017.
|
||
|
||
### specs.md
|
||
|
||
Spécification du login décentralisé (secp256k1, contrats, pairing mFA, relais) :
|
||
|
||
- **Modèle** : messages publiés sans signatures ni clés ; signatures et clés publiées séparément ; tout adressé par hash canonique ; récupération par **GET uniquement** (pull).
|
||
- **Objets** : Service, Contrat, Champ, Action, ActionLogin, Membre, Pair, MessageBase, Hash, Signature, Validateurs, MsgChiffre, MsgSignature, MsgCle.
|
||
- **Graphe** : Service → Contrat → Champ → Action(login) → Membre → Pair ; contraintes « au moins 1 parent ».
|
||
- **Pairing** : UUID pair ↔ mots BIP32 ; pairing **obligatoire** pour login.
|
||
- **Écrans** : accueil, création/import identité, relais, pairing, sync, services, chemin login, challenge, signatures mFA, publication, résultat.
|
||
- **Machine à états** : S_INIT → S_HOME, S_SYNC_GLOBAL, S_PAIR_*, S_LOGIN_*, etc., avec erreurs récupérables / fatales.
|
||
|
||
### storage.md
|
||
|
||
- **Relais** : stockage hybride (mémoire + `./data/messages.json`). Messages + `seenHashes` persistés ; **signatures et clés non persistées** (perdues au redémarrage).
|
||
- **Front** : LocalStorage (`userwallet_identity`, `userwallet_relays`, `userwallet_pairs`, `userwallet_hash_cache`, plus legacy `userwallet_keypair`, `userwallet_services`). Graphe en mémoire uniquement (`GraphResolver`).
|
||
|
||
---
|
||
|
||
## 2. userwallet/ (frontend)
|
||
|
||
### Stack
|
||
|
||
- React 18, React Router, Vite, TypeScript.
|
||
- Crypto : `@noble/secp256k1`, `@noble/hashes`.
|
||
- Pas de state global (hooks + services).
|
||
|
||
### Structure
|
||
|
||
- **/components** : Home, CreateIdentity, ImportIdentity, Login, PairManagement, RelaySettings, Sync, ServiceList, ErrorDisplay, etc.
|
||
- **/hooks** : useIdentity, useChannel, useErrorHandler, useServices, etc.
|
||
- **/services** : GraphResolver, LoginBuilder, SyncService.
|
||
- **/utils** : relay, storage, identity, crypto, canonical, encryption, verification, cache, bip32, pairing, iframeChannel, etc.
|
||
- **/types** : identity, message, contract, auth, etc.
|
||
|
||
### Points notables
|
||
|
||
- **Identité** : création (secp256k1), import (dérivation clé publique depuis clé privée hex ; mnemonic/seed non supportés).
|
||
- **Relais** : config dans LocalStorage, test `/health`, GET/POST messages/signatures/keys via `utils/relay`.
|
||
- **Pairing** : BIP32 UUID ↔ mots, `PairConfig` avec `membres_parents_uuid`, `is_local`, `can_sign`.
|
||
- **Graphe** : GraphResolver avec caches (services, contrats, champs, actions, membres, pairs), `resolveLoginPath`, validation des parents.
|
||
- **Login** : LoginBuilder (challenge, nonce, chiffrement « for all », preuve avec signatures), publication message → signatures → clés.
|
||
- **Sync** : SyncService appelle les relais, HashCache (LocalStorage), déduplication, fetch clés/signatures, vérification hash/signatures/timestamp, mise à jour du graphe.
|
||
- **Iframe** : iframeChannel + useChannel ; messages `auth-request`, `auth-response`, `login-proof`, `service-status`, `error` ; postMessage vers parent avec `'*'`.
|
||
|
||
---
|
||
|
||
## 3. api-relay (backend relais)
|
||
|
||
### Stack
|
||
|
||
- Express, CORS, JSON. TypeScript, tsx en dev.
|
||
- Pas de base de données : mémoire + persistance optionnelle (`./data`).
|
||
|
||
### Structure
|
||
|
||
- **/routes** : messages, signatures, keys, health.
|
||
- **/services** : StorageService, RelayService.
|
||
- **/types** : message (MsgChiffre, MsgSignature, MsgCle, Stored), config.
|
||
|
||
### Endpoints
|
||
|
||
- **GET /health** : `{ status: 'ok', timestamp }`.
|
||
- **GET /messages?start=&end=&service=** : messages dans la fenêtre, optionnellement par service.
|
||
- **POST /messages** : enregistrement + relais.
|
||
- **GET /messages/:hash** : message par hash.
|
||
- **GET/POST /signatures/:hash** et **/signatures** : idem pour signatures.
|
||
- **GET/POST /keys/:hash** et **/keys** : idem pour clés.
|
||
|
||
### Comportement
|
||
|
||
- **Storage** : messages, signatures, keys en mémoire ; `seenHashes` pour déduplication. Persistance : messages + `seenHashes` dans `messages.json` ; signatures et clés non sauvegardées.
|
||
- **Relay** : `PEER_RELAYS` en env ; relais des messages/signatures/clés vers les pairs via POST.
|
||
|
||
### Correctif relais (POST /messages)
|
||
|
||
- Vérifier `alreadySeen = storage.hasSeenHash(msg.hash)` **avant** `storeMessage`.
|
||
- Puis `storage.storeMessage(stored)`.
|
||
- Relayer seulement si `!alreadySeen` : `await relay.relayMessage(msg)` et `stored.relayed = true`.
|
||
|
||
### Autres points
|
||
|
||
- **config.ts** : RelayConfig avec `relay_enabled`, `max_message_age_days`, etc. Non utilisé dans `index.ts` (config réelle : PORT, HOST, STORAGE_PATH, PEER_RELAYS).
|
||
- **README** : port par défaut 3019.
|
||
|
||
---
|
||
|
||
## 4. Liens entre UserWallet et api-relay
|
||
|
||
- UserWallet appelle les endpoints du relais (messages, signatures, keys, health) via `utils/relay`.
|
||
- Types alignés : MsgChiffre, MsgSignature, MsgCle (structure équivalente, noms français).
|
||
- UserWallet utilise `datajson_public` (services_uuid, types_uuid, timestamp, etc.) comme le relais.
|
||
- Ports : front 3018, relais 3019 (voir `ports.md`).
|
||
|
||
---
|
||
|
||
## 5. Synthèse
|
||
|
||
| Élément | userwallet | api-relay |
|
||
|-----------|--------------------------------------------------------------------|----------------------------------------------------------|
|
||
| **Rôle** | Front login décentralisé (secp256k1, contrats, pairing mFA) | Relais stockage + diffusion messages/signatures/clés |
|
||
| **Port** | 3018 | 3019 |
|
||
| **Stockage** | LocalStorage (identité, relais, pairs, hash cache) | Mémoire + JSON (messages, seenHashes) ; sig/keys non persistées |
|
||
| **Specs** | Aligné avec specs.md (graphe, ordre message→sig→clés, pull-only) | Séparation messages / signatures / clés, dédup par hash |
|