**Motivations:** - Documenter le reste à faire (userwallet, service-login-verify, api-relay, website-skeleton) - Renforcer la validation côté api-relay et service-login-verify - Ajouter écrans diagnostic et sync service, service notifications relais, contrat par défaut **Root causes:** - N/A (évolutions + correctifs ciblés) **Correctifs:** - api-relay: GET /:hash (keys, messages, signatures) rejette hash vide → 400 - service-login-verify: validation structure preuve (challenge.hash, nonce, timestamp, signatures), reason invalid_proof_structure **Evolutions:** - RESTE_A_FAIRE.md: vue d’ensemble et tâches par projet - UserWallet: DiagnosticScreen, ServiceSyncScreen, relayNotificationService (hash events, fetch, decrypt, graph), defaultContract, loginStateMachine, useChannel, loginPublish, LoginScreen, LoginCollectShare - website-skeleton: README étendu **Pages affectées:** - RESTE_A_FAIRE.md - api-relay: keys, messages, signatures - service-login-verify: types, verifyLoginProof - userwallet: App, DiagnosticScreen, LoginCollectShare, LoginScreen, ServiceSyncScreen, useChannel, loginStateMachine, relayNotificationService, defaultContract, loginPublish - website-skeleton: README
7.1 KiB
Reste à faire - Projets UserWallet
Author: Équipe 4NK
Date: 2026-01-28
Vue d'ensemble
Ce document liste les éléments restants à implémenter ou à valider pour les projets :
userwalletservice-login-verifyapi-relaywebsite-skeleton
1. userwallet
1.1 Écrans login (Priorité : Haute - À valider)
Statut : À valider avant implémentation
Référence : features/userwallet-ecrans-login-a-valider.md
Les écrans suivants sont déjà en place mais nécessitent validation et éventuelles améliorations :
- Sélection service / sélection membre
- Construction du chemin login
- Message de login à valider
- Collecte signatures mFA
- Publication
- Vérification locale + résultat
Action requise : Validation des écrans existants et ajustements selon les retours de tests.
1.2 Notifications relais (Priorité : Haute)
Statut : Partiellement implémenté
Référence : features/userwallet-contrat-login-reste-a-faire.md (§ 3.2)
Fait :
- Progression collecte signatures (X/Y) implémentée via
onProgressdansrunCollectLoop - Affichage dans
LoginCollectShare
Reste à faire :
- Réagir à d'autres événements relais si extension (ex. push)
- Hash à fetch pour signatures, contrats, membres, pairs, actions, champs
- Une fois le hash connu : récupération sur le relai des signatures, contrats, membres, pairs, actions, champs
- Les notifications doivent piloter : quel hash fetch, puis fetch signatures/clés et mise à jour du graphe
1.3 Merkle trees (Priorité : Basse - Optionnel)
Statut : Non implémenté (optionnel)
Référence : features/userwallet-contrat-login-reste-a-faire.md (§ 3.6)
Description : Checkpointing / accélération de scan pour optimiser la synchronisation à grande échelle.
Impact : Amélioration de performance pour les volumes importants de données.
1.4 Écran "synchronisation continue par service" (Priorité : Moyenne)
Statut : Non implémenté
Référence : userwallet/docs/specs.md (§ Écran "synchronisation continue par service")
Fonctionnalités attendues :
- Liste services + toggle sync automatique
- Fréquence (min/heure/jour)
- Fenêtre de scan
- Accélérateurs : Bloom filter (taille, faux positifs estimés), Merkle (segments/périodes)
- Bouton "lancer maintenant"
Traitements locaux :
- GET messages depuis dernier checkpoint
- Dédup hash
- Fetch signatures et clés si nécessaire
- Validation graphe et droits
États / erreurs :
- Volume trop important → recommander Bloom/Merkle
- Relais instables → backoff
1.5 Écran "paramètres crypto (avancé)" (Priorité : Basse)
Statut : Non implémenté
Référence : userwallet/docs/specs.md (§ Écran "paramètres crypto (avancé)")
Fonctionnalités attendues :
- Algorithme hash (ex : sha256)
- Canonisation JSON (mode strict)
- Paramètres ECDH (secp256k1)
- Paramètres KDF/symétrique (si exposés)
- Politique anti-rejeu : TTL nonce, fenêtre timestamp
États / erreurs :
- Incompatibilité avec services existants
- Paramètres non supportés par version logicielle
1.6 Validation stricte CNIL (Priorité : Moyenne)
Statut : Non implémentée
Référence : features/userwallet-champs-obligatoires-cnil.md
Description : Validation stricte CNIL (présence des champs lorsque requis) non implémentée ; à prévoir selon politique métier.
Action requise : Définir la politique métier et implémenter la validation.
1.7 Corrections ESLint (Priorité : Moyenne)
Statut : Environ 95 erreurs restantes
Référence : features/userwallet-eslint-fix.md
Types d'erreurs :
max-lines: fichiers trop longsmax-lines-per-function: fonctions trop longuescomplexity: complexité cyclomatique élevéemax-params: trop de paramètresno-non-null-assertion: utilisation de!- Et autres violations
Action requise : Refactoring progressif pour corriger les violations.
2. service-login-verify
2.1 Persistance du NonceCache (Priorité : Basse - Optionnel)
Statut : Actuellement en mémoire uniquement
Référence : features/service-login-verify.md
Description : Le NonceCache actuel est en mémoire avec TTL configurable. Une persistance optionnelle (IndexedDB, Redis, etc.) peut être ajoutée si nécessaire.
Note : L'interface NonceCacheLike permet déjà d'implémenter une version persistante. Le cache en mémoire est suffisant pour la plupart des cas d'usage.
Action requise : Implémenter uniquement si besoin de persistance entre redémarrages du service.
3. api-relay
3.1 Évolutions futures (Priorité : Basse - Optionnel)
Statut : Non implémentées (évolutions futures possibles)
Référence : userwallet/features/api-relay.md
Évolutions mentionnées :
- Base de données : Remplacer le stockage en mémoire par une base de données (SQLite, PostgreSQL)
- Authentification : Ajouter une authentification pour les endpoints POST
- Rate limiting : Limiter le nombre de requêtes par IP (déjà implémenté partiellement)
- Compression : Compresser les messages stockés
- Indexation avancée : Indexer par service UUID, type UUID pour des requêtes plus rapides
- WebSocket : Support WebSocket pour les notifications en temps réel (optionnel, car le modèle est pull-only)
- Métriques : Exposer des métriques (Prometheus, etc.) - déjà implémenté partiellement
- Logging structuré : Utiliser un logger structuré (Winston, Pino, etc.) - déjà implémenté (Pino)
Note : La plupart de ces évolutions sont optionnelles et dépendent des besoins de production.
4. website-skeleton
4.1 Aucun élément manquant identifié
Statut : Complet
Description : Aucun élément spécifique mentionné comme manquant dans la documentation.
Synthèse par priorité
Priorité Haute
- userwallet : Validation des écrans login (1.1)
- userwallet : Notifications relais - événements push (1.2)
Priorité Moyenne
- userwallet : Écran "synchronisation continue par service" (1.4)
- userwallet : Validation stricte CNIL (1.6)
- userwallet : Corrections ESLint (1.7)
Priorité Basse (Optionnel)
- userwallet : Merkle trees (1.3)
- userwallet : Écran "paramètres crypto (avancé)" (1.5)
- service-login-verify : Persistance du NonceCache (2.1)
- api-relay : Évolutions futures (3.1)
Notes importantes
- Les éléments marqués "À valider" nécessitent une validation explicite avant implémentation.
- Les éléments optionnels peuvent être implémentés selon les besoins et contraintes.
- Les corrections ESLint doivent être faites progressivement pour ne pas bloquer le développement.
- La plupart des fonctionnalités de base sont implémentées et fonctionnelles.
Références
features/userwallet-contrat-login-reste-a-faire.mdfeatures/userwallet-ecrans-login-a-valider.mdfeatures/userwallet-champs-obligatoires-cnil.mdfeatures/userwallet-eslint-fix.mdfeatures/service-login-verify.mduserwallet/docs/specs.mduserwallet/features/api-relay.md