Open JeremyRand opened 3 years ago
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 https://github.com/namecoin/namecoin-core/issues/360#issuecomment-663760674.
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.
@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.)
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.
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 nametheintercept.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:domain
.identity
.dd/
, returndomain data
.idd/
, returnidentity data
.nonstandard name
.The second item in the array behaves as follows:
d/
prefix, add the.bit
suffix, return the result.id/
prefix, return the result.dd/
oridd/
prefix, and treat the remainder as a nonstandard name (see next step).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 asdomain 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.