-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "name_display" field to name_show response #385
Comments
I would prefer having a separate RPC that parses names, because it would be useful in more places than See #365 and #360 (comment). |
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 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 |
why not?
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.
The text was updated successfully, but these errors were encountered: