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

Qt: UI mock of DNS configuration dialog #196

Open
brandonrobertz opened this Issue Nov 15, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@brandonrobertz

brandonrobertz commented Nov 15, 2017

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:

domain_mock

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?

@JeremyRand JeremyRand changed the title from UI mock of DNS configuration dialog to Qt: UI mock of DNS configuration dialog Nov 16, 2017

@jonasbits

This comment has been minimized.

@JeremyRand

This comment has been minimized.

Member

JeremyRand commented Nov 16, 2017

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:

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

@brandonrobertz

This comment has been minimized.

brandonrobertz commented Nov 16, 2017

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

This comment has been minimized.

domob1812 commented Nov 16, 2017

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

This comment has been minimized.

brandonrobertz commented Nov 16, 2017

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).

domain_mock2

@brandonrobertz

This comment has been minimized.

brandonrobertz commented Nov 18, 2017

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.

peek 2017-11-18 15-00

@JeremyRand

This comment has been minimized.

Member

JeremyRand commented Nov 19, 2017

@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

This comment has been minimized.

Member

JeremyRand commented Nov 19, 2017

@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 .

@domob1812 domob1812 added the qt label Jun 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment