5.3 KiB
Idées à explorer
Ce document conserve les idées, pistes, questions et alternatives qui méritent d'être étudiées sans constituer encore un engagement de développement ou une décision architecturale.
Statuts
À explorerEn explorationRetenueRejetéeTransférée au roadmapTransférée vers une décision/règle
APIs et extensibilité
Nomenclature *-api
Status : Retenue
Les crates de contrats publics extensibles utilisent ksp-<domain>-api, sans suffixe -lib.
Premiers couples retenus : program, materializer et store. Les APIs worker/job sont des lifecycle APIs distinctes.
Execution policy API
Status : En exploration — candidat fort
Étudier ksp-execution-policy-api comme contrat commun d'autorisation/safety/policy d'une exécution.
Le contrat doit permettre des implémentations différentes selon le contexte, par exemple scenario Devnet, application générale ou futur produit trading.
L'UI sélectionne/injecte une implémentation réutilisable ; elle ne doit pas devenir propriétaire d'une politique complexe.
Execution orchestration
Status : En exploration — candidat fort
Étudier ksp-execution-lib comme orchestration spécialisée entre programme, policy, wallet et transport, plutôt qu'une dépendance directe de ksp-program-lib vers wallet/transport.
Le graphe exact est reporté à 0.0.3-pre.003.
Scenarios : norme avant API
Status : Retenue
Ne pas créer ksp-scenario-api pour l'instant.
Définir d'abord une norme souple de structure, métadonnées, exécution et résultat des crates ksp-scenario-<domain>-lib, sans imposer un trait Rust qui limiterait des scénarios hétérogènes.
Réévaluer seulement si les premières implémentations révèlent un vrai contrat commun.
Type d'erreur KSP unique
Status : En exploration
La direction retenue est un seul type public ksp_core_lib::Error consommable par le workspace sans obliger ksp-core-lib à connaître chaque domaine supérieur.
Nommage des items publics
Status : À explorer
Définir avec les premières APIs réelles les conventions de nommage des traits, structs, enums, aliases, constantes et autres items exportés publiquement.
Arborescence et réexports
Status : À explorer
Définir avec les premières crates fonctionnelles les conventions d'arborescence, façades lib.rs, modules API et réexports publics.
Transport
Modèles homogènes on-chain
Status : Retenue
ksp-onchain-transport-lib ne dépend pas de ksp-store-api, mais ses différents providers doivent exposer des modèles homogènes par catégorie de données afin que ksp-worker-raw-retriever puisse les convertir simplement vers les modèles raw persistants du store.
Aucune ksp-onchain-transport-api séparée n'est prévue.
Off-chain volontairement hétérogène
Status : Retenue
ksp-offchain-transport-lib regroupe metadata, prix, quotes, routage et autres accès externes afin d'éviter une explosion de crates. Il n'est pas nécessaire de leur inventer une API métier commune.
Workers et jobs
Workers de processing
Status : Retenue
Après ksp-worker-raw-retriever, les responsabilités de processing actuellement prévues sont séparées :
ksp-worker-core-processor;ksp-worker-generic-materializer;ksp-worker-domain-projector(nom provisoire).
Worker control
Status : Retenue comme direction
ksp-worker-control-lib doit être une implémentation réutilisable de gouvernance consommable par des applications desktop manager, une future application globale et l'orchestrateur.
Job control
Status : Rejetée pour l'instant
Ne pas créer ksp-job-control-lib sans duplication concrète entre plusieurs jobs. ksp-job-api suffit comme lifecycle API commune tant que chaque job peut être gouverné directement via son implémentation.
Wallet : applications futures
Wallet Android
Status : À explorer — futur lointain
Une application Android native utilisant ksp-wallet-lib est envisagée. Nom exact à définir plus tard, candidat : ksp-app-wallet-android.
Extensions navigateur
Status : À explorer — futur lointain
Prévoir potentiellement des extensions Firefox et Chrome consommant les capacités KSP appropriées. Noms candidats non normatifs :
ksp-app-wallet-firefox-extension
ksp-app-wallet-chrome-extension
Le modèle de sécurité, la frontière Rust/WebAssembly/native et le stockage des secrets devront être étudiés avant toute décision.
Wallet web
Status : À explorer — futur lointain
Un wallet web/online utilisant les contrats KSP est envisagé. La gestion des secrets et le modèle de confiance devront être traités comme une question architecturale majeure avant développement.
Pipelines
Pas de pipeline monolithique
Status : Retenue
Ne pas créer de ksp-pipeline-lib. Les pipelines sont introduits séparément à la demande avec un périmètre concret.
Trading
Trading Intelligence avant application de trading
Status : Retenue
Construire d'abord statistiques, features, signaux, risque, backtests, détection de patterns/anomalies et intégrations ML telles que XGBoost. La couche/application de trading opérationnelle est construite ensuite.