cli: Support import and export of key pairs

[CodeSandwich]

We need to be able to migrate the accounts between machines.

The proposition:

Add commands:

• account export, which exports accounts to a file
• account import, which imports accounts from a file

The file should store the accounts' metadata, e.g. a human readable name. We can reuse the format of accounts.json.

account export should allow exporting either all the accounts or only the chosen ones, specified by their names.

account import should add all the accounts from the given file. When importing an account, which already exists, it should be silently ignored, when it's exactly the same (most importantly the seed), but should cause an error otherwise.

[NunoAlexandre]

This is exactly how I pictured doing the account import and account export :)

[NunoAlexandre]

I gave this some more thought and I'm not sure whether it's worth implementing this feature.

The way I imagine the feature,

• on export, a file path arg is provided where the selected key pairs will be stored. The user should select those key-pairs interactively or else we essentially require the user to remember the name of their key-pairs. The possible paths are:

  • The output file already exists.
    • If its format is valid, we can add new key pairs to it.
      • a selected key-pair name doesn't exist
      • If there is a clash in names, we should ask the user what to do: keep existing, overwrite with the new being added, rename the new one, etc
    • If its the format is something else, we should confirm with the user that we should overwrite it.

• on import, a file path arg is provided where the selected key pairs will be imported from. The user should select those key-pairs interactively or else we essentially require the user to remember the name of their key-pairs. The possible paths are:

  • The input file doesn't exist
  • The input file exists.
    • If its format is valid, we can add read key pairs from it.
      • a selected key-pair name doesn't exist
      • If there is a clash in names, we should ask the user what to do: keep existing, overwrite with the new being added, rename the new one, etc
    • If its the format is something else, we can only report it and stop.

Now, note the number of cases and the steps that a user has to go through to friendly import and export key-pairs.

Wouldn't it be much simpler to let the user know where the key-pairs are stored and let them copy-paste them between key-pairs.json files of two different machines? As of now, the key-pairs.json file is not pretty, so it would be cumbersome to do this, but that's very easy to address. We can easily document how to do this. I can't imagine the target audience of our chain not knowing how to edit a file and move json values, but please correct me if I'm mistaken.

Lastly, this features comes in to address a use case that wouldn't have been necessary if it wasn't for this confusion created by our docs: https://radicle.community/t/spinning-up-a-testnet-node-first-user-experience/196/5. So I vote to not introduce this in the end but prettify the key-pairs.json file and document how to transfer keys between machines.

[CodeSandwich]

on export (...) we essentially require the user to remember the name of their key-pairs

What's wrong with that? As a user I would just call key-pair list and then copy-paste them. As an engineer I would be delighted to keep the logic as simple and generic as possible.

The output file already exists.

As a user I would consider this default behavior unexpected and dangerous. My keys are extremely sensitive and I want full control and awareness of what's going on with them. I would prefer to see an error, unless I pass --apend or --force.

on import (...) The user should select those key-pairs interactively or else we essentially require the user to remember the name of their key-pairs

Maybe we could get away with not having an interactive CLI if we add a key-pairs import list command?

Wouldn't it be much simpler to let the user know where the key-pairs are stored and let them copy-paste them between key-pairs.json files of two different machines?

I find this solution much more error prone and dangerous. First we must add a command, which will tell the user the location of the file on their specific system. Then we're asking them to manually edit a dotfile in a machine format containing the keys to their assets. It's like giving a guy a scalpel and asking him to make an operation on his own open heart. I think that we should make it possible and natural to never touch this file.

Another point is our freedom with the format - being user editable is a major design limitation. It must be readable by humans (no switch to BSON, no encryption), must never change its format (no switch to YAML, all the format updates must be optional) and must contain only data, which can be moved atomically (no state (e.g. operation counter), no global metadata (e.g. hash of the whole file)).

Lastly, this features comes in to address a use case that wouldn't have been necessary if it wasn't for this confusion created by our docs

The docs confusion was the first time we've encountered the keys migration use case, but it's valid on its own. We must think about a way to move the keys, they mustn't be locked on one machine by design.

[NunoAlexandre]

on export (...) we essentially require the user to remember the name of their key-pairs

What's wrong with that? As a user I would just call key-pair list and then copy-paste them. As an engineer I would be delighted to keep the logic as simple and generic as possible.

Note that you point out the user-unfriendly step there: to perform a step, you first need to perform another one, which requires copy-pasting sensitive data to some location (say, a new terminal tab or a notes tool) where you can both see it and perform the second step, the one that you actually want to perform.

The output file already exists.

As a user I would consider this default behavior unexpected and dangerous. My keys are extremely sensitive and I want full control and awareness of what's going on with them. I would prefer to see an error, unless I pass --apend or --force.

It's only as unexpecting as the user lets it be, right? they specify the paths... Anyway, my suggestion is to interactively ask the user whether that's really the intended action, so it's not more dangerous than your counter-proposal which I'd be fine with.

on import (...) The user should select those key-pairs interactively or else we essentially require the user to remember the name of their key-pairs

Maybe we could get away with not having an interactive CLI if we add a key-pairs import list command?

Could you expand?

Wouldn't it be much simpler to let the user know where the key-pairs are stored and let them copy-paste them between key-pairs.json files of two different machines?

I find this solution much more error prone and dangerous. First we must add a command, which will tell the user the location of the file on their specific system. Then we're asking them to manually edit a dotfile in a machine format containing the keys to their assets. It's like giving a guy a scalpel and asking him to make an operation on his own open heart. I think that we should make it possible and natural to never touch this file.

Another point is our freedom with the format - being user editable is a major design limitation. It must be readable by humans (no switch to BSON, no encryption), must never change its format (no switch to YAML, all the format updates must be optional) and must contain only data, which can be moved atomically (no state (e.g. operation counter), no global metadata (e.g. hash of the whole file)).

I agree with your argument about the format.

Lastly, this features comes in to address a use case that wouldn't have been necessary if it wasn't for this confusion created by our docs

The docs confusion was the first time we've encountered the keys migration use case, but it's valid on its own. We must think about a way to move the keys, they mustn't be locked on one machine by design.

I agree the feature makes sense to exist, but so probably do many more. I prefer to be lean and not implement every single feature that might potentially be used, that's all.

[CodeSandwich]

Note that you point out the user-unfriendly step there: to perform a step, you first need to perform another one, ...

This step is optional, it's only a helper when the user doesn't remember the name.

... which requires copy-pasting sensitive data to some location (say, a new terminal tab or a notes tool) where you can both see it and perform the second step, the one that you actually want to perform.

Key pair name isn't sensitive.

Maybe we could get away with not having an interactive CLI if we add a key-pairs import list command?

Could you expand?

This command could return a list of names of the keys stored in the imported file.

I agree the feature makes sense to exist, but so probably do many more. I prefer to be lean and not implement every single feature that might potentially be used, that's all.

Of course, it's an issue tracker, not a to-do list for today morning 😉

[NunoAlexandre]

Note that you point out the user-unfriendly step there: to perform a step, you first need to perform another one, ...

This step is optional, it's only a helper when the user doesn't remember the name.

I know, my point is that is, most likely, something users would have to do more often than not.

... which requires copy-pasting sensitive data to some location (say, a new terminal tab or a notes tool) where you can both see it and perform the second step, the one that you actually want to perform.

Key pair name isn't sensitive.

I was imagining copying the whole things since it'd be too much effort to copy only the entry keys. There could also be the case that the user needs to check on the address and not on the key pair name. (for example, they have been using an address for mining but can't remember which name identifies it(

Maybe we could get away with not having an interactive CLI if we add a key-pairs import list command?

Could you expand?

This command could return a list of names of the keys stored in the imported file.

As a user, I'd much rather have the import being interactive.