anchorage_layer_simple/RESTE_A_FAIRE.md
ncantu f27345e0ba RESTE_A_FAIRE, relay validation, verify proof structure, UserWallet diagnostic/sync
**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
2026-01-28 01:37:16 +01:00

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 :

  • userwallet
  • service-login-verify
  • api-relay
  • website-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 onProgress dans runCollectLoop
  • 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 longs
  • max-lines-per-function : fonctions trop longues
  • complexity : complexité cyclomatique élevée
  • max-params : trop de paramètres
  • no-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

  1. userwallet : Validation des écrans login (1.1)
  2. userwallet : Notifications relais - événements push (1.2)

Priorité Moyenne

  1. userwallet : Écran "synchronisation continue par service" (1.4)
  2. userwallet : Validation stricte CNIL (1.6)
  3. userwallet : Corrections ESLint (1.7)

Priorité Basse (Optionnel)

  1. userwallet : Merkle trees (1.3)
  2. userwallet : Écran "paramètres crypto (avancé)" (1.5)
  3. service-login-verify : Persistance du NonceCache (2.1)
  4. 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.md
  • features/userwallet-ecrans-login-a-valider.md
  • features/userwallet-champs-obligatoires-cnil.md
  • features/userwallet-eslint-fix.md
  • features/service-login-verify.md
  • userwallet/docs/specs.md
  • userwallet/features/api-relay.md