Comment by comex | Hacker News Reader

Comment by comex | Hacker News Reader

It still seems bizarre to me that this system lets people register arbitrary TLDs. If nothing else, sooner or later a new ICANN gTLD will conflict with a Handshake registration. At that point, Handshake will no longer be a backwards compatible extension of the existing DNS, so systems will have to choose one or the other. Maybe the Handshake authors think that when that day comes (and it's probably not that far off), Handshake will already have achieved enough popularity that operating systems and browsers will choose Handshake instead of ICANN. Somehow, I doubt it...

Imagine IPv6, but if it was somehow designed to squat on top of the IPv4 namespace, so that switching to IPv6 would cause existing addresses to start pointing somewhere else. That's pretty much the situation Handshake has chosen to be in.

Not to mention that allocating TLDs

- confuses non-technical users ("what do you mean, there's no dot in the address?")

- conflicts with the choice of most browsers to unify the address and search bar (if I type refrigerators and press enter, I want a search results page, not the homepage of whoever registered the TLD 'refrigerators')

- may conflict with other non-standard domain name systems, including special-purpose TLDs like .onion – though they've at least reserved the existing ones, so it would only be a problem for not-yet-developed systems

It's strange, because I want to support decentralized name systems, and Handshake seems better designed than some of the previous attempts, but that one decision makes it seemingly guaranteed to fail.

Its just one example of the entire governance problem thats conspicuously absent from the post. How is dispute resolution handled? Identity verification? Attestation?

Reasonable answers to those questions are generally counter to the raison d’etre of setups like this. And without it you have a spam and scam goldrush to squat the most “valuable” entries and pretty big gap in _human_ trust in the system.

What inherently requires an identity to register a domain name?

When you become big, famous, influential, anything like that. Then people can register your domains and misrepresent you or just use your namesake as a platform to attack you (write bad things about you at best, do some really nasty damage at worst). Need to play defense preemptively.

I prefer technology to deal with the technical issues and individuals to deal with their individual issues.

Tech can't possibly cater to everyone's special needs.

I'm totally fine with domain names being the interface between thr protocol and the human user. All other mappings (e.g. legal names) fall in the realm of human politics.

The problem is that you cannot do anything about it, other than suing the author - if you can find them and they're in a reasonable jurisdiction.

Well, you can try to break the system by splitting it in half, introducing an overlapping domain. If collisions is the desired way of dealing with it, the whole thing is ultimately broken.

Just imagine Amazon breaking Google domains because they have a better cloud.

With ICANN and registrars, there is a point you can directly attack legally, and a root of trust.

Yes, this. DNS and CAs are effectively rooted in internationally recognized legal systems with rules, precedent, and procedure (flawed though they may be). Approaches which circumvent that give up those protections. Which leaves something like “first actor is precedence” and “mightiest compute is rightest.” Maybe theres a technical framework that can address those problems. But I havent seen it before, and its not even mentioned in the parent article.

> With ICANN and registrars, there is a point you can directly attack legally, and a root of trust.

For my use case, that's a problem rather than an advantage, as I'm not a holder of important IP works, trademarks, etc.

Its not that registration requires id. And i dont mean an individual providing gov id. I mean verifying that “store.sony” is managed by a legal entity representing Sony Corporation of America. Basically the entire (ongoing) problem behind DV/EV certs etc. Identity is essentially what underpins trust and dispute resolution.

This paragraph from the blog post doesn't completely address your comment (or even most of it), but it seems useful to have as a reference as I've almost always missed it:

> How Handshake conflicts with ICANN > All 1500 of the existing ICANN TLDs are blacklisted on Handshake for backwards-compatibility. This means that end-users resolving their DNS through Handshake can still access .com domains as normal. New ICANN TLDs can theoretically conflict with Handshake TLDs, but ICANN isn't issuing new TLDs for another few years. When ICANN does issue new TLDs, they’ll only allow at most 500 new TLDs per year. The likelihood of conflict is low even though conflicts can technically happen. In the future, it's up to the community to decide which names take precedence. We believe Handshake names will take precedence because people will find them more useful, and I’ll cover why I think Handshake can gain adoption even in the face of ICANN’s network effects in another blog post.

> When ICANN does issue new TLDs, they’ll only allow at most 500 new TLDs per year. The likelihood of conflict is low even though conflicts can technically happen.

Oh, "only" 500? Out of which a substantial fraction will be common words and therefore likely to be squatted on if Handshake is even remotely popular? I wondered if Handshake was at least trying to reserve English words, but apparently not, judging by this:

    Names which were added _after_ the final snapshot:

    - `charity` - A new gTLD added on ICANN's system.
    - `inc` - A new gTLD added on ICANN's system.

- https://github.com/handshake-org/hs-names/blob/master/README...

Please tell me there's something I'm missing...

> I want to support decentralized name systems

This isn't a coherent thought, which illustrates why they fail. A name _system_ is something you have exactly _one_ of, because otherwise they conflict. To support more than one is to give up altogether, it might actually be slightly worse than just not caring at all.

So you'd need to pick one and then, even if clearly better alternatives are subsequently proposed, you _must_ stick by your choice or you destroy the value of choosing at all. That's clearly a bad idea, you're more or less guaranteeing a sub-optimal outcome for yourself.

I'm not seeing any explanation behind any of your attestations. Are they assumptions?

Saying conflicts are inevitable/unavoidable between name systems seems simplistic: it's a problem to solve. Not necessarily easy, but I know of no hard law making it implicitly insurmountable.

Why does changing name system destroy all value? Sure, changing any system is disruptive and can be relatively destructive; such changes must be weighed against benefits of change, but I see no reason choosing generally better alternatives must destroy all value.

The conflict is intuitively obvious. A name system maps names _to_ something. If system A and system B have the same mapping, that's just the same system under a different name. If they have different mappings they conflict because the mapping will give me different results from system A versus system B. It's that fundamental.

The address bar in Chrome shows both the string as a potential search, and URLs in recent history/tabs with that string. Why wouldn't a Handshake-supporting browser do something similar?

Most alternative domain name systems nest everything under a single TLD – .eth, .onion, etc. In theory, either the standard DNS or a different alternative name system could cause a conflict by using the same TLD themselves. But unsurprisingly, ICANN/IETF are a lot more receptive to "please avoid using this one semi-branded TLD" than "please hand over the entire namespace to us". .onion is already formally reserved by IETF RFC as a "special-use domain name", and hopefully .eth will join it in the future. As for a different alternative name system, conflict over .eth could theoretically happen if Ethereum forks again or if ENS itself is somehow forked, but an independent effort would presumably pick a different name.

Reply on news.ycombinator.com