SafeKeys - is there a better name?

Features
21

So what is actually should be passed as SafeKey1 in --pay-with <SafeKey1>?
Wallet Safe-URL? Is it treated also as SafeKey?

22

If you pass a SafeKey CLI would still ask you for a secret key, so not that useful, if you otherwise pass a Wallet-URL and assuming CLI can decrypt it then that should be enough. Remember you could pass a Wallet-URL with a name of the specific spendable balance, e.g. --pay-with safe://<wallet-url>/for-beers

1 Like
23

It looks like your example command is more about wallets than safekeys then.

24

Probably yes. A SafeKey in some of those examples can go in the --to arg, e.g. wallet transfer --to safe://<safekey-URL> --from safe://<wallet-URL>/for-beers

1 Like
25

I was thinking a bit more about this, but what if:

$ safe files put ./file.txt --pay-with <SafeKey1> --owner <SafeKey2> --encrpyt-with <SafeKey3>

prompts you for the corresponding secret keys, unless you provide --with-trezor in which case the SafeKey URLs are used to dictate which secret keys to use form the Trezor, so CLI automatically can request Trezor the three different keys to pay/sign/encrypt with ?

We could have commands to retrieve the SafeKeys that correspond to each of the Trezor keys, e.g.:

$ safe keys show --from-trezor

…and why would I want the keys from Trezor in the form of a SafeKey URL? well, in this way I can then give people an NRS-URL for my Trezor SafeKeys, so they will make transfers to safe://bochaco and I will then be able to check my balance and/or use my coins using my Trezor with:

$ safe keys balance safe://bochaco --with-trezor

Note I’m using Trezor for all the examples, but as we start supporting other devices they can all have their corresponding flags in the same commands to function analogously.

3 Likes
26

Maybe CLI can have commands to specify default source(s) of secret keys?
If search for secret key, which corresponds to SafeKey, is successful, then CLI will use it.
If not, ask user where it should look for it or ask secret keys directly.

2 Likes
27

I think that the names of these keys only need to make sense in the context of their intended use. They don’t need to correspond to what they actually are, but what makes it easiest for the user to understand.

For instance if the keypair is generated and stored on the network for the purpose of being used for sending and receiving tokens, then call it a WalletKey. If the purpose is to sign, call it a SignatureKey, if the purpose is to encrypt, call it an EncryptionKey.

This is assuming the keys are created in the CLI or some GUI for instance and is saved on the network for ease of use for regular people.

But since the keys are actually all the same thing, if the user creates their own keys in any way, just call them what they are. Since this user clearly knows what they are doing, calling the keys something else is likely to create confusion. They are simply then a key pair.

All the keys on and off the network can still be used for the same things if a user wants and knows how to. But this is a poweruser use case and can be ignored as far as naming goes. So the fact that they are interchangable can be ignored, which removes the need for a single name for all keys, which allows for clearer names.

4 Likes