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.

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

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.

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.