rnp cli user experience

[dewyatt]

Description

What are everyone's thoughts on the possibility of redesigning the rnp CLI at some point to be more like git? (Or are there other ideas for improvement in this area?)

I find git's separation of "commands" vs "options" to be a good user experience, like: git stash save --keep-index, git --no-pager log, git commit --author=....

It would be interesting to see if rnp's operations could actually be reduced to this form, and if that would improve the user experience. It's difficult since there is some overlap in some operations.

I could imagine something like:

rnp dearmor (default to stdin)
rnp enarmor file.gpg
rnp import (autodetect format and import from stdin)
rnp import key.asc (default to autodetect)
rnp import --format=GPG --armor key.asc
rnp export --userid=user1
rnp export --armor --keyid=0x...
rnp generate rsa --numbits=1024 (prompt for required info)
or rnp generate --type=rsa --numbits=1024 --userid=asdf --passphrase=asdf (maybe non-interactive if all required info is supplied)
rnp encrypt --output encrypted.data plaintext.data (encrypt with default key)
rnp decrypt encrypted.data
rnp encrypt --add-recipient=user1 --add-signer=user1 plaintext.data
rnp encrypt --add-passphrase --cipher=cast5 (prompt for pass)
rnp encrypt --add-passphrase=pass1 --add-passphrase=pass2 (no prompt)
rnp sign (sign stdin data with default key)
rnp --homedir=~/.rnp sign --add-signer=user1 file.data

Anyways, I haven't really thought about the above in-depth, just throwing some ideas out there, there's likely issues. But I think it's worth discussing whether we can innovate a bit and improve the user experience in this area.

[ni4]

For the new user it would be no difference - he'll need to learn it, and existing commands would work in the same way as ones without dashes.

Slightly easier would be commands without additional options, i.e., say, rnp encrypt somefile.txt user1@email user2@email aes-128 or rnp sign somefile.txt cleartext sha256 user@email. This will make some problems during the parsing, but, for instance, 'sha256' or 'aes128' in command line clearly says about user's intentions.

Also I was thinking about making 'gpg emulation layer' - i.e. script or executable which will consume the same commands as gnupg does and do the same functions. Will this bring any value?

[dewyatt]

For the new user it would be no difference - he'll need to learn it

I think we should have a more user-friendly view than that.

One potential difference that I could see for a new user is that when they look at example invocations (in the man page, or on some help forum), they can more quickly ascertain what the main "operation" is that is being performed because it's always the first positional argument. I think it's a pattern that people pick up on and it's more intuitive than the alternative. If you have something like: gpg --armor --local-user=user0 --recipient=user1 --encrypt rnp encrypt --armor --userid=user0 --add-recipient=user1

IMO the latter is easier for a new user to grasp. They immediately see "rnp encrypt" and know what the overall purpose of the invocation is.

Anyways, personally I've observed this approach becoming more popular over the past 10 years or so in tools like git, docker, npm, kubernetes/kubectl, vagrant, aws, gcloud, systemd/systemctl, pip, etcd, and a ton of other things. It seems like a well-organized way of doing a CLI, and makes it easy to split man pages up for each operation as a bonus (like man docker-run or man git-commit).

My opinion is that the CLI is a sore spot in gpg and an area where rnp could be more "modern" and user-friendly.

rnp encrypt somefile.txt user1@email user2@email aes-128 or rnp sign somefile.txt cleartext sha256 user@email.

It seems nice, but personally I would never recommend this because of the ambiguity introduced.

[ronaldtse]

I fully agree that the git/aws "command style" CLI is preferable. All our CLI tools, including Ribose CLI, RVC utilize this style which is way more usable than --[options].

One major benefit is that we clearly separate where the options apply (and in the help) to each command, such as:

rnp generate-key help
rnp generate-key --asymmetric --alg ecdsa --output json

[ronaldtse]

Let's come up with a full list of commands?

[ni4]

Then let's stick to this style for sure. We have issue #323 with full list of commands, so it should be updated, basically with deletion of -- prefix for the commands.