search

handshake-org / hsd

Handshake Daemon & Full Node
Other
1.92k stars 278 forks source link

#645+ Handling ICANN Strings in Hard Fork #649

Open dnsguru opened 2 years ago

dnsguru commented 2 years ago

(This carries over from and splits off #645)

Extending the claim period is a good and responsibile idea to put in place, +4 years, +10 years, +25 years, whatever the term is. The downside is that it might diminish the urgency to act which may have had some claim sooner vs defer, but the upside is that Handshake can be seen as a mature and trustable platform.

There are TLDs that should have been set aside as ICANN TLDs that either:

There are also some TLDs (mostly .brand that opted to later not launch) which were in the ICANN root which have been released and could be available in Handshake (ex: .active, .blanco, .boots etc) (see: ICANN gTLDs JSON Report, constantly updated)

It would be good to use this hard fork to address where some TLDs were missed and went to auction - we've discussed this and it seems a bit controversial but the mistakes that let some errors slip through should be fixed. It is problematic and it creates more difficulty in having conversations with large providers to describe that there is name collision now as opposed to it being something to address later for names that have auctioned (.music, .spa, hotels etc).

Originally posted by @dnsguru in https://github.com/handshake-org/hsd/issues/645#issuecomment-945256375

The conversation splits down the line of what to do about a few of the 2012 round ICANN strings that were not included in the bootstrap in Feb 2020 and later auctioned. This includes some Amazon TLDs, .music, .kids, .spa, .hotels and some others.

These force collision between the "ICANN root" versions and the handshake versions of the TLDs that were missed in the bootstrap and got auctioned on handshake and remain unclaimable by the TLD administrators on the ICANN side.

The collision stuff is fueling disinterest in adoption and inclusion by larger institutional / incumbent DNS / Service Providers / Browsers that might otherwise be accellerating adoption of handshake.

The folks who won the auctions on the slipped names understandibly want to keep them.

The adoption challenge will remain thick and sticky until this gets sorted out, so the community needs to decide if the hobbled adoption is more important than the certainty of TLD ownership on this one.

There was a plugin solution for resolvers that was developed as a potential band-aid with the ambition of addressing this at the per-resolver preference level, but institutional large-scale providers seem disinterested in that solution as a bridge to the collisions issue.

It is a bit of a polarized issue. Move large adoption obstacles out of the path on the handful of names that probably should not have been allowed, or leave them in place?

NetOpWibby commented 2 years ago

the upside is that Handshake can be seen as a mature and trustable platform

This is what I care about the most. However, how do we incentivize holders of Handshake names to give up what they invested in? Give them a refund totaling the winning (or second highest) bid? That seems the fairest but would they all do it?

(Also, does someone have a list of existing collisions?)

A rude alternative would be to go ahead with the fork and declare names like music/ inoperable on Handshake 2.0 as-is.

ca98am79 commented 2 years ago

the upside is that Handshake can be seen as a mature and trustable platform

The whole point is that you don't have to trust. You can verify. My company owns the Handshake name kids/ - I can prove this and it is verifiable with the Handshake protocol. You don't need to trust ICANN (or anyone) for that.

It doesn't really matter how things are seen. And by whom? The code is open source, anyone can check it out and come to their own conclusions as to whether it is mature and trustworthy.

The collision stuff is fueling disinterest in adoption and inclusion by larger institutional / incumbent DNS / Service Providers / Browsers that might otherwise be accellerating adoption of handshake.

I am not sure this is true. For example it didn't stop Namecheap (the 2nd largest and fastest growing registrar in the world) to adopt Handshake.

pinheadmz commented 2 years ago

Using a hard fork to reallocate assets will necessarily be controversial, meaning any such attempt to do so will result in a second blockchain. We've seen this exact story play out with Ethereum / Ethereum Classic. If anyone is concerned about name collisions, a controversial hard fork of Handshake will literally double those concerns.

Cryptocurrencies are designed to protect and empower individual users, not large institutions.

dnsguru commented 2 years ago

Namecheap is big, no argument, but they are a sales channel, not a national DNS resolver.

This project is about more than fomo sales and profits, it is about use and adoption too.

Conflating registration and resolution is cognitive distortion. Analog is (registration) Apple sells iPhones, but if only small carrier networks but no national/international carriers support them (resolution) then they are mighty tech but isolated from mass adoption.

In fact, it is a perfect example, to walk it out further... Say Apple developed and sold a few million new iPhone models that they allowed custom area codes on as major features but these were not activatable or carried by the big networks because they re-routed a few actual area codes incorrectly in its firmware because Apple engineers failed to look at the announced area code routing tables, instead opting for what was in the phone book at the time.

Despite the excitement over the technical capability of these special phones wifi or other features, the carriers won't add these phones while they reroute a few of the conflicting area codes, and a handful of folks entrench on their custom area codes that conflict at the end result of 2 million bricked iPhone devices that can only work to make calls on wifi or spotty isolated regions.

Folks want them to work all over the place, naturally, universally.

Move the barrier.

We just need to put a link to this issue and #649 in the pinned message on telegram in response to "wen cloudflare"

encirca-handshake commented 2 years ago

Regarding a hard fork for Handshake to address reserved strings, here are my thoughts:

It would be useful to develop some principles and policies to be governed by. Here are a few:

  1. Do not be the initiator of namespace collisions. Respect pre-existing ICANN TLD namespaces. In its next TLD round (like the first), ICANN will need to address the potential harm that it would cause by delegating TLDs with namespace collisions.

The original intent of Handshake was to be backwards-compatible with ICANN But it missed a few TLDs that were still in the ICANN pipeline. These should be clawed back and placed on the reserved list.

This isolates the namespace collision issue to one where ICANN is initiating namespace collisions rather than Handshake.

In terms of collisions with other alternative DNS (UD, Butterfly, etc.) , I propose that these can be ignored.

  1. Have a mechanism to mirror the retirement of ICANN TLDs ICANN has processes for the retirement of both gTLDs and ccTLDs. As ICANN removes TLDs from the root zone, then Handshake should mirror these removals. See: https://ccnso.icann.org/sites/default/files/field-attached/pdp3-retirement-final-report-08jun21-en.pdf https://www.icann.org/resources/pages/gtld-registry-agreement-termination-2015-10-09-en

  2. Maintain backwards compatibility with ICANN TLDs Forever There should not be an expiration date for claiming reserved ICANN TLDs. ICANN TLD Registries may never claim their reserved Handshake TLD and Handshake should be able to accept this.

Otherwise, if these reserved ICANN TLDs are released, then Handshake becomes the initiator of namespace collisions, which violates the first principle above.

  1. If there is an ICANN TLD application for a string that is still available on Handshake, then it should be automatically reserved on Handshake. This helps with compatibility with the ICANN Root and prevent Handshake as the initiator of collisions.

5 Maintain a plan for the expiration of reserved website domains The initial reservation of the top 100,000 Alexa-ranked websites was a crude anti-cybersquatting policy that merely used the Alexa list as a proxy for the top trademarks. I would allow these reservations to expire provided this expiration occurred after the next list of ICANN applications were announced to minimize the potential for namespace collisions.

The reservation of these should expire, since there are also legitimate non-infringing uses for trademarked strings, especially if they are dictionary words. To discourage cybersquatting, see the next policy.

I suspect there is a significant overlap between the reserved Alexa list and the strings that will be applied for in the next ICANN TLD round. So, perhaps the timing of unreserving Alexa names could be event-driven: i.e it occurs only after ICANN publishes its list of submitted TLD applications, so that the overlap can be moved to the reserved ICANN TLD list before the Alexa names expire.

  1. Develop an Anti-cybersquatting Policy (or Acceptable Use Policy) and Mechanism Develop a future-proof Anti-cybersquatting/Acceptable Use Policy AND mechanism for blacklisting TLDs.

There are likely many famous trademarks that do not operate stand-alone high traffic websites and thus were not included on the Alexa list. And new global famous trademarks have emerged since Handshake has launched and continue to emerge.

How will Handshake discourage cybersquatting of these trademarks?

Beyond trademarks, there are also TLD uses that should be discouraged, since as Child Trafficking. How will the Handshake community police unacceptable uses of Handshake?

NetOpWibby commented 2 years ago

The original intent of Handshake was to be backwards-compatible with ICANN but it missed a few TLDs that were still in the ICANN pipeline. These should be clawed back and placed on the reserved list.

I somewhat agree with this but this statement brought a question to mind...what if ICANN sees a Handshake name doing well and wants to create it on their side? There's a lot of talk about users of Handshake respecting ICANN. Is this respect reciprocal?

Beyond trademarks, there are also TLD uses that should be discouraged, since as Child Trafficking. How will the Handshake community police unacceptable uses of Handshake?

Johnny Wu of Namebase has a burner wallet that people have sent names to.

encirca-handshake commented 2 years ago

Forget about reciprocal respect. ICANN isn't on the other side. Instead, it is some corporation or entrepreneur or speculator (hoping to be bought out).

Voluntary submission to a burner wallet isn't going to cut it.

The issue-du-jour is "DNS Abuse". The heavyweights are gearing up...https://www.fastcompany.com/90686579/blockchain-domains-bit-microsoft

pinheadmz commented 2 years ago

@NetOperatorWibby

Johnny Wu of Namebase has a burner wallet that people have sent names to.

This doesn't make sense. The names will just expire and back to auction. If we really wanted to burn a name it should be sent to an anyonecanrenew address and the community will have to keep the name alive, with no dns data, and keep it off the auction block. Even this strategy won't be bulletproof as fees rise on chain and renewal fees aren't fun anymore.

befranz commented 2 years ago

Regarding a hard fork for Handshake to address reserved strings, here are my thoughts:

I agree with Encircas post with a few comments:

But it missed a few TLDs that were still in the ICANN pipeline. These should be clawed back and placed on the reserved list.

ICANN TLDs which were not reserved by mistake in the beginning should become reserved via hard fork (of course just if community voted for). The current owner (who was probably aware of the mistake) should get (double?) the amount of HNS of the highest bid.

If there is an ICANN TLD application for a string that is still available on Handshake, then it should be automatically reserved on Handshake.

I disagree to reserve any ICANN TLDs in the future. Neither is it possible to quickly reserve a name (which takes a hard fork) nor do I think that such a name would still be available on Handshake.

Develop an Anti-cybersquatting Policy (or Acceptable Use Policy) and Mechanism Develop a future-proof Anti-cybersquatting/Acceptable Use Policy AND mechanism for blacklisting TLDs.

Law enforcement has ways to seize Bitcoin so are ways to seize Handshake TLDs. I guess it's even easier to get the owner of a name since for a working domain you need also nameserver and host, so a lot of traces... And if government can seize a name they can give it to the right owner or prevent using it.

pinheadmz commented 2 years ago

@befranz

ICANN TLDs which were not reserved by mistake in the beginning should become reserved via hard fork (of course just if community voted for). The current owner (who was probably aware of the mistake) should get (double?) the amount of HNS of the highest bid.

Namebase owns .music - the community should persuade them to "claw back" this name. I'd 1,000,000% rather ruin Namebase's reputation as a custodian than ruin the Handshake blockchain's reputation for securing private-key-secured bearer assets.

@encirca-handshake

The original intent of Handshake was to be backwards-compatible with ICANN But it missed a few TLDs that were still in the ICANN pipeline. These should be clawed back and placed on the reserved list.

A blockchain project that claws back user's assets is a dead project in my opinion. We can argue over the founders' "intents" with the reserved list but I guarantee you they did NOT intend for an authoritarian organization of people especially a for-profit corporation like MMX co-founded by Jothan Frakes aka @dnsguru to HIJACK the protocol.

Users in support of this corporate take-over should learn about the Ethereum Classic hard fork, and the SegWit2x (failed) hard fork. The community can decide to do whatever it wants but I promise I will personally not merge code to handshake-org/hsd that claws back user's assets.

befranz commented 2 years ago

I have to correct myself. There are currently 3 name conflicts between Handshake and IANA TLD list xn--4dbrk0ce ישראל (Israel) xn--cckwcxetd アマゾン (Amazon) xn--jlq480n2rg 亚马逊 (Amazon)

which I guess occurred after Handshake Mainnet start. music. is not even on the IANA list today. So there's not even a reason to correct any mistakes since there's none.

dnsguru commented 2 years ago

A blockchain project that claws back user's assets is a dead project in my opinion. We can argue over the founders' "intents" with the reserved list but I guarantee you they did NOT intend for an authoritarian organization of people especially a for-profit corporation like MMX co-founded by Jothan Frakes aka @dnsguru to HIJACK the protocol.

@pinheadmz this appears to be a bit of a personal reputational attack. You're better than that.

The problem with it besides it being offensive and frustrating because of all the effort I put in to evolving this project, is that factually it is as ham-fisted as the founders' understanding of ICANN that led to the mistakes in the bootstrap.

Yes, I helped co-found MMX and worked there in 2009-2010, which is two years before MMX applied for any TLDs in 2012, and although they were one of the ten applicants for .music in the 2012 round, they did not end up prevailing as the party who ultimately secured the TLD through the ICANN application process.

I get frustrated too, but don't make it personal.

pinheadmz commented 2 years ago

the founders' understanding of ICANN

...is what led to the invention of Handshake.

pinheadmz commented 2 years ago

they did not end up prevailing as the party who ultimately secured the TLD through the ICANN application process.

Apologies. 🙏

befranz commented 2 years ago

There are also some TLDs (mostly .brand that opted to later not launch) which were in the ICANN root which have been released and could be available in Handshake (ex: .active, .blanco, .boots etc) (see: ICANN gTLDs JSON Report, constantly updated)

You guys do have so much more background in this space, can you explain why the names you mentioned are not in the current IANA TLD list? Wouldn't it be better to clean up the disprepances between ICANN and IANA or at least mark names with a status to understand the difference? And even on IANA site there's a second list which is different again.

And last question, how do you recommend to solve conflicts between Handshake and 'constantly updated' list by ICANN?

Edit: Just checked .active, .blanco and .boots in ICANN gTLDs JSON Report they have a removalDate 2018/2019!!

And here's dateOfContractSignature of .music, please note : 2021-05-04 (May the Fourth be with you ;-) - 2021)

dnsguru commented 2 years ago

I have to correct myself. There are currently 3 name conflicts between Handshake and IANA TLD list xn--4dbrk0ce ישראל (Israel) xn--cckwcxetd アマゾン (Amazon) xn--jlq480n2rg 亚马逊 (Amazon)

Israel launched a Hebrew language version of its ccTLD (.il), and the two Amazon IDN were caught in the conflict queue along with .amazon (but this was caught by the alexa list) as the TLD for the brand worked out their matter where there were objections from the South American countries that regionally held some rights to dispute it.

which I guess occurred after Handshake Mainnet start.

Yup

music. is not even on the IANA list today.

Because it got unconflicted, then contracted, and then gets added to the root zone. Doesn't mean it doesn't exist any more than a name that is sitting in reveal on handshake isn't real

So there's not even a reason to correct any mistakes since there's none.

Thats a tad entrenched, but I get that argument. This is the perspective that the founders just took a snapshot of whatever was in the root zone at the time and it had some stuff and missed some stuff. This is a perfectly valid point of view, and from the perspective of anyone who picked up one of the conflicting strings, it makes sense to frame things this way.

So let's say there are about a dozen (maybe TLDs) that had been created in the 2012 round but were not in the root due to de-conflicting delays and other guard rails against name collisions. The conflicts were thornier and those took longer, but didn't appear in a cornfield suddenly, unless one choses to look at the IANA list or root zone in isolation.

The challenge with this perspective on handling the matter of the collisions with exsting domains, perhaps even more hard-edged than using the ICANN Json resource, is that it carries a message to large institutional carriers, DNS Infrastructure, browsers etc that the founders of handshake completely missed some really obvious stuff like this, which begs the question, what else did they miss. It erodes confidence in the project as viable or safe to embrace.

While taking the 'it wasn't in the root' preserves the dozen or so TLDs that slipped through in conflict with the published json list and the ngtld portal that listed all the 2012 round applications, it does so at the cost of diminishing overall handshake adoption in the wild.

Parties that could have quite a transformative impact on the project like cloudflare or major browsers watch these threads for how these matters are addressed or not have done the "alt-root" dance a few times already, and are already in 'no thank you' mode.

If we leave this as-is, those dozen or so TLDs that really should not have been allowed into auction are absoluately in the way of a good answer to wen cloudflare

And last question, how do you recommend to solve conflicts between Handshake and 'constantly updated' list by ICANN?

The gTLD conflicts don't just pop up magically in a corn field. There was a 2012 round - period. The results are in the queue. That queue was either unknown or ignored. To say that list is "constantly updated" is less unpredictable if one uses the ICANN json and not the root zone or IANA list.

There is a process under way within ICANN called 'subpro' or 'subsequent procedures' that is likely 18-36 months from delivering a new TLD round, and that is a W.A.G. estimate that seems to constantly slip. By addressing the gaps to those known in a manner that Tom Barrett and I are identifying, it makes the issue of name collission less a thing until such time as that round opens, and by then this community will have all kinds of remedy or answers to questions about this that are not present today.

Edit: Just checked .active, .blanco and .boots in ICANN gTLDs JSON Report they have a removalDate 2018/2019!!

I enumerated a few examples but the principle there was to not only have names get taken from auctionees (if the community opts that) or switch lists, but also to make available some TLDs that the ICANN side of things dropped so those are available to people in the handshake.org namespace.

And here's dateOfContractSignature of .music, please note : 2021-05-04 (May the Fourth be with you ;-) - 2021)

Good star wars reference - nerd respect active. Anyways... Correct on that date. Pretty similar topic on most all of the conflict domains, but .music seems to be the focus of your comments. Although all 10 of the applications for .music were applied to ICANN in 2012, the conflict resolution process to narrow down to the (there can only be one) "Highlander" situation down to the sole party that ultimately was delegated the ICANN TLD.

There are a number of other stories of conflicts that had to get untangled, but all stem from a predictable, publicly available list of strings that were applied for in 2012.

The objective here is to get handshake better answers to the conflict and name collission stuff as it is big obstacle for how usable the rest of the names can be.

Path A: Clutch tightly to 12ish names but hobble confidence from vendor/service for 2M others Path B: hobble 12ish names to move those obstacles + demonstrate this is a serious trustable project

dnsguru commented 2 years ago

they did not end up prevailing as the party who ultimately secured the TLD through the ICANN application process.

Apologies. 🙏

It was a 'forced alumnist' situation so I have no level of butthurtedness over them not prevailing. I moved on to other things.

It was just a wierd thing to have a job from 12 years ago thrown up as some reason I am motivated here (or?)

The timing, while I am in the middle of being asked by other community members to coach others in the handshake community on how to speak and engage during the ICANN 72 meeting (on right now https://72.schedule.icann.org) about the handshake project and engage in a productive manner with that community... ain't nobody got time for that kind of demotivational stuff.

faltrum commented 2 years ago

First of all, I want to express my sincerely respect for all of you and your opinions. I will be direct and short in my opinion. There is a very beautiful and seriously solution: Path C: ICANN claim his Handshake TLD, so claim 24000000 HNS, with that coins ICANN can buy the 12 TLD. Everybody win: ICANN, HAndshake community (no division in this Hardfork), the ICANN owners and HNS Owners. The best part is Path C is quickly and HNS dev can help ICANN members to claim it through Bob-Wallet claim button. Thank you for read me.

NetOpWibby commented 2 years ago

So right now it appears that the consensus is that there is no consensus.

Industry (or corporate/incumbent) adoption seems to be the goal. However, many users of Handshake are quite tired of how things have been. Deference to corporations is decidedly anti-cypherpunk, even with the best intentions...which, the original authors of Handshake built the blockchain with.

What I see happening is this: we'll agree to disagree and user adoption will drive industry adoption — not the other way around. ICANN's continued planned round slippage keeps moving back in our (Handshake's) favor.

While there is power in being the default and included in every shipping operating system, crypto-native folks are no strangers to augmenting their devices with additional software to achieve what they want. My mom knows what a smart contract is and I gave her her Handshake name. Public awareness is only a matter of time and ICANN is all too keen to (unintentionally) provide us this gift.

What everything will boil down to is a browser/extension setting asking users which namespace they want to access.

🤷🏾‍♂️

NetOpWibby commented 2 years ago

@faltrum That's actually pretty genius. It's not like ICANN would be losing money.

faltrum commented 2 years ago

@faltrum That's actually pretty genius. It's not like ICANN would be losing money.

I think could be a great solution, everybody win.

ca98am79 commented 2 years ago

The challenge with this perspective on handling the matter of the collisions with exsting domains, perhaps even more hard-edged than using the ICANN Json resource, is that it carries a message to large institutional carriers, DNS Infrastructure, browsers etc that the founders of handshake completely missed some really obvious stuff like this, which begs the question, what else did they miss. It erodes confidence in the project as viable or safe to embrace.

I don't understand how you come to this conclusion. A line had to be drawn, and it was drawn. .music wasn't in it and so it didn't make the cut. Do you propose that ICANN be the root of trust for Handshake? That is to say, should we claw back any new ICANN TLD? Or do you want to draw a line in the sand, but you want it to be at some later point (presumably after .music is clawed back)?

I don't see it as the founders missed anything, I see it simply that a line had to be drawn and it was drawn with the root zone at the time it was drawn. You can't keep moving it / changing it. The line was drawn and now it is Handshake's turn to control the root zone.

dnsguru commented 2 years ago

Path C: ICANN claim 24000000 HNS

I admire the creativity of this community in finding alternative paths forward.

Utopian idea, but this has low odds, unfortunately. On a good day I would give this a 2-3% chance, knowing how risk-averse and careful review would be at ICANN, they would probably spend whatever it's equivalent fiat on legal / financial / security reviews.

Most folks familiar with ICANN understand that this suggestion needs to be presented in a nuanced way to have a chance.

The leadership and community at ICANN may be entirely unaware of the claim being available.

Would be worth someone stepping up at the public forum during the current ICANN 72 meeting to mention the handshake project claim, the claim and its equivalent usd value, and do so without much other said.

There are a set of people from within the ICANN community who are watching the discussion, and it is good, where we can, to convince them there is a community that respects what it is building upon the shoulders of, that it understands how to expand the namespace responsibly and there is appetite for more than just mercenary commercial interests going on.

NetOpWibby commented 2 years ago

Most folks familiar with ICANN understand that this suggestion needs to be presented in a nuanced way

The leadership and community at ICANN may be entirely unaware of the claim being available.

There are a set of people from within the ICANN community who are watching the discussion

Seems like the ball is in y'all court.

dnsguru commented 2 years ago

Mobile client ; bumped wrong button

dnsguru commented 2 years ago

I don't understand how you come to this conclusion. A line had to be drawn, and it was drawn. .music wasn't in it and so it didn't make the cut. Do you propose that ICANN be the root of trust for Handshake?

No, I am saying that the runner sharted at the firing gun and needs new underwear.

That line is brown and needs a bleaching to clean up some "farticles"

That is to say, should we claw back any new ICANN TLD?

Just those which existed from various stages of application in 2012. I keep saying this, it is not a new or growing list.

Or do you want to draw a line in the sand, but you want it to be at some later point (presumably after .music is clawed back)?

I want this project to get wider adoption before facing collision issues

I don't see it as the founders missed anything, I see it simply that a line had to be drawn and it was drawn with the root zone at the time it was drawn.

I think this is a split of perspective based upon what one wants to select as the approach that supports one outcome or another.

But they totally missed the existing TLD list for all practical intents and purpose, otherwise there would not be collisions

You can't keep moving it / changing it.

Nothing moved. The wrong line was chosen

The line was drawn and now it is Handshake's turn to control the root zone.

This would imply it has been demonstrated handshake could be trusted to do that in a way that could be possible, with things like rectifying the shart

befranz commented 2 years ago

Just those which existed from various stages of application in 2012. I keep saying this, it is not a new or growing list.

Just for the sake of clarity, can you name it?

dnsguru commented 2 years ago

Just those which existed from various stages of application in 2012. I keep saying this, it is not a new or growing list.

Just for the sake of clarity, can you name it?

Sure, Here is the link to the ICANN 2012 Round gTLD Portal

In the brief window that was open in 2012 to do so, there were 1933 applications filed, many of which were multiple parties interested in the same TLD. No new rounds or application opportunities have occurred since 2012, but the evaluation and contracting for these took time so TLDs started to hit the root around late 2013 for them, and some have taken longer t han others. Click on Contention Sets link from the page link above - those would have to get sorted out before going to contract and then into the root.

This data has all been there - the list of TLDs was static at the point they closed the round in 2012.

befranz commented 2 years ago

It's funny to tell me to sort things out myself to get the names. Thanks, I'm out.

dnsguru commented 2 years ago

must have been a language misunderstanding of "can you name it"

maybe you were asking for a list of conflicted domans and not a link to the resource that had been there since 2012 ?

befranz commented 2 years ago

Ok, obviously a misunderstanding. I wanted to ask you if you can name the names/domains - explicitely - which create conflicts and you want to get solved.

kibagateaux commented 2 years ago

Just some meta-commentary on the thread so far

Ok now on to lengthy argument as i am so want to do :)

I empathize with the argument to not clawback assets but this is an incredibly small scope with clearly defined criteria and precedence. This is not an undefined, arbitrary change that violates first principles of Handshake. It is an unfortunate situation that we are in but one do to a bug in the implementation of Handshake itself and now we have the opportunity to fix it. For perspective there are over 2.6 million TLDs registered on Handshake so far meaning this change would affect only 0.0002% of all Handshake domains. (can update stat if conflicted TLD number changes) We can probably count the unique individuals that are affected on one hand, will we let the tyranny of a small minority prevent us from making a critical improvement to the protocol?

I do believe that HNS would still be useful and valuable even if it doesn't become the global root zone. But it would only ever be useful to us. It would be hard to give the freedom and security that we strive for ourselves to others without it being THE root zone. Advocating for a shortlist of investors (see below why only this stakeholder matters in this proposal) jeopardizes the success of the project and introduces security risks for nontechnical users that might not even know that Handshake vs ICANN differences exist or which conflicting TLD they are or should be accessing. At the end of the day it is our job to maintain the global common namespace for ALL users of the internet. For such an outsized impact for the greater good, I find it hard to believe that an owner of a conflicted Handshake domain wouldn't advocate for this change and if they dont advocate it I would question our responsibility to them as a community.

I think there are 3 main stakeholders at play here - DNS infrastructure providers, self-sovereign domain users, and TLD investors.

DNS Infrastructure - Pretty obvious standpoint. They will not support Handshake if it conflicts with ICANN. Handshake can try to rebuild the global internet infrastructure on its own but considering the difficulty in funding basic protocol development already, it is safe to say we are dependent on these service providers for any large scale adoption.

Self-sovereign domain users - These are just your average TLD owners. They like owning their name and knowing that it is verifiably theirs. They think it's pretty cool that all these weird domain names actually work, partially because they don't even know how its possible. They may or may not believe in all the values of crypto and Handshake. This policy will affect 0% of these users! Even if we mirrored ICANN forever and revoked any TLD they create this policy wouldn't affect 99.99~% of these personal/niche/shitpost domains because only mainstream domains would be tolerable and profitable for large scale companies to go through the capital intensive ICANN process.

TLD investors - Speculators and scalpers that only want to monetize TLDs through resales or SLD sales. Realistically these are the only stakeholders at risk in this proposal because they are the only domains worth going through the ICANN process. Obviously not ideal to "lose" "your" domain investment but as speculators they are aware of the risks and a full loss should be calculated and accounted beforehand. This proposal states that these names should have been reserved since genesis block and should never have been available for auction. But lets say there wasnt a bug and you do rightfully own it, lets keep in mind that this proposal doesn't constantly revoke TLDs in the future putting all of your assets at risk. These investors likely own a diverse portfolio of TLDs. It is better to get full refund on your purchase and lose upside in one asset in order to derisk and increase potential value for the rest of you portfolio. Sure one of the domains you used to own might have been worth millions, but overall your portfolio is much bigger in absolute terms than it would be if you don't get a refund for your domain.

So effectively this proposal affects almost no one and even for those that it does affect negatively in the short term, in the long term the change will have a much larger positive impact on them.

Most importantly there's nothing to prevent anyone from forking Handshake into a new chain and implementing these changes themselves, improving their chances of adoption. You should hope that it is a hardfork and you retain your existing assets on Handshake onto this new chain but realistically (or at least what I would do if I had no allegiance to Handshake) it would be an entirely new chain and you will have to buy your TLDs and coins all over again. Investing in a new chain reduces your profitability as well and delegitimizes Handshake more than clawingback assets that theoretically shouldn't have been available on Handshake in the first place.

In order to be THE root zone Handshake MUST be compatible with the original root zone. Otherwise we are a just another alternative namespace and have failed at our mission. With foreign governments building independent infrastructure to replace systems that have historically been controlled U.S interests, such as the European Union's Galileo program to replace GPS, it is possible that we could see nation state adoption of Handshake as credibly neutral infrastructure.

"Furthermore, Galileo provides Europe and European citizens with independence and sovereignty" - EU Space Program

ICANN policies like mandatory data collection for WHOIS in conflict with GDPR regulation creating friction, that could tip the balance in our favor. However, a government would never adopt Handshake if we aren't in synch with ICANN, putting citizens at risk for phishing cyberattacks, fraudulent domain sales, etc.

As a cryptoanarchist I really do wish that this situation could be avoided its short sighted and zero-sum to say that this proposal only has negative affects and could potentially kill handshake. If anything i think the opposite is true, there is almost no downside and massive upside to the potential. I recognize this challenges the sovereignty of Handshake and its users but I would like to think of us as a community and that the affected community members see this is a good decision for all of us and support it.

NetOpWibby commented 2 years ago

I don't disagree...I'd like confirmation from the ICANN guys about other conflicts, if we missed any.

Also, what about future ICANN gTLD rounds? They're gonna happen...eventually. Will the conversation of forking come up again?

Whatever happens right now should be done so with the clear expectation that future conflicts won't be accommodated. This proposed hard fork is fixing an oopsie that shouldn't have happened in the first place (and maybe adjusting other things people smarter than I see as slight annoyances within Handshake).

befranz commented 2 years ago

dnsguru commented on 27 Oct 2021 The leadership and community at ICANN may be entirely unaware of the claim being available.

Would be worth someone stepping up at the public forum during the current ICANN 72 meeting to mention the handshake project claim, the claim and its equivalent usd value, and do so without much other said.

Just for reference, recorded on 28 Oct 2021 https://thenamesdontresolveinwhatwecalltheinternet/

encirca-handshake commented 2 years ago

I think this discussion should include a more near-term threat facing Handshake. The main threat to Handshake right now is that blockchain domains are being perceived as a haven for cyber-criminals. The “minor” distinctions between Handshake, Unstoppable Domains, Butterfly and ENS do not matter.

I am new to Handshake but fully embrace its potential. I do not see it replacing ICANN. Instead, it will enable the long tail of TLDs for individuals and businesses who are unable or unwilling to go through the ICANN application process.

As someone who has been involved in the domain name space since before the formation of ICANN, I have this observation to make: The ICANN community that has spent 20+ years building the DNS regulatory framework is increasingly viewing the blockchain as an existential threat to their DNS governance role.

And as Chair of the Blockchain Committee for the International Trademark Association, interest in the threats and opportunities from blockchain domains is intensifying. Right now, the threats are over-whelming the opportunities.

Microsoft ALREADY flagged blockchain domains for potential DNS abuse. In their October, 2021 report, Microsoft Digital Defense Report OCTOBER 2021, they say “blockchain domains have become a preferred choice for cybercrime infrastructure” and “The next big threat: “Forever” (blockchain) domains” (just do a search for “blockchain” in the report) (https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWMFIi)

ICANN is also raising the alarm here (January 5, 2022): Relying on ICANN Community-Developed Processes for a Safe, Secure Internet (https://www.icann.org/en/blogs/details/relying-on-icann-community-developed-processes-for-a-safe-secure-internet-5-1-2022-en) and here (November 24, 2021): Buyer Beware: Not All Names Are Created Equal (icann.org) (https://www.icann.org/en/blogs/details/buyer-beware-not-all-names-are-created-equal-24-11-2021-en)

One recently staked Handshake TLD is “.c0m” that substitutes the letter o with a zero. Do not be surprised to see this TLD making headlines in 2022 as another shining example of how blockchain domains can be exploited by cyber-criminals to defraud consumers.

And finally, the 5-10 missed ICANN TLDs will also be publicized in the near-term as an example of blockchain’s abuse of the DNS.

Defending against all this will be a HUGE distraction and hinder the adoption and success of Handshake.

In this context, here are some general principles for your consideration:

  1. Handshake should not be the initiator of namespace collisions. Respect pre-existing ICANN TLD namespaces. Handshake adhering to this principle will force the ICANN community to decide if they want to introduce collisions against blockchain TLDS, such as Handshake.

The next round of ICANN TLDs will be in 4-5 years’ time. I predict MOST of these applications will overlap with the Alexa100K list and will be claimed before the reserved status expires. So, I do not see a lot of Handshake collisions happening in the next ICANN round.

I participate in ICANN’s Names Collision Advisory Process (NCAP). NCAP is focused primarily on root server error traffic. In 2012, 95% of applied-for strings had such error traffic. All new TLDs were required to undergo a controlled interruption process to alert users generating this error traffic.

The DNS has evolved in 10 years. NCAP will be releasing a draft report this month that reveals that root server traffic in 2022 do not have visibility to 30% of all potential TLD collisions—instead, these non-root TLD “collisions” are seen only by public dns resolvers. Thus, in 2022, the controlled interruption method would not mitigate 30% of potential TLD collisions.

ICANN will be forced to address these non-root TLD collisions before delegating more TLDs.

  1. How to handle the 5-10 ICANN TLDs that were not reserved? The original intent of Handshake was to be backwards-compatible with ICANN. But it missed 5-10 TLDs that were still in the ICANN pipeline.

If not addressed somehow, these 5-10 Handshake TLDs will be shining examples of why blockchain TLDs are a huge risk of potential harm to consumers.

Allowing these small number of Handshake TLDs to collide with ICANN TLDs in 2022 will put Handshake supporters on the defensive and risk being labelled as “bad actors”.

In other words, this will be a distraction and inhibitor to gaining further adoption of Handshake.

I do not think there should be a hard or soft fork just to claw these back. But I do think the owners of these TLDs should voluntarily return them for the good of Handshake. Otherwise, they WILL continually be publicized as examples of DNS Abuse by Blockchain domains by the ICANN, Microsoft, Brand protection providers, etc.

  1. Maintain the current Handshake plan for the expiration of reserved ALEXA website domains

The initial reservation of the top 100,000 Alexa-ranked websites was a crude anti-cybersquatting policy that merely used the Alexa list as a proxy for the top trademarks. Many of these strings have legitimate non-infringing uses. If not claimed, they should be released for general registration per the current schedule. I predict most of these will be claimed by the trademark owners anyway before the Handshake expiration date: aided and abetted by brand protection providers and new TLD consultants.

  1. Handshake/Namebase should have an “Acceptable Use Policy” Criminal activity should be discouraged. Problematic TLDs include:
    • TLDs with unacceptable content
    • Homograph TLDs
    • TLDs that impersonate brand owners
    • Colliding TLDS (discussed later)

Unacceptable Content: How will the Handshake community assess and police unacceptable uses for Handshake? (i.e., child sex trafficking). What is the mechanism to blacklist TLDs deemed not acceptable to the community?

Homographs: There are TLD strings that should be discouraged, such as TLD Homographs that could be used to confuse, mislead, and defraud consumers. See What is an IDN Homograph Attack and How Do You Protect Yourself? (zvelo.com). (https://zvelo.com/what-is-idn-homograph-attack-protect-yourself/#:~:text=An%20internationalized%20domain%20name%20%28IDN%29%20homograph%20attack%20is,used%20to%20lure%20users%20to%20the%20new%20website.)

ICANN already requires ICANN TLDs to police this. See ICANN Statement on IDN Homograph Attacks and Request for Public Comment. (https://www.icann.org/en/announcements/details/icann-statement-on-idn-homograph-attacks-and-request-for-public-comment-23-2-2005-en)

Donuts, the registry with the largest portfolio of names has made this their predominant market positioning: TrueName Home - TrueName by Donuts saying “Our advanced anti-phishing technology blocks imposters by preventing registrations that spoof your domain name.” (https://truename.domains/)

Handshake should have a policy to prevent IDN Homographs – which is prohibiting the use of more than one IDN script in characters comprising a given TLD label. I do not know if Handshake homograph TLDs have already been registered and would be impacted by such a policy. If we become aware of them, we would blacklist them. And I would discourage Namebase and others from not staking them.

Regarding the Handshake “.c0m” TLD that substitutes a zero for the letter o. I see no redeeming value to a TLD that appears designed to confuse consumers. Although EnCirca supports every Namebase-staked TLD, EnCirca has flagged the “.c0m” TLD and a few other obvious trademark infringements for special processing where we will process the SLD order only if the registrant can demonstrate rights in the corresponding .com domain or trademark. We will lobby other registrars to do the same.

FORK OR NOT? I do not think a fork is necessary to address the issue above. But if a fork were to happen, here are some other issues to consider.

  1. I would maintain the reservation of ICANN TLDs Forever. There should not be an expiration date for claiming reserved ICANN TLDs. ICANN TLD Registries may never claim their reserved Handshake TLD, and Handshake should accept this since Handshake should not be introducing collisions. This isolates and reinforces the namespace collision issue to one where only ICANN is initiating future collisions rather than Handshake.

I do not see many ICANN TLD claims happening in the current climate. There are two major reasons why: A. ICANN is discouraging it. You have all seen the recent domainincite.com blog post. ICANN is blocking 23 gTLD transfers over blockchain fears - Domain Incite (https://domainincite.com/27303-icann-is-blocking-23-gtld-transfers-over-blockchain-fears)

Here is ICANN’s January 5 response: Relying on ICANN Community-Developed Processes for a Safe, Secure Internet. (https://www.icann.org/en/blogs/details/relying-on-icann-community-developed-processes-for-a-safe-secure-internet-5-1-2022-en) One of my clients cancelled claiming their reserved Handshake TLD last week due to concerns over this.

B. TLD registries need cooperation from the Back-end registry providers providing the TLD’s HSM. Do not under-estimate the potential competitive threat they perceive from Handshake to their business model.

  1. Have a mechanism to mirror the retirement of ICANN TLDs ICANN TLDs are not forever. Already, over one hundred from the 2012 have been removed from the root. As ICANN removes TLDs from the root zone, then Handshake should mirror these removals by removing these strings from the reserved names list. ICANN has processes for the retirement of both gTLDs and ccTLDs. See:

I look forward to continuing this discussion!