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
222 lines
7.5 KiB
Markdown
222 lines
7.5 KiB
Markdown
# 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 :**
|
|
1. **Bloom filter suffisant** : Le Bloom filter déjà implémenté couvre la majorité des cas d'usage d'optimisation
|
|
2. **Complexité vs bénéfice** : La complexité d'implémentation est élevée pour un gain marginal dans la plupart des cas
|
|
3. **Volumes actuels** : Les volumes de données actuels ne justifient pas nécessairement cette optimisation
|
|
4. **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é
|
|
1. **Base de données** (SQLite/PostgreSQL) - Production
|
|
2. **Métriques Prometheus** - Compléter l'implémentation existante
|
|
|
|
### Optionnel selon besoins
|
|
3. **Authentification POST** - Si problèmes d'abus
|
|
4. **Indexation avancée** - Si volumes importants
|
|
|
|
### Non recommandé
|
|
5. **Compression** - Gain marginal
|
|
6. **WebSocket** - Contredit le modèle pull-only décentralisé
|
|
|
|
### Déjà en place
|
|
7. **Logging structuré** - Pino déjà implémenté
|
|
8. **Rate limiting** - Déjà implémenté
|
|
9. **CORS** - Déjà implémenté
|
|
10. **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.
|