4.8 KiB
Utilisation de ksp-app-wallet-desk
1. Lancement de développement
Depuis la racine du workspace :
(cd crates/ksp-app-wallet-desk && cargo tauri dev)
Pour isoler les wallets d'un parcours manuel :
(cd crates/ksp-app-wallet-desk && \
KSP_WALLETS_DIRECTORY=var/wallet-desk-manual cargo tauri dev)
Le processus Rust debug recale son current working directory sur la racine du workspace avant le bootstrap Config. KSP_WALLETS_DIRECTORY, les autres variables KSP et le .env restent résolus exclusivement par ksp-config-lib.
2. Format natif
Wallet Desk ne sélectionne pas directement une version de wire : il utilise la façade générique de ksp-wallet-lib.
nouveau wallet -> V2
import Solana CLI/Base58 -> V2
inspection/ouverture -> auto-détection V1/V2
mutation d'un V1 ouvert -> V1
mutation d'un V2 ouvert -> V2
La présence de V2 ne réécrit pas automatiquement les fichiers V1 existants.
3. Création / import
Dans Create / Import :
- la création génère une nouvelle identité Solana et un
.kspwalletV2 ; - l'import accepte les formats de transfert Solana retenus, puis crée un
.kspwalletV2 ; - OWNER est toujours requis ; VIEW est optionnel ;
- les passwords sont request-only et ne sont jamais renvoyés par IPC.
L'import natif utilise un picker Rust. Le path source complet et les bytes de keypair ne traversent pas le frontend.
4. Inventory et ouverture
L'inventory n'affiche que des projections locked sûres. La sélection ne déverrouille jamais automatiquement un secret Config.
L'ouverture peut ensuite utiliser :
- un password saisi manuellement ;
- un candidat secret Config explicitement sélectionné côté backend.
VIEW et OWNER produisent des handles Rust-only. La Pubkey, l'alias et les notes ne sont projetés qu'après autorisation.
5. Administration
OWNER permet notamment :
- modifier l'alias ;
- ajouter/modifier/supprimer des notes ;
- changer le password OWNER ;
- changer, désactiver ou recréer VIEW ;
- exporter la keypair en Solana CLI JSON ou Base58.
VIEW peut effectuer sa self-rotation lorsqu'il est actif. Les opérations destructives/privilégiées utilisent les modals Bootstrap du shell et non window.confirm/alert.
6. Migration V1 -> V2
La migration existe dans ksp-wallet-lib, mais n'est jamais un effet secondaire d'une ouverture Wallet Desk.
Les APIs bibliothèque dédiées sont :
migrate_wallet_v1_to_v2
migrate_wallet_file_v1_to_v2
migrate_wallet_file_v1_to_v2_in_place
Elles authentifient OWNER, reconstruisent un document cryptographique V2 neuf et conservent l'identité Solana ainsi que les metadata/note IDs. Lorsque VIEW est activé, un password VIEW cible doit être fourni. La copie est no-clobber ; le remplacement in-place est stale-protected.
7. Balance Solana
Une session VIEW ou OWNER autorisée peut demander getBalance via ksp-onchain-transport-lib. Le frontend ne choisit ni Pubkey arbitraire ni URL RPC : ces valeurs sont dérivées de l'état Rust autorisé et de Config.
8. Runtime packagé
En build release, les Config/schemas enregistrés sont des resources du bundle Tauri. Avant le bootstrap applicatif, ksp-config-lib prépare un répertoire de données utilisateur commun à KSP :
<runtime KSP writable>/
├── config/
│ ├── composite.ksp-app-wallet-desk.json
│ ├── std.logging.json
│ ├── std.transport.json
│ ├── std.wallet.json
│ └── schemas/
├── .env # créé/modifié uniquement par Config si nécessaire
├── logs/ # par défaut si path relatif
└── wallets/ # par défaut si path relatif
Le chemin physique exact dépend de la plateforme et est résolu par ProjectDirs; l'application ne suppose aucune home directory particulière.
Les Config existantes sont conservées lors d'une mise à jour. Les schemas sont synchronisés depuis le package courant. Le .env et les secrets ne sont jamais embarqués dans le bundle.
9. Validation de publication
Avant le build :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-config-lib
cargo test -p ksp-wallet-lib
cargo test -p ksp-app-config-desk
cargo test -p ksp-app-wallet-desk
cargo test --workspace
Puis parcours fonctionnel :
(cd crates/ksp-app-wallet-desk && cargo tauri dev)
Le smoke Devnet opt-in, s'il est rejoué, doit l'être avant le build final.
L'absolue dernière opération est :
(cd crates/ksp-app-wallet-desk && cargo tauri build)
Aucune commande de validation ne doit être exécutée après ce build avant la décision de publication/tag, afin de conserver la preuve d'ordre du gate.