hsd
hsd copied to clipboard
handshake-org
#645+ Handling ICANN Strings in Hard Fork
(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:
- went to auction and were acquired (ex: .music, .spa, hotels etc); or,
- were placed in the alexa list instead of the ICANN list (ex: .web etc)
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?
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.
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.
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.
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"
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:
- 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.
-
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
-
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.
- 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.
- 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?
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.
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
@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.
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.
@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.
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.
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.
the founders' understanding of ICANN
...is what led to the invention of Handshake.
they did not end up prevailing as the party who ultimately secured the TLD through the ICANN application process.
Apologies. 🙏
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)
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
dateOfContractSignatureof.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
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.
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.
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.
🤷🏾♂️
@faltrum That's actually pretty genius. It's not like ICANN would be losing money.
@faltrum That's actually pretty genius. It's not like ICANN would be losing money.
I think could be a great solution, everybody win.
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.
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.
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.
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
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?
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.
It's funny to tell me to sort things out myself to get the names. Thanks, I'm out.
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 ?