Difference of ENS Domains (.eth) vs Handshake (HNS) domains
Posted: Tue Mar 16, 2021 11:51 pm
Differences of ENS Domains (.eth) and Handshake (HNS) domains
So still resting up after an epic first HandyCon - Handshake’s first conference - and one of the hottest panels was the “Traditional Domain Ecosystem + Handshake”
Here’s the video replay:
In the panel, we had Brantly from ENS domains sharing “the other side” of the discussion with why ENS feels there isn’t compatibility or interoperability between the 2.
You can listen in to the link above to hear that and more amazing insights.
But afterwards, a lot of chats in Telegram groups - and one thing I try to do here at Handshake Mercenary is capture those amazing insights for a larger group of people to see.
Here’s some epic posts in response
So still resting up after an epic first HandyCon - Handshake’s first conference - and one of the hottest panels was the “Traditional Domain Ecosystem + Handshake”
Here’s the video replay:
In the panel, we had Brantly from ENS domains sharing “the other side” of the discussion with why ENS feels there isn’t compatibility or interoperability between the 2.
You can listen in to the link above to hear that and more amazing insights.
But afterwards, a lot of chats in Telegram groups - and one thing I try to do here at Handshake Mercenary is capture those amazing insights for a larger group of people to see.
Here’s some epic posts in response
==== Dees reply about Ens vs HNS =====
ENS doesn't depend on HNS or on the ICANN root, it's just its own thing, and they decided to avoid letting it conflict, so he was saying if they wanted to they could open up their root zone like how handshake's is open, but they don't want to. to him, there's not a technical advantage to binding ENS and HNS systems together, because mechanically, ENS could just have more TLDs without needing the extra pieces. However, from the HNS perspective, we believe HNS is the right approach to the root zone problem, and that SLD stuff can be layered onto it by cloning ENS or other cross chain integrations or L2 solutions.
yeah the interop discussion is a recurring thing and there are folks on both sides of it philosophically. clearly each system has a strategy to try to account for interop but there are tradeoffs between those strategies, and as brantly pointed out, they are incompatible strategies that can't be reconciled without one side changing their approach. i think most of the hns community wants maximum compatibility but there is a built in expectation that some conflicts can and will occur (some are already pending). some folks want to just say forget the old internet we have a new internet now, no compatibility needed. i think the majority of us would say we want the soft-fork approach that JJ talked about to succeed fully, minimizing or completely avoiding any harmful collisions.
=== Zipkin ====
Matthew Zipkin, [Mar 16, 2021 at 6:04:15 PM]:
My take is that ENS is offering the legacy system "blockchain-as-a-buzzword" not "blockchain-a-solution". Imagine DropBox® telling TLDs "hey we can store your zone files on our servers" and then claiming that "handshake is in conflict with DropBox"
Blockchains are slow, inefficient, and expirimental. The trade off is censorship resistance. If that is not your explicit goal, you don't need a blockchain (arguably)
Brantly also wants us to remember that ENS is not just one TLD (.eth) its "all of them" -- and its because of the dropbox analogy. They are just offering the legacy system a way to put their data on ethereum (IMHO -- for no reason other than to "get with the times")
SO yes, .com and .org and .info "can" use ENS -- but actually the same way they "can" use HNS (DNSSEC proof of ownership)
Big differences are that HNS reserved names expire in 4 years, and maybe HNS will grow into something unexpected by that point
And also HNS consensus rules (reserved list) was set in stone in Feb 2020. So JJ's "soft fork" analgoy breaks down a bit there - its more like a soft fork + timeline split a la back-to-the-future.
Its a soft fork as long as nothing changes in the ICANN root zone after Feb 2020, but this has already happened