Add "name_display" field to name_show response

[JeremyRand]

Is your feature request related to a problem? Please describe.

Newbie users aren't likely to know how namespaces work. As a result, if they see d/theintercept in their name inventory, they may not understand that this is the domain name theintercept.bit.

Describe the solution you'd like

I'd like the name_show command's response to add a "name_display" field. This field returns an array of length 2. The first item in the array behaves as follows:

• If the name identifier meets the criteria in the domain names spec (from the proposals repo), return domain.
• If the name identifier meets the criteria in the identities spec (from the wiki), return identity.
• If the name identifier begins with dd/, return domain data.
• If the name identifier begins with idd/, return identity data.
• Else return nonstandard name.

The second item in the array behaves as follows:

• If a domain, strip the d/ prefix, add the .bit suffix, return the result.
• If an identity, strip the id/ prefix, return the result.
• If domain data or identity data, strip the corresponding dd/ or idd/ prefix, and treat the remainder as a nonstandard name (see next step).
• If a nonstandard name, and representable by ASCII, enclose the ASCII representation of the result in quote marks and return it.
• If a nonstandard name, and not representable by ASCII, prefix the hex representation of the result with 0x and return it.

The array result can be used by the Qt GUI to indicate what the name means, e.g. a name identifier whose name_display field is ["domain", "theintercept.bit"] can be displayed as domain theintercept.bit in the name inventory list, to make it clear that this is a domain name.

Describe alternatives you've considered

We could return a single string that concatenates the two above items, but I suspect this will make localization painful since Qt-based localization workflows will want "domain" to be a distinct string when it comes out of RPC.

We could put all of this logic in the Qt GUI, but that makes it annoying to do integration tests, and also I think this information is useful to CLI users.

Additional context

N/A.

[yanmaani]

I would prefer having a separate RPC that parses names, because it would be useful in more places than name_show. For example, name registration and trading could use this to warn you when you're trying to buy Domain.bit rather than d/domain.

See #365 and #360 (comment).

[domob1812]

I think this is definitely something out of scope for the core daemon and RPC interface. It is purely for frontends and should be included with such. CLI users should know what they are doing. If they want a nice interface and don't know about namespaces, they should use a frontend instead.

[JeremyRand]

@domob1812 I disagree with the view that we should assume CLI users are experts. We already do plenty of things to dissuade footgun scenarios in CLI mode (e.g. disabling name_new for existing names unless the user passes a flag indicating that they really want this). A nontrivial number of users use the CLI instead of the GUI not because they are Namecoin experts, but either because they are on a machine that doesn't have a GUI available (perhaps they're SSH'ed into a remote system) or because they are GNU/Linux experts (and therefore comfortable with a terminal UI, which doesn't in any way imply that they are experts on Namecoin).

AFAICT the amount of code involved in adding this to the GUI directly, versus adding it to CLI and then accessing the RPC interface from the GUI, is roughly the same. By doing the latter, we improve the UX for non-expert CLI users. I don't see any cost to doing so. Is there a hidden cost to the latter that I'm not seeing?

@yanmaani I agree that some of the logic in this proposal would be useful for determining whether a given name identifier is standard, which is useful for validating proposed name operations. That said, I don't want the GUI to have to call out to a validation method in addition to the name_list method, nor do I want CLI users to need to know about a name validation command that they need to call after name_show to get the info that they're likely to want. Can you suggest an approach that would work for both? (Seems like factoring out the common code to an internal function would be doable.)

[yanmaani]

I don't want the GUI to have to call out to a validation method in addition to the name_list method,

why not?

nor do I want CLI users to need to know about a name validation command that they need to call after name_show to get the info that they're likely to want

So you want a RPC call that (1) shows the value of the name and (2) shows the key of the name with the .bit suffix? That's way too niche, and there's no reason to have those in the same place. You would basically be creating a 'god RPC call'. NACK.