Qt: UI mock of DNS configuration dialog

[brandonrobertz]

I'm mocking up the UI for the d/ DNS managemane dialog and I was looking for some input / general ACKs before I get the code locked to the design. I created a quick mockup of what I've got so far:

Basically this covers everything related to a single (non-subdomain map) domain name. I was thinking that in the "DNS Records" table, I'd list all current records and allow you to edit them using the tabs (you'd click edit a record, it would bring up the tab with the values filled and allow you to update.) I do have some questions about how to proceed.

• Is the d/ spec fully recursive via map? I.e., do I need to come up with a way to be able to recurse (infinitely) into various sub-sub-sub domains and offer all the options found at the top level? I might need to come up with a slightly different design for this if it's the case.
• What's the current max size (in bytes) for name values?
• Do you think organizing things in relation to DNS, as I have now, is a good way to organize the dialog?
• Are all options found in the spec (https://wiki.namecoin.info/index.php?title=Domain_Name_Specification) currently being used? I put the ones that appeared to be the most standardized, but the spec was vague about which were allowed currently, which are in use, which haven't been implemented, etc. Should I add more options to the UI?

[jonasbits]

This spec is nice https://github.com/namecoin/proposals/blob/master/ifa-0001.md

[JeremyRand]

Is the d/ spec fully recursive via map? I.e., do I need to come up with a way to be able to recurse (infinitely) into various sub-sub-sub domains and offer all the options found at the top level? I might need to come up with a slightly different design for this if it's the case.

Yes, recursive map usage is allowed.

What's the current max size (in bytes) for name values?

It should be equal to the Bitcoin PUSHDATA size limit, which if I recall correctly is 520 bytes. Note that transactions that go over this limit are valid, but cannot be spent (so going over the limit is an easy way to accidentally destroy a name). I don't know whether the RPC commands guard against this -- if they don't, they should be amended to do so.

Do you think organizing things in relation to DNS, as I have now, is a good way to organize the dialog?

Whatever is standard practice for DNS registrar UI's is fine with me, since they have better UX evaluation resources than we do. I'm curious, do DNS registrar UI's typically combine A and AAAA records that way?

Are all options found in the spec (https://wiki.namecoin.info/index.php?title=Domain_Name_Specification) currently being used? I put the ones that appeared to be the most standardized, but the spec was vague about which were allowed currently, which are in use, which haven't been implemented, etc. Should I add more options to the UI?

The correct specs are:

• https://github.com/namecoin/proposals/blob/master/ifa-0001.md
• https://github.com/namecoin/proposals/blob/master/ifa-0002.md
• https://github.com/namecoin/proposals/blob/master/ifa-0003.md

The wiki is severely outdated. I suggest adding import, srv, tls, txt, and sshfp.

[brandonrobertz]

Thanks for the quick responses everyone.

Whatever standard practice for DNS registrar UI's is fine with me, since they have better UX evaluation resources than we do. I'm curious, do DNS registrar UI's typically combine A and AAAA records that way?

@JeremyRand No they typically have an A section (IPv4) and AAAA (IPv6). I figured I'd combine them since Namecoin also adds Tor, i2p, etc and having separate sections for all those seems redundant. I can update the tab to say A/AAAA if that would make it clearer. The dropdown was going to be a resource/domain type specifier.

[domob1812]

Regarding the size limit for values: Yes, the maximum length is 520 bytes - the RPC commands verify that. But as Jeremy pointed out, this is not the full truth; you can set the value to 1023 bytes max once, and then you are no longer able to renew the name so it will expire. I think for your purpose you can ignore that, though, and just always assume 520 bytes as the hard limit.

[brandonrobertz]

Updated mock with the (I think?) full spec implemented. I still need to find a good way to implement recursive map, but I'm thinking users will interact with this whether they're on a top level or inside a map (with certain tabs/things disabled per spec).

[brandonrobertz]

And here's what I've got for map. This pretty much completes the mock. I'm going to continue coding this design unless I get any strong NACKS.

[JeremyRand]

@brandonrobertz a few minor notes:

• As per DNS RFC's, NS records can't contain an IP address, only a domain name. (FQDN's need a trailing period.)
• Might be useful to add ZeroNet to the A tab.
• I believe SOA records (email JSON field) are deprecated in favor of identity records (info JSON field). @hlandau would be able to better comment on this point.

Other than that, it looks okay to me, but I'm not a UX expert. Might be worthwhile to post the UI mockup on Reddit and the forum to get wider feedback.

[JeremyRand]

@brandonrobertz also note that the only form of TLSA records that actually works in browsers is the dehydrated form from https://github.com/namecoin/proposals/blob/master/ifa-0003.md .