95 lines
5.7 KiB
Markdown
95 lines
5.7 KiB
Markdown
<!-- file: docs/IDEA_REMINDERS.md -->
|
||
<!-- version: 4 -->
|
||
|
||
# Rappels d’idées
|
||
|
||
Ce document regroupe les améliorations utiles mais non bloquantes pour la clôture de la migration et pour la reprise du développement fonctionnel.
|
||
|
||
## Application desktop
|
||
|
||
- Ajouter une autocomplétion Token lorsque des tables de référence fiables existeront.
|
||
- Ajouter une autocomplétion Pool lorsque des tables de référence fiables existeront.
|
||
- Introduire une pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs.
|
||
- Étudier une résolution configurable du chemin de base utilisé par `kb-store`.
|
||
- Séparer à terme la configuration du logging dans un fichier JSON dédié avec son propre schéma et ses propres profils de logging.
|
||
- Permettre de sélectionner et changer un profil de logging indépendamment du profil applicatif actif, afin que les fenêtres Devnet puissent écrire dans des routes ou fichiers distincts sans changer le profil général de l’application.
|
||
|
||
## Pipeline et PostgreSQL
|
||
|
||
- Dimensionner dynamiquement la concurrence Decode replay en fonction du pool PostgreSQL disponible.
|
||
- Ajouter un retry borné et observable pour les erreurs transitoires de pool PostgreSQL.
|
||
- Conserver dans les résumés des compteurs distincts pour les échecs fonctionnels, les erreurs de traitement ou de stockage, les entrées récupérées après retry et les échecs finaux.
|
||
- Étudier une persistance dédiée des erreurs transitoires qui surviennent avant qu’une ligne de ledger puisse être écrite.
|
||
|
||
## Documentation et outils
|
||
|
||
- Refaire les scripts Python d’audit après stabilisation définitive de la structure, des targets et de la nomenclature.
|
||
- Maintenir un inventaire des IDL actives avec leur source, leur version ou commit, leur Program ID et les surfaces qui les utilisent.
|
||
|
||
## Transport off-chain des metadata
|
||
|
||
- Évaluer une crate `kb-offchain-transport` générale après le pipeline metadata : fetch HTTP(S)/IPFS/Arweave, prix SOL/USD-EUR-CHF, APIs Jupiter et autres fournisseurs non Solana RPC.
|
||
- Décider séparément si cette crate accepte uniquement des lectures ou aussi des opérations off-chain authentifiées/mutables, avec contrats de sécurité distincts.
|
||
- Borner tailles, types MIME, redirections, délais et schémas HTTP(S)/IPFS/Arweave.
|
||
- Ne pas coupler le fetch off-chain au décodage déterministe ni au replay canonique on-chain.
|
||
|
||
## Registre Program IDs, IDL et surfaces implémentées
|
||
|
||
- Analyser `olddocs/archivekbobobot/docs/SOLSCAN_ACCOUNT_SOURCE_MATRIX.md` et les documents équivalents de bot2.
|
||
- Construire un registre croisé contenant au minimum Program ID, protocole, source vérifiée, présence d’IDL, provenance de l’IDL et chemin local.
|
||
- Comparer ce registre avec les constantes de `kb-program-ids`.
|
||
- Comparer chaque entrée avec les décodeurs, exécuteurs et matérialisateurs réellement présents dans `kb-lib`.
|
||
- Distinguer les IDL provenant de Solscan, Solana Explorer, dépôts Git officiels ou autres sources vérifiées.
|
||
- Ne pas déclarer l’inventaire complet avant le rescan des archives bot2 et bobobot.
|
||
|
||
## Architecture future des workers et applications
|
||
|
||
Cette proposition doit être étudiée avant intégration au ROADMAP définitif.
|
||
|
||
### Worker W1 — acquisition temps réel
|
||
|
||
- Binaire long-running utilisant `kb-onchain-transport`.
|
||
- Écoute configurable de Program IDs, logs, comptes ou autres filtres.
|
||
- Support progressif WebSocket, gRPC et recours HTTP/RPC lorsque nécessaire.
|
||
- Écriture des signatures et transactions raw dans `kb-store`.
|
||
- Modification à chaud des abonnements.
|
||
- Notification fiable de l’arrivée de nouvelles données raw.
|
||
- Arrêt uniquement sur demande explicite ou erreur fatale contrôlée.
|
||
|
||
### Worker W2 — décodage et matérialisation temps réel
|
||
|
||
- Binaire recevant ou détectant les notifications de nouveaux raw.
|
||
- Exécution des décodeurs et matérialisateurs activés.
|
||
- Configuration à chaud des surfaces actives.
|
||
- Notification après décodage et matérialisation.
|
||
- Traitement uniquement des données reçues pendant son activité ; aucun rattrapage implicite des périodes d’arrêt.
|
||
|
||
### Application de rattrapage historique
|
||
|
||
- Application ou binaire séparé, éventuellement Tauri.
|
||
- Réutilisation des capacités Core extraction, decode replay et matérialisation.
|
||
- Traitement des raw non pris en charge en temps réel par W2.
|
||
- Coordination explicite pour éviter la concurrence ou la double prise en charge avec W2.
|
||
- Backfill ciblé pour combler des périodes manquantes.
|
||
- Décodage et matérialisation configurables comme dans W2.
|
||
|
||
### Pilotage W1/W2
|
||
|
||
- Application de contrôle permettant de modifier à chaud les filtres d’acquisition, décodeurs et matérialisateurs.
|
||
- Diagnostics, état des workers, files d’attente, erreurs et métriques.
|
||
- Contrats d’administration séparés des contrats de données.
|
||
|
||
### Applications consommatrices
|
||
|
||
- Application de trading consommant les événements temps réel de W2 et l’historique de `kb-store`.
|
||
- Filtrage d’événements tels que nouveaux tokens, nouvelles paires, prix, migrations launchpad vers AMM, burns et changements de liquidité.
|
||
- Construction d’historiques et OHLC depuis les matérialisations stockées.
|
||
- Application non trading utilisant la même combinaison temps réel et historique pour visualiser les autres matérialisations.
|
||
|
||
### Principe de déploiement progressif
|
||
|
||
- W1 doit pouvoir continuer à acquérir les raw pendant le développement de nouveaux décodeurs.
|
||
- W2 et les applications peuvent être redémarrés pour charger de nouvelles surfaces.
|
||
- Le rattrapage historique doit traiter les périodes non couvertes sans perturber le flux temps réel.
|
||
- Les frontières de notification, ownership de traitement, idempotence et reprise doivent être définies avant implémentation.
|