Difference of ENS Domains (.eth) vs Handshake (HNS) domains

How are people issuing SLD domains on their Handshake names? Let's discuss options, tech, and case studies.
Post Reply
User avatar
skyinclude
Posts: 217
Joined: Thu Jan 14, 2021 1:05 am
Location: China
Contact:

Trusted Buyer

Difference of ENS Domains (.eth) vs Handshake (HNS) domains

Post by skyinclude »

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

==== 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
_____________
- SkyInclude/

https://skyinclude.com/ or HNS http://setup.skyinclude :mrgreen:

Image
User avatar
skyinclude
Posts: 217
Joined: Thu Jan 14, 2021 1:05 am
Location: China
Contact:

Trusted Buyer

Re: Difference of ENS Domains (.eth) vs Handshake (HNS) domains

Post by skyinclude »

more insights I am catching from dees
andreyaniv/ — Today at 2:30 AM
How does our hns compare with ens.domains ??
dees/ — Today at 2:44 AM
eh, i don't think anybody's actually worked on writing a nice complete comparison yet
but basically at the high level, ens is centrally controlled where hns is not
ens is not an open root zone, trying to avoid any potential for conflict with the icann root, whereas hns is an open/permissionless root zone that can/will have some collisions but that we may be able to minimize as a community, and ultimately collisions will be resolved at the resolver layer of tools. ens is ethereum based which means a validating node needs to process all of ethereum's chain, not just the ens stuff. HNS is dedicated to being a DNS root zone so it's much more efficient to run a full node. by being a trustless root anchor, we can plug in additional layers of systems onto HNS's root, like with badass domains, and plenty of other stuff coming, so IMO we can kind of have the best of all worlds eventually.
there are problems with HNS, and specifically with potential HNS adoption, i think they can mostly all be solved though
_____________
- SkyInclude/

https://skyinclude.com/ or HNS http://setup.skyinclude :mrgreen:

Image
cjj
Posts: 101
Joined: Tue Feb 02, 2021 1:03 pm
Re: Difference of ENS Domains (.eth) vs Handshake (HNS) domains

Post by cjj »

Thanks @skyinclude
Great knowledge here!
User avatar
skyinclude
Posts: 217
Joined: Thu Jan 14, 2021 1:05 am
Location: China
Contact:

Trusted Buyer

Re: Difference of ENS Domains (.eth) vs Handshake (HNS) domains

Post by skyinclude »

cjj wrote: Wed Mar 17, 2021 3:11 pm Thanks @skyinclude
Great knowledge here!
Ya, so much amazing knowledge lost in those telegram groups - just trying to archive it!
_____________
- SkyInclude/

https://skyinclude.com/ or HNS http://setup.skyinclude :mrgreen:

Image

Post Reply