Discrepancy between `keys add` and `keys new`

[alexanderbez]

The commands keys new (newly added) and keys add result in a somewhat confusing UX. I believe from #2091, we want to mark add as deprecated (which we can via Cobra). However, add has "recovery" functionality which new does not. How do we want to handle this?

Does it make sense to have have recovery functionality in keys new? Perhaps we can remove keys add all together and simply add a keys recover command.

/cc @ebuchman @jackzampolin

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alessio]

In my opinion, we should have:

• a generate-key command
• a recovery command

The latter could be implemented just as a flag for the former.

[alexanderbez]

Why not then just add --recover to keys new and do away with keys add (which should be deprecated)?

[alessio]

I think generate is semantically more correct, though add does not bother me. Agreed on aggregating --recover 👍

[alexanderbez]

Ok so rename new to generate and add the --recover flag? Thoughts @jackzampolin @ebuchman?

[jackzampolin]

I would prefer not to use generate or new really. Unpopular opinion alert I think add describes the action best: you are adding keys to your database in all of the listed scenarios (--recover, generate/new). Thoughts?

[alexanderbez]

Also, I don't think keys new prints the seed @ebuchman ?

[jackzampolin]

@alexanderbez it does not.

[alexanderbez]

Shouldn't it?

[jackzampolin]

Yup!

[ebuchman]

Also, I don't think keys new prints the seed

Excellent and critical point! I don't have strong opinions here, other than that users should be able to enter mnemonic and bip39 passphrase interactively (ie. not recorded in shell history). As long as that's possible, I'm happy. Sorry for the mayhem on this one ...