May I pick this up?

@wengDavo Are you still working on it, or can I take over?

@mablr Yes you can take over I've got a bunch on my plate right now and probably won't get back to it anytime soon. Appreciate you jumping in!

@wengDavo All right, thanks for letting me know! I’ll it take over.

All the best!

TL;DR: "All that for this?"

I've started implementation work (in cast wallet), but I believe it's important to clarify a few design questions before proceeding:

1. Verbosity Control
   For the wallet address sub-command, the public key could be displayed alongside the address when the verbosity level (sh_verbosity()) is greater than 0, similar to how the address is displayed with the private key in the wallet private-key sub-command.
   Is this the intended behavior, or should the public key always be shown regardless of verbosity?

2. JSON Output Handling
   In the wallet new sub-command, when shell::is_json() is false, we could format the public key display similarly to wallet address.
   However, when shell::is_json() is true, adding the public key would alter the structure of the JSON output. How should we handle this?

   • Always include the public key in the JSON output, regardless of verbosity
   • Include it only when verbosity > 0 (but this would lead to inconsistent JSON structure)
   • Never include it in the JSON output

3. Code Organization
   Extracting the public key string from a WalletSigner object involves several processing steps, as seen in the wallet public-key sub-command.
   To avoid code duplication, we'd likely need to introduce a helper method in the WalletSubcommands implementation if we want to display the public key in other sub-commands.

Given all this, I’m starting to wonder: is it really necessary to display the public key in wallet new and wallet address, when users can simply run wallet public-key instead?

1. Verbosity Control
   For the wallet address sub-command, the public key could be displayed alongside the address when the verbosity level (sh_verbosity()) is greater than 0, similar to how the address is displayed with the private key in the wallet private-key sub-command.
   Is this the intended behavior, or should the public key always be shown regardless of verbosity?

Given we already have the public-key subcommand, modifying the address subcommand to also output the public key is redundant. If one already has a private key, they should directly use the public-key subcommand. Maybe restrict the scope to only modify the output of cast wallet new?

2. JSON Output Handling
   In the wallet new sub-command, when shell::is_json() is false, we could format the public key display similarly to wallet address.
   However, when shell::is_json() is true, adding the public key would alter the structure of the JSON output. How should we handle this?

   • Always include the public key in the JSON output, regardless of verbosity
   • Include it only when verbosity > 0 (but this would lead to inconsistent JSON structure)
   • Never include it in the JSON output

IMO, if cast wallet new will print the public key to stdout, then the JSON should reflect it as well. So, moving forward always include it in stdout and in the JSON.

3. Code Organization
   Extracting the public key string from a WalletSigner object involves several processing steps, as seen in the wallet public-key sub-command.
   To avoid code duplication, we'd likely need to introduce a helper method in the WalletSubcommands implementation if we want to display the public key in other sub-commands.

Agreed. Extracting the logic from the public-key subcommand seems simple enough.

The above portion seems a sufficient candidate, and should therefore make testing the new function simple.

Given all this, I’m starting to wonder: is it really necessary to display the public key in wallet new and wallet address, when users can simply run wallet public-key instead?

I'd recommend restricting the scope, and simply displaying the public key in the cast wallet new subcommand (taking into consideration the JSON output as well).

What do you think @coffee-converter ?

Thanks @0x8a8a for your feedback. I think we are at the same page about design, but I'm still sceptical about the real value of this feature even with the reduced scope. 🤔

I would also be interested to hear your opinion @coffee-converter.