khadhroony-solana-project/docs/IDEAS.md

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

• À explorer
• En exploration
• Retenue
• Rejetée
• Transférée au roadmap
• Transfé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 : Transférée vers une décision/règle

ksp-execution-policy-api est retenu 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 : Transférée vers une décision/règle

ksp-execution-lib est retenu comme orchestration spécialisée entre programme, policy, wallet et transport. Il dépend de ksp-program-api, pas de l'implémentation ksp-program-lib.

Les types exacts d'opération préparée et de policy restent à définir en 0.0.3-pre.004.

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.

Modèles communs inter-domaines

Status : À explorer avec l'implémentation

Aucun ksp-data-api global n'est prévu actuellement. Les modèles appartiennent à leur responsabilité (transport, program, materializer, store) et les composants de composition réalisent les conversions explicites.

Réévaluer seulement si les premières implémentations montrent une duplication réellement nuisible impossible à résoudre sans contrat commun supplémentaire.

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.

Program API — questions d'implémentation

Payload décodé ouvert et persistable

Status : À explorer lors de la première implémentation

ksp-program-api ne doit utiliser ni enum central fermé de Program IDs ni Any comme seule représentation.

À décider à partir des besoins réels :

• value tree typé KSP ;
• schema/version + payload binaire ;
• structure sérialisable ouverte ;
• autre contrat garantissant identification, persistence et extensibilité.

Conflits de registry

Status : À explorer

Définir la politique lorsqu'un registry reçoit plusieurs implémentations capables de traiter le même Program ID/surface/version :

• priorité explicite ;
• refus du conflit ;
• sélection par version/capability ;
• autre mécanisme documenté.

Convention interne dec / exec_prep

Status : À explorer avec les premiers modules

Le principe domain/program/capability est retenu. Les noms exacts des dossiers courts (dec, exec_prep) seront validés avec la première vraie arborescence.