Public key format mismatch between `gnoland secrets init` and `gnoland genesis validator add` about gno HOT 7 CLOSED

I agree with @zivkovicmilos on this, the key must not be stored in bech32 format because the key could be used somewhere else.

See it like the wallet private key, it's for Gno, but you can use the same private key anywhere else.
The Validator key could be use for another chain, ( It's a bad practice of course ) but it's on the validators to decide.

Bonus, if the key leak, it's harder to determine which chains the key belongs.

But i agree, i already discuss with milos on it, the CLI must be improved for gnoland secrets get ... to show simpler results.

from gno.

Thanks @zivkovicmilos for providing all the context.

At the moment, secrets get provides Address and Key information in plain text. I propose either outputting them as json by adding a --json flag or saving the key in Bech32 format. This would allow us to easily parse the contents of the secrets JSON with tools such as jq.

from gno.

This is one of those "it's not a bug it's a feature" moments in Gno

Ed25519 keys are saved as base64 encoded Amino on disk, ex:
VRFGraumxyIOS6Rij5HHqhN3zOXp6s4K7WJKZy+bDcA==

This is legacy logic that we haven't really touched (there was no need) -- it's fine to keep the key not human readable. Our secrets get commands know how to display this of course in a format you can use for other commands.

gnoland genesis validator add , however, is custom made to take in the bech32 representation of the key, because the crypto lib we use (our own) can easily parse pub keys from this format (that, or either raw bytes).

The flow currently is:
generate key -> fetch the key using secrets get -> use that value to add the validator

I think we could've easily gone the route of just taking in the public key as base64 amino encoded, and decoding it in the validator add command, but at the time this was the quickest route; we figured we'd iron it out later if needed

What do you think @r3v4s, @albttx? Should we standardize this in some way?

from gno.

@mazzy89
We have a tracker issue for the json output #2301

from gno.

I spoke already about this with @moul who agreed on the bad UX and agreed on opening the issue. I'm fine to wire a fix.

from gno.

@zivkovicmilos
For better UI/UX, yes I think we should standardize it somehow.
Why don't we just add another flag like #2249(#2301) does?

• --decode or --readable? Looking for some better string 🤣🤣

from gno.

Closed by #2393

from gno.