Thank you for your responses 
; I’ll try to cover all the points.
I first tried rusqlite but it was quite limited, then I looked at several posts and tried to find one crate with a minimum of “stars” on github that seemed good (and diesel was also mentionned)
I only saw later that we can see an amount of downloads of a crate on https://crates.io (so indeed diesel is with a bit more usages).
If diesel also supports having proper entity mappings (it think it does) we could check to change to that one if you think it would be better in the long run 
I agree the naming could be improved. In fact, since I only save the secret in “substrate URI” format the 2 crypto_type Sr25519Mnemonic & Sr25519Seed are mostly the same; I create the KeyPair for them the same way (sp_core::sr25519::Pair::from_string(&deriv_suri, None).unwrap();).
And to answer @vit last point; in the case 2 different root keys were created, one with a BIP39 and one with a “mini-secret”/seed; the secret part stored will be as in my example:
BIP39:
"bottom drive obey lake curtain smoke basket hold race lonely fit walk"
mini-secret/seed:
"0xf813535799c3a15b8e419a06964e87fabd3f265caebcbb38c935a1acdbe05253"
And when creating the “//0” derivation for those; the “substrate uri” used will be:
BIP39:
"bottom drive obey lake curtain smoke basket hold race lonely fit walk//0"
mini-secret/seed:
"0xf813535799c3a15b8e419a06964e87fabd3f265caebcbb38c935a1acdbe05253//0"
So what would be best for those crypto_type values and should I still keep 2 different ones for the BIP39 | mini-secret/seed
(I’m fine with the proposition of @vit : “BIP39Mnemonic” / “EntropyKDFSeed” / “G1V1Seed”)
I understand that the human provided cesium id & secret are not really safe; but we still need to support them in order for people to migrate the identity and perform some more operations.
So indeed, I guess we should not allow creating derivations for those; although it is technically possible as shown in my test and from what I read in this page the hard derviations // are supported for all crypto; but soft derivation / are only supported by sr25519 pairs.
So the question that remains for G1v1 keys is do we still allow adding it to the vault
If yes, we should show in the vault list somehow that no derivation can be made on those; any idea
- An extra column “derivable” with values yes/no or a ‘*’ to say yes…
- Or I should just also display the
crypto_type(we need to come up with good names indeed) and mention that derivations are only allowed for the non G1v1 ones. Maybe I should reuse theSecretFormatvalues (Substrate, Seed, Cesium) to display to the user since the user has to provide a specific SecretFormat when importing something else than BIP39 ? (I adapted thevault list allprovided below with that idea)
Last question regarding G1v1 keys; is it ok if I continue persisting the “seed” suri of the key instead of the double id & secret (which is a bit annoying to save into 1 db field)
Indeed, I took the name from tikka db mappings in the first place.
So 2 questions for this one:
- Is it ok to continue using the same
encryptfunction we used for key files (age::Encryptor::with_user_passphrase(Secret::new(passphrase));) - What name would be best;
encrypted_suri (in which case it would only be correct if we keep persisting G1v1 seed as a surias well)
I didn’t get what you meant in this case. The user input for “derivation path” (requested using inquire) is allowed to be empty (=> None in Rust and null in DB) or any string that must start with at least one ‘/’ character since all derivations path must have at least one of those.
We may want to add extra checks for the user input path; but it might be enough to check we don’t already have the same SS58 address persisted in db when computing the keypair with the “root” suri + the derivation path.
Indeed, I might not be consistent in my namings everywhere and if we can come up with better names, I’m all for it
About “vault name”
Since the name db property is in vault_derivation db table; we can have a name for any derivation (<Root> or otherwise).
In my example of list all above, “substrateDeriv1CustomName” was a specific name given to a derivation with path “//1”.
And since most of the commands should allow us to select a specific SS58 Address or it’s name this is why I decided on “vault name”; I also think “account name” is risky and might be confused with the “Identity” name linked to the account.
Maybe it would be better to mention “derivation name” (I gave examples below using that - to be seen if it’s clear/good enough)
It could be something like
Options:
-a <ADDRESS> SS58 Address
-d <NAME> Derivation name for a SS58 Address (can be a <Root> derivation name)
And in the vault list all
gcli vault list all
available derivations:
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ SS58 Address Format Path Derivation Name │
╞══════════════════════════════════════════════════════════════════════════════════════════════════════╡
│ 5DfhGyQdFobKM8NsWvEeAKk5EQQgYe9AydgJ7rMB6E1EqRzV substrate <Root> mySubstrateKey │
│ 5D34dL5prEUaGNQtPPZ3yN5Y6BnkfXunKXXz6fo7ZJbLwRRH //0 <mySubstrateKey//0> │
│ 5GBNeWRhZc2jXu7D55rBimKYDk8PGk8itRYFTPfC8RJLKG5o //1 substrateDeriv1CustomName │
│ 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY //Alice <mySubstrateKey//Alice> │
│ 5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4 cesium <Root> myCesiumKey │
│ 5GjAp6kkbsDjxABGouMvu1Mxbr7PaFqbMrprEoZ466vPF2Vt seed <Root> mySeedKey │
│ 5HBwy19piXNWg7bfShuNgWsBCWRzkG99M8eRGB6PHkxeAKAV //0 <mySeedKey//0> │
│ 5HdRvcHctMZG4KVFZd1qLwgKyLhvKWTAGYpXsu2JRkUp3u5h //2 deleteme │
└──────────────────────────────────────────────────────────────────────────────────────────────────────┘
About “vault key”
Maybe also using “derivation” for that instead
Example of adated commands:
gcli vault derivation --help
Add a derivation to an existing <Root> derivation
Usage: gcli vault derivation <-a <ADDRESS>|-d <NAME>>
Options:
-a <ADDRESS> SS58 Address
-d <NAME> Derivation name for a SS58 Address (can be a <Root> derivation name)
-h, --help Print help
For that one, if needed we can adapt to use a different clap command “argument” that would have a slightly modified explanation for -d <NAME> : derivation name for a <Root> SS58 Address
gcli vault rename --help
Give a meaningful derivation name to a key derivation (can be for a <Root> derivation)
Usage: gcli vault rename <ADDRESS>
Arguments:
<ADDRESS> SS58 Address
Options:
-h, --help Print help
gcli vault remove --help
Remove a derivation (and all linked derivations along with the key if a <Root> derivation is given)
Usage: gcli vault remove <-a <ADDRESS>|-d <NAME>>
Options:
-a <ADDRESS> SS58 Address
-d <NAME> Derivation name for a SS58 Address (can be a <Root> derivation name)
-h, --help Print help
gcli vault use --help
Use specific derivation (changes the config Address)
Usage: gcli vault use <-a <ADDRESS>|-d <NAME>>
Options:
-a <ADDRESS> SS58 Address
-d <NAME> Derivation name for a SS58 Address (can be a <Root> derivation name)
-h, --help Print help
I can add another sub-command for vault list.
Maybe vault list for where we could provide SS58 Address or name of a (<Root>) derivation
Something like:
gcli vault list --help
List available derivations
Usage: gcli vault list <COMMAND>
Commands:
all List all <Root> derivations and their linked derivations in the vault
for List all derivations linked to the one selected
root List only <Root> derivations in the vault
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
gcli vault list for --help
List all derivations linked to the one selected
Usage: gcli vault list for <-a <ADDRESS>|-d <NAME>>
Options:
-a <ADDRESS> SS58 Address
-d <NAME> Derivation name for a SS58 Address (can be a <Root> derivation name)
-h, --help Print help