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
7.5 KiB
Options non implémentées - Analyse d'intérêt
Author: Équipe 4NK
Date: 2026-01-28
1. Merkle trees (optionnel)
Description
Checkpointing / accélération de scan pour optimiser la synchronisation à grande échelle.
Intérêt
Avantages potentiels :
- Performance : Réduction significative du nombre de requêtes nécessaires pour synchroniser de grandes quantités de données
- Scalabilité : Permet de gérer des volumes importants (millions de messages) sans dégradation de performance
- Efficacité réseau : Réduction de la bande passante utilisée lors des synchronisations
- Checkpointing : Possibilité de reprendre une synchronisation depuis un point précis sans tout re-scanner
Cas d'usage :
- Services avec un très grand nombre de messages (millions)
- Synchronisations fréquentes sur de grandes fenêtres temporelles
- Réseaux avec bande passante limitée
- Besoin de synchronisation incrémentale efficace
Inconvénients / Complexité
Complexité technique :
- Implémentation complexe (construction d'arbres de Merkle, gestion des segments)
- Nécessite une coordination entre client et serveur (relais doit supporter Merkle)
- Gestion des conflits et des branches d'arbres
- Maintenance et debugging plus difficiles
Coût de développement :
- Temps de développement important
- Tests complexes (volumes importants, cas limites)
- Documentation et formation nécessaires
Alternatives existantes :
- Bloom filter : Déjà implémenté, réduit efficacement les requêtes inutiles
- Hash cache : Déjà implémenté, évite de traiter les messages déjà vus
- Fenêtre de scan configurable : Permet de limiter la portée des synchronisations
Recommandation
Intérêt : MOYEN à FAIBLE
Raisons :
- Bloom filter suffisant : Le Bloom filter déjà implémenté couvre la majorité des cas d'usage d'optimisation
- Complexité vs bénéfice : La complexité d'implémentation est élevée pour un gain marginal dans la plupart des cas
- Volumes actuels : Les volumes de données actuels ne justifient pas nécessairement cette optimisation
- Dépendance serveur : Nécessite une modification des relais pour supporter Merkle, ce qui limite l'adoption
Quand l'implémenter :
- Si les volumes de messages deviennent très importants (millions+)
- Si les synchronisations deviennent un goulot d'étranglement mesurable
- Si le Bloom filter ne suffit plus pour optimiser les requêtes
- Si les relais sont prêts à supporter Merkle
Conclusion : Optionnel, à considérer uniquement si un besoin réel de performance à grande échelle est identifié et mesuré.
2. Évolutions futures api-relay (optionnel)
Description
Plusieurs évolutions possibles pour api-relay : base de données, authentification, WebSocket, compression, etc.
Analyse par évolution
2.1 Base de données (SQLite, PostgreSQL)
Intérêt : ÉLEVÉ
Avantages :
- Persistance fiable : Données persistées de manière fiable, pas de perte en cas de redémarrage
- Performance : Requêtes optimisées, indexation efficace
- Scalabilité : Gestion de volumes importants
- Transactions : Garanties ACID pour la cohérence des données
- Maintenance : Outils de backup, monitoring, maintenance standardisés
Inconvénients :
- Configuration et déploiement plus complexes
- Nécessite une migration depuis le stockage en mémoire actuel
Recommandation : À implémenter en production. Le stockage en mémoire actuel est suffisant pour le développement mais pas pour la production.
2.2 Authentification pour endpoints POST
Intérêt : MOYEN
Avantages :
- Sécurité : Protection contre les abus (spam, DoS)
- Traçabilité : Identification des sources de messages
- Contrôle d'accès : Limitation à des clients autorisés
Inconvénients :
- Complexité de gestion des clés/tokens
- Nécessite une infrastructure d'authentification
- Peut limiter la décentralisation (nécessite une autorité pour émettre les tokens)
Recommandation : Optionnel. Utile si des problèmes d'abus sont identifiés. Le modèle actuel (pull-only, déduplication par hash) offre déjà une certaine protection.
2.3 Compression des messages stockés
Intérêt : FAIBLE
Avantages :
- Réduction de l'espace disque
- Réduction de la bande passante réseau
Inconvénients :
- CPU supplémentaire pour compression/décompression
- Complexité de gestion (format, version)
- Les messages sont déjà relativement petits (JSON)
Recommendation : Non prioritaire. Les messages sont déjà compacts (JSON). La compression n'apporterait qu'un gain marginal.
2.4 Indexation avancée (service UUID, type UUID)
Intérêt : MOYEN
Avantages :
- Requêtes plus rapides pour des filtres spécifiques
- Meilleure performance sur de gros volumes
Inconvénients :
- Complexité de gestion des index
- Maintenance supplémentaire
Recommandation : Optionnel. L'indexation par service_uuid est déjà partiellement implémentée. À améliorer si les volumes augmentent.
2.5 WebSocket pour notifications en temps réel
Intérêt : FAIBLE à MOYEN
Avantages :
- Notifications en temps réel (push)
- Réduction de la latence
- Meilleure expérience utilisateur
Inconvénients :
- Contradiction avec le modèle pull-only : Le modèle actuel est volontairement pull-only pour la décentralisation
- Complexité de gestion des connexions WebSocket
- Nécessite une infrastructure serveur plus complexe
- Peut compromettre la décentralisation (dépendance au serveur)
Recommandation : Non recommandé. Contredit le principe de décentralisation et le modèle pull-only. Le polling actuel est suffisant et plus robuste.
2.6 Métriques Prometheus
Intérêt : ÉLEVÉ
Avantages :
- Monitoring et observabilité
- Détection proactive des problèmes
- Métriques de performance
Inconvénients :
- Configuration supplémentaire
- Infrastructure de monitoring nécessaire
Recommandation : À implémenter en production. Déjà partiellement implémenté (GET /metrics). À compléter selon les besoins de monitoring.
2.7 Logging structuré (Winston, Pino)
Intérêt : ÉLEVÉ
Avantages :
- Meilleure traçabilité
- Analyse des logs facilitée
- Debugging plus efficace
Inconvénients :
- Configuration supplémentaire
- Gestion des logs (rotation, stockage)
Recommandation : Déjà implémenté. Pino est déjà utilisé dans api-relay. À maintenir et améliorer si nécessaire.
Synthèse
À implémenter en priorité
- Base de données (SQLite/PostgreSQL) - Production
- Métriques Prometheus - Compléter l'implémentation existante
Optionnel selon besoins
- Authentification POST - Si problèmes d'abus
- Indexation avancée - Si volumes importants
Non recommandé
- Compression - Gain marginal
- WebSocket - Contredit le modèle pull-only décentralisé
Déjà en place
- Logging structuré - Pino déjà implémenté
- Rate limiting - Déjà implémenté
- CORS - Déjà implémenté
- Bloom filter - Déjà implémenté
Conclusion
Les évolutions les plus pertinentes pour api-relay sont :
- Base de données : Nécessaire pour la production
- Métriques : Utile pour le monitoring
Les autres évolutions sont optionnelles et dépendent des besoins spécifiques identifiés en production.