You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #365, a RPC interface to validate certain information was proposed. This would take encoded data and return information about its relation to the specification.
Recent discussion regarding PR #436 and generation of names according to delegation seem to create the need for at least two additional RPCs:
Take non-Namecoin data (e.g. ["példány", "rootdomain"], ["delegated", "delegatorvalue"]) and encode this according to Namecoin specs (e.g. d/xn--pldny-zqa7c, {"import":"dd/delegated"})
I think I'd prefer to have two RPCs for manipulating names (parse name, serialize name), and two RPCs for manipulating values (decode value, encode value). Then you could factor out "find name by appending random digits" into a RPC call, and then just put the parts together in the GUI.
So these two RPCs could be four, if you'd split it like "name to namecoin", "name from namecoin", "value to namecoin", "value from namecoin". I still think that would be slightly preferable.
@JeremyRand, I think you may have strong feelings on this.
The text was updated successfully, but these errors were encountered:
Sounds good to me, and as long as the code is separated into its own set of RPC methods, I don't really mind adding this. Regarding "name to/from namecoin" specifically, though, isn't that just straight-forward IDN encoding? Is that something that the RPC interface needs to expose? I think users should just use their IDN library of choice or the idn CLI instead of expecting Namecoin to do it for them.
That's a fair point, but if the feature is to be in Namecoin (see discussion in #385), I think it's strongly preferable that it be its own RPC. Also, I think Namecoin might have special considerations with regard to homoglyph attacks, because it's not nationally bound. That might cause for it to have special rules on encoding, e.g. encoding "россия.bit" as "pocc" (Latin letters) + "ия" (Cyrillic), or giving some kind of warning on mixed stuff like "nаmесоіп.bit". There's a whole literature on best practices out there I'm pretty sure.
Anyway, I think the idea is to use it for the GUI while registering names, which broadly seems like a good idea, and since you can't really put complexity in the GUI code because it's untestable, you have to put it in its own RPC if you want to test it. So you'll need at least some of this functionality for that.
In #365, a RPC interface to validate certain information was proposed. This would take encoded data and return information about its relation to the specification.
Recent discussion regarding PR #436 and generation of names according to delegation seem to create the need for at least two additional RPCs:
["példány", "rootdomain"]
,["delegated", "delegatorvalue"]
) and encode this according to Namecoin specs (e.g.d/xn--pldny-zqa7c
,{"import":"dd/delegated"}
)In the review of #436, I said:
So these two RPCs could be four, if you'd split it like "name to namecoin", "name from namecoin", "value to namecoin", "value from namecoin". I still think that would be slightly preferable.
@JeremyRand, I think you may have strong feelings on this.
The text was updated successfully, but these errors were encountered: