[bloopernova]

This definitely looks interesting!

(I hope a project contributor is reading/commenting)

Q: Let's say I'm a representative of a company that wants to buy their name "example.com" to be resolved via Handshake. Assuming things are live and running well, what's the process by which we'd get www.example.com resolving to 123.123.123.123? (keeping it simple, not worrying about mx and srv records yet) How stable and safe is our record, assuming we owned the trademark for example.com?

[BluSyn]

This provides a replacement for the root zone and not does not directly include subdomains. In DNS terms this is like registering a TLD. So if you own "companyx.com" domain, you could register "companyx" on handshake. Once you own this domain you can use your private key associated to set your name servers / other DNS settings, so subdomains could fallback to using existing DNS resolution, or this could resolve directly to a website.

With your private key you can also do interesting things like verify your subdomains with signatures ala DNSSEC or verify your own SSL certs without CAs.

The paper also mentions future improvements that could see each TLD using a side-chain (like plasma) to manage and possibly sell their own subdomains. This could also give each TLD owner more control over their own "consensus rules" for their particular TLD.

There are a lot more possibilities here, some are covered in the paper, many more are still to be explored.

Super excited for this project!

[iforgotpassword]

I'm curious how this would work out at scale. Would everyone just get a long descriptive TLD and then use that directly? While that would technically work I imagine it would confuse people who are used to treat the address bar of the browser primarily as the search box. So I'd enter "flowers" and expect a Google search for flowers, but since the TLD flowers exists and resolves to something you end up on some dude's blog. The alternative would be to use the www subdomain, but apart from looking odd (www.flowers? Something my mom could accidentally come up with, forgetting the .com - so maybe not that bad after all...) since we're not used to that now, it also reverses the current trend of dropping the www.

So of looks like this could also mean some changes in how we actually use the web, not just how DNS is managed.

[pera]

That's a relatively new UI behavior popularized by Google Chrome. If you use Firefox, for instance, you can have two text boxes: one for the URL and another one for searching.

[lugg]

Chrome already handles this: if you want the domain enter in the protocol - https://

If you want to search leave it off.

On top of that Chrome already has the ability to redirect you straight to the domain if it is well defined. I can't imagine it difficult to move that logic to google redirects instead.

e.g. "test.vm" goes to a google search despite being url format. "test.dev" goes to domain.

[iforgotpassword]

The point is not whether there is a technical solution to that or not.

"I'll prefix the domain with https:// so I will directly establish a secure connection because leaving it out implicitly means plain http, which makes me vulnerable to mitm attacks" - nobody outside tech, ever

And it wouldn't be any different here. Over the last decade we've been so focused on dumbing down tech enough so that it's accessible to pretty much anyone on the planet. It will be very hard to reverse this trend. Even just adding a trailing slash is cumbersome. I can only imagine how many million man hours we'd have to waste worldwide to explain that to the average Joe and their mom. Just remembering how many times I've seen people type a backslash instead of a slash in URLs, this will be fun.

[fowl2]

trailing slash works and is easier to type ;)

[palisade]

"If you own a name in the existing root zone or the Alexa top 100k, your name is waiting for you on the blockchain. You are able to claim it by publishing a DNSSEC ownership proof – a cryptographic proof that you own the name on ICANN’s system. Your name must have a valid DNSSEC setup in order for the claim to be created. If you do not have DNSSEC set up, don’t worry – you can set it up after the handshake blockchain launches and proofs will still be accepted retroactively."

https://handshake-org.github.io/guides/claims.html

[RileyJames]

I’m confused, and after skimming through the paper I’m still not sure.

How does this work after the handshake network launches?

If I register a new domain with ICANN, but do not register it with Handshake, can someone else? And if not, doesn’t that mean ICANN is still the central authority for domain names? (Including transfers)

It seems like the existing root zone & handshake will immediately fork, and then how will 3rd parties determines which root zone is correct? Doesn’t that still mean existing CA’s could simply update the root zone (regardless of handshake) (which is the existing problem with bad actor CA’s).

I’m probably missing something here, could anyone elaborate?

[palisade]

My understanding of it is that 100,000+ are in reserve for existing companies / sites already registered. All you have to do is contact them to let them know, with proof, that you want ownership of yours. After launch there will be a "sunrise" period where if you register with ICANN, and then provide proof to handshake, they will give you ownership. I'm not sure how long that period lasts, I'm guessing for a long time until they feel ICANN is no longer relevant if I had to guess.

The goal of the project seems admirable. Potentially, this can help fund open source initiatives which are sorely underfunded while solving the "how do we find a domain in a decentralized way and verify its trust" issue that currently exists. I suppose time will tell, though.

[xur17]

My understanding is that all current tlds (.com, .net, .org, etc) will be claimable once the service launches. In addition, everyone in the Alexa 100k will be able to claim their domain stripped of the tld, so example.com gets .example, root.com gets .root. Handshake is only handling top level domains - dns will continue to handle resolving of subdomains.

Icaan will continue to be relevant, this will just control all other tlds.

This is just my understanding after doing some reading last night - someone please correct me if I'm wrong.