Conflict issue with pending ICANN TLDs: .MUSIC .KIDS .HOTEL et al

[dnsguru]

I have peripherally followed this project over the past few years, and was in Montreal at the ICANN meeting and I had the chance to hear Boyma present Handshake. I have heard the marketing pitch repeatedly, and there's some potential here in HNS / Handshake, where @chjj should be applauded.

This project is gaining some traction, which is good, and folks are spending HNS to get into auctions on names. It sounded like the fork point on legacy root and evergreening existing stuff had been handled well, but I noticed some stuff got overlooked in that process.

This hs-names project seems to have some promise - in the spirit of helping it forward I did some research and caught some TLD related stuff that needs IMMEDIATE attention.

tl;dr: Revise the TLD list

This project missed a lot of sources for blocking things like upcoming ICANN TLDs when gathering the evergreen list of TLDs to be set aside and need to address this immediately.

1. Go here:
   https://gtldresult.icann.org/applicationstatus/viewstatus

2. In the grey box "CURRENT APPLICATION STATUS", you will want the following statuses from the drop-down: "Applicant Support", "In Contracting", "In PDT" and "On-hold"

This will reveal the following TLDs:

• .AMAZON - Blocked by alexa approach, good
  • .アマゾン ("Amazon" in Japanese) Punycode: xn--cckwcxetd This has auction slated for January 2021
  • .亚马逊 ("Amazon" in Chinese) Punycode: xn--jlq480n2rg Auction available
• .HOTEL This has an auction slated for December 2020
• .IDN This one closed April 22, 2020
• .KIDS This has an auction slated for July 2020
• .MUSIC There is a TLD in reveal phase that conflicts
• .SPA - Blocked by alexa approach, good
• .WEB - Blocked by alexa approach, good
• .WEBS - Blocked by alexa approach, good

3. Add the missing ones. I didn't look to see if any of them have been auctioned or assigned, other than noticing the auction for .MUSIC - and a quick look revealed that .MUSIC and .WEB were not present in the TLD list here.

4. Address the conflict proactively. Your call on addressing HNS TLDs that collide with these if they have already been auctioned.

I hope you can turn those chips back into potatoes.

The first occurrence of a TLD collision with HNS with one that is delegated by ICANN accelerates the conversations within ICANN and the security professionals and industry on the Name Collision (NCAP) aspect of the HNS project.

I do not get any mild sense that the answers have revealed themselves yet within the HNS community for some of the important and uncomfortable questions that should be expected from NCAP over the intersection.

It seems there was an assumption made that by evergreening the existing list of TLDs plus the Alexa list that this would be done and dusted enough to buy 24-36 months time until a (maybe) new TLD round and ICANN would monitor HNS and remain laissez faire on this.

Optimistically, if some solution to all this could reveal itself before a new round, and it might, the time frame gets accelerated on that attention, and those solutions to the conflicts have not revealed themselves.

[pinheadmz]

The easiest way to deal with this is to add rules in the HNS resolver, which lives in the application layer. Users can opt-in to ignore certain names from the blockchain and resolve them to the ICANN root zone instead, which is the same mechanism used when a name not found on the HNS chain.

This will not require a hard fork or a soft fork as far as the blockchain is concerned, it will only make the owner of the HNS name music. perhaps a little disappointed.

If the HNS music wins the race for better content than the ICANN music, Handshake users may decide individually to ignore the new ICANN TLD and proceed with the "vision" of Handshake.

[brandondees]

Consider also that the names covered by the alexa list will be claimable by the owner of whoever's domain was in the list, not necessarily any relationship to the new TLD in question.

I'm slightly concerned about the "the handshake owner might be disappointed" solution, since all of these names are likely to be considered high-value and auction for a good chunk of money, and perhaps even more in resales, between parties who don't understand the situation. I'm hoping that some effort can be made to either get the handshake TLDs into the hands of the corresponding ICANN TLD controllers (no more conflict, maybe some money changes hands to make it happen), or to go ahead and get mitigations rolled out into resolvers and other tools (wallets, namebase, even hsd itself) so that at the very least, there is some awareness disseminated about the special circumstances for these names before too many people make expensive mistakes, or IMO more ideally, we effectively go ahead and block those names from being auctioned/abused pre-emptively where applicable. IMHO I think the community's still small enough that a hard fork to fundamentally eliminate an issue like this would be pretty broadly acceptable, considering how much FUD the alternatives could generate.

[pinheadmz]

Just brainstorming a few scenarios from the comments so far:

Consensus Change

kids:

• Since it's not open for auction yet, a new rule can be soft-forked in by a majority of miners to blacklist this name. It will still not be a "reserved" name and the owner of this name in the ICANN system will not be able to claim it on HNS, nor will anyone else. This will send a message to the HNS and DNS communities that we are trying to cooperate and avoid conflict.

• OR, a new updated root zone can be hard-coded into hsd along with a new reserved name list. As this option is a hard-fork, 100% of network nodes must upgrade or we will start having even worse name collisions between forks of Handshake. This will send a message to the blockchain community that we are willing to risk consensus failure to stay compatible with the legacy authority.

music:

• Since this name already has an owner on HNS, a hard fork as described above would also have to revoke the existing auction, like the Ethereum DAO fix. This will send a message to all HNS name holders that their assets may be revoked depending on actions from the legacy authority.

Application Change

• Don't change any protocol rules, just add these names to the resolver blacklist. If it is configureable, users will be able to choose which .music they prefer. If it is not configurable, then either one or the other namespace will be inaccessible to the user. This will send a message to "both" owners of music (and all other names) that their name alone isn't valuable because users still have to opt-in to it and there is competition.

Do nothing

• This will send a message to both DNS and HNS communities that Handshake is an alternative root zone.

I'm not trying to emphasize or criticize any particular path forward, these are just initial thoughts. I'm interested in hearing more opinions about it.

[dnsguru]

Interesting errata worth noting is the following ongoing work within the ICANN community about what they call 'Name Collision' helps to explain the challenges over namespace confusion.

Link: https://www.icann.org/en/system/files/files/managing-risks-tld-2-name-collision-07may20-en.pdf

[skynode]

@pinheadmz While the community is still fledgling, any hard fork whose mission is to maintain some compatibility with ICANN when TLD collisions might occur will be viewed as a moral hazard and severely diminish any confidence folks have built over time in the project. For a young project, you certainly don't want to hard fork in that direction.

That said, I think the choice range is probably a sweet spot between doing nothing (and establish an alternative root zone, much like how cryptospace has become a parallel economy underpinned by Bitcoin & ETH, regardless of business friction which will ebb with time) and adding certain names to a configurable resolver blacklist whose default is Handshake but can be changed to the regular DNS system.

In the event that a name is under consideration but won't be released by ICANN for a while (say 3-5 years), HNS might as well do nothing, allowing auctions on that name to continue while protocol front-enders like Namebase can let market participants know that there's a name-collision risk to participating in that auction including as much information as possible (links to external resources are fine) in order to provide some form of guidance to players. The onus is on market participants to keep abreast of developments in the gTLD space not just within the Handshake community. While the TLD here continues to remain under ICANN consideration, in some rare cases, users may build up enough content, services and traffic to deployed TLDs, in a sense, tilting the market in favor of Handshake TLDs - we don't want to close the door on this possibility.

When we have cases like .music, then going the other route might make sense - allow users to choose which resolution they prefer through a configurable setting in HSD.

[dnsguru]

A hard fork would not be the best approach on this issue given how nascent this project is in the launch phase - I agree w @skynode

In the specific case of .MUSIC it is months away from launching, not years.

It appears to have just been a hole in the logic used in the effort to avoid a conflict like this, at least until whatever point a few years from now where ICANN might open applications for a new round.

There are discussions under way on what to do about this collision - with a bias on win/win outcome - obviously it is best to get this squared away so that neither community is activated in bad ways so that there is room for whatever future unfolds for HNS TLDs that is not distracted by the wrong conversations.

[brandondees]

😈 advocate here, I think protecting compatibility with ICANN is the most critical factor in mass adoption for this system. When we go to browser vendors and standards bodies for support, they're going to tend to say "we don't break existing websites, period." -- This issue does not apply at all to potential future ICANN names, only existing ones that have sites deployed. That does put a ticking clock on .music though because sites will begin rolling out as soon as that pending process wraps up.

As I understand it, @dnsguru and namebase may be able to get the parties concerned for both sides of .music to talk and work out a deal to unify them, which avoids this pressing conflict with a win-win arrangement and buys handshake some time, if it goes well. For the other contentious names, though, it's a bit of a game of chicken in terms of which side gets interesting sites online first, how many users rely on them, etc. which I think puts handshake at a disadvantage.

I don't see "let the user set a preference for one source or the other" as a working solution in general... what happens when I want to visit mariott.hotel in icann space to book a trip to visit family, and also want to visit space.hotel in handshake for a vacation to the moon. I'll have to have a greylisting system at the resolver level, which is much more complicated and might not be acceptable UX for normal users to manage. What happens when future.hotel is a different entity on each side, and I am interested in visiting both? The result is the handshake web is broken until one side or the other dominates. This kind of conflict isn't limited to web browsing experience, but everything that relies on DNS. Soon it will be possible to deploy web pages and services that load resources from both ICANN domains and handshake domains at the same time, so it can't be a simple toggle option. Some of these issues wouldn't occur if handshake didn't fall back to the old DNS, but that kind of all-or-nothing partitioning is not likely to tempt a lot of regular users to adopt. It's like insisting on only accessing tor hidden services at .onion urls... sure, you can enjoy better security and more confidently that way, but you're limited to such a small corner of the internet that it's almost not even useful.

IMHO preventing these conflicts from reaching the wild if possible is worth giving deep consideration to, even if it means making expensive changes on the handshake side, up to and including hard forks if it really comes to it. It sounds like that doesn't need to be considered for now, but might come up again for future names.

I definitely concur with @skynode about Namebase and other interfaces to the HNS name market having an onus to stay on top of these kinds of issues and even bend over backwards to inform the user about the implications to minimize any financially expensive mistakes.

Whenever possible, the best outcome for all IMO is to get the pending/future ICANN TLD stakeholders to adopt their matching HNS names as early as possible, so they get more or less the same treatment as the hardcoded list as far as web users are concerned.

[dnsguru]

Great writeup and approach. There are discussions under way to determine win/win paths of addressing the named TLDs in this issue report, which is encouraging. I also have to thank this community for being so welcoming to my input, even though inconvenient, and all of the responses have been focused on greater good solutions to the conflicts identified. For the inevitable collisions that would stem from later ICANN rounds... the founding team around Handshake clearly made efforts to give that a good runway to allow for the community to evolve ideas. The suggestion of prospective ICANN applicants securing HNS is smart, but a bit of a challenge in manifesting. There were a number of competing interests for different strings in almost every application phase 2000, 2005, 2012, and it would be very likely to occur in the next round as well. The 2012 round had a number of these. The contentions were resolved by auction or other means but this drives costs up. It also may reveal proprietary information where a potential applicant might be publicly traded, and I could riff on a number of other reasons but won't. To thwart the potential of harms from early disclosure this causes parties who aspire to apply for a string to play it close to the vest. While HNS does offer some anonymity there is subsequently a matter of which potential applicant. Also, I would like to believe that HNS TLD holders might grow out their use cases and be viable applicants for ICANN DNS TLDs. I don't know of potential ICANN applicants will secure their HNS, but they may be inspired to by the eventual utility and traction and demand if things are done right

…

On Wed, May 13, 2020, 5:46 PM Brandon Dees ***@***.***> wrote: 😈 advocate here, I think protecting compatibility with ICANN is the most critical factor in mass adoption for this system. When we go to browser vendors and standards bodies for support, they're going to tend to say "we don't break existing websites, period." -- This issue does not apply at all to potential future ICANN names, only existing ones that have sites deployed. That does put a ticking clock on .music though because sites will begin rolling out as soon as that pending process wraps up. As I understand it, @dnsguru <https://github.com/dnsguru> and namebase may be able to get the parties concerned for both sides of .music to talk and work out a deal to unify them, which avoids this pressing conflict with a win-win arrangement and buys handshake some time, if it goes well. For the other contentious names, though, it's a bit of a game of chicken in terms of which side gets interesting sites online first, how many users rely on them, etc. which I think puts handshake at a disadvantage. I don't see "let the user set a preference for one source or the other" as a working solution in general... what happens when I want to visit mariott.hotel in icann space to book a trip to visit family, and also want to visit space.hotel in handshake for a vacation to the moon. I'll have to have a greylisting system at the resolver level, which is much more complicated and might not be acceptable UX for normal users to manage. What happens when future.hotel is a different entity on each side, and I am interested in visiting both? The result is the handshake web is broken until one side or the other dominates. This kind of conflict isn't limited to web browsing experience, but everything that relies on DNS. Soon it will be possible to deploy web pages and services that load resources from both ICANN domains and handshake domains at the same time, so it can't be a simple toggle option. Some of these issues wouldn't occur if handshake didn't fall back to the old DNS, but that kind of all-or-nothing partitioning is not likely to tempt a lot of regular users to adopt. It's like insisting on only accessing tor hidden services at .onion urls... sure, you can enjoy better security and more confidently that way, but you're limited to such a small corner of the internet that it's almost not even useful. IMHO preventing these conflicts from reaching the wild if possible is worth giving deep consideration to, even if it means making expensive changes on the handshake side, up to and including hard forks if it really comes to it. It sounds like that doesn't need to be considered for now, but might come up again for future names. I definitely concur with @skynode <https://github.com/skynode> about Namebase and other interfaces to the HNS name market having an onus to stay on top of these kinds of issues and even bend over backwards to inform the user about the implications to minimize any financially expensive mistakes. Whenever possible, the best outcome for all IMO is to get the pending/future ICANN TLD stakeholders to adopt their matching HNS names as early as possible, so they get more or less the same treatment as the hardcoded list as far as web users are concerned. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJL23RVC2N4WSLMFI53RRM5OZANCNFSM4M45SS6Q> .

[pinheadmz]

Handshake is, by design, on a collision course with ICANN. When it happens is not really relevant. This project is about fighting for freedom, not compliance with legacy authority (ENS is particularly good at this, and this why HNS is worth existing: it is different). ICANN is allocated 24,480,000 HNS. If they claim their name today, in a month they can redeem those coins and slaughter every auction for any name they want to maintain control over.

That being said, I disagree that user controls are a "non-working solution". Look how easy it is for most users to literally switch off HNS resolution (this is NextDNS):

I use a VPN almost 100% of the time, but my banking website blocks access from VPN. I am in the habit of deactivating my VPN when I need to access particular websites such as these. It's a very slight inconvenience, but I am an advanced internet user and I can click a button when I need to opt-out of my advanced features.

[ca98am79]

As @pinheadmz mentions, Handshake is designed to collide with ICANN. It was also designed to work with the "legacy" DNS system. A line had to be drawn to mark the transition, and in my opinion the line was drawn when mainnet launched, so no going back. For this reason I think nothing should be done in regards to this issue.

I disagree with @brandondees that "protecting compatibility with ICANN is the most critical factor in mass adoption." At this point I think it is the opposite - mass adoption will come because handshake is an order of magnitude better than ICANN at managing the root DNS zone, in terms of security, decentralization, freedom, innovation, etc..

[dnsguru]

Accumulating consensus is a social issue and not a technical one. There are tons of smart and passionate people around Handshake - and it only gets better by attracting more.

@pinheadmz "Handshake is, by design, on a collision course with ICANN. When it happens is not really relevant. "

I do not get a sense that the entire community agrees with that. I get the perspective you're expressing and embrace it as being valid and legitimate, especially given all of the contributions you've put in here on HNS. At the core of all of this is that I am concerned about letting this collide right now. It would probably be a bad path without having allowed more community to have developed and adoption to have occurred. 24-36 months vs a few months is a contrast, especially in earlier phases.

The 'this is designed to collide' or 'toggle switch' model is telling users that HNS names only work fractionally, and it plays this down a trivial matter. That is actually a loud message that HNS names don't have value because nobody actually uses them. I don't see how any of that advances adoption or attracts new uses.

If there are aspirations of working with people within the ICANN space / marketplace in the future, the manner in which this name collision matter resolves will be referenced in those discussions for years.

I could see people seeking to perhaps offer subdomains in their freshly minted TLDs wanting to approach the registrar channel or hosting companies, and that's going to go well if this can be seen as a mature community that will work together on solving tangles, or go really poorly if this is coming across as rebellious.

There are a lot of eyes on this, and it seems wise to have a bridge to the existing platforms through working out things like this one. It is high profile, for sure.

I have now had a conversation with the .MUSIC people as they became aware of this name collision matter and the auction, and willing to be patiently working towards a good outcome that is not disruptive to the Handshake Community and they are willing to have that conversation out in the open.

That could go in a good direction just as easily as it could a bad one.

Trying to have this go in a good direction.

[brantlymillegan]

Hey, dir. of operations of ENS here. Just wanted to note that since ENS is integrating the ICANN managed DNS root namespace (we've already started this process with .XYZ, .KRED, and a few others, and the rest are coming soon), this HNS-DNS conflict also means there will be a conflict between HNS and ENS. Meaning, whoever owns example.music on DNS will also own it on ENS, not the person who owns example.music on HNS.

Of course, as with DNS, this was always inevitable because of our "bring blockchain technology to the existing consensus/ICANN namespace" strategy, but I'm just pointing out that the coming-sooner-than-expected conflict will exist not just between HNS and the legacy system but also within the blockchain-for-naming industry itself.

[realrasengan]

I wanted to take a moment to share my experiences during the great internet forkage (GIF).

A long time ago, in an internet far far away, IRC was the epicenter of the internet. If you were a stakeholder on the internet (e.g., net admins, developers, etc.), in the past, it was likely you were on IRC. I still remember when the HoTMaiL owners (pre Microsoft) sent me an email agreeing to link an IRC server. The good ol' days.

While there were some offshoot, separated IRC Networks, there really was just one major at the time. However, there were policies on that major network that the overall internet disagreed with. These policies (re Eris' link policy) led IRC to fork and split into two - hence the birth of EFnet - Eris Free.

However, there were others who had issues with EFnet. Eventually, there were a number of networks that formed, from UnderNET, to DALnet to Freenode during this time period. DALnet, in fact, reached millions of users at a time when the Internet barely had millions of users.

Looking specifically at things, there was a #square (re squaresoft) on DALnet and also on EFnet. These were channels with the same name, but on different networks. EFnet came long before DALnet, but in the end, #square on DALnet was populated and EFnet's #square was a shell of its former self.

I do not believe that there is a name collision here with 'music' on legacy net and 'music' on the new internet. People have proven, time and time again, that they are willing to route around bad actors and bad policies which ICANN seems to be riddled with according to journalists and the internet populace. Anyway and as a matter of fact, there are several name collisions on the legacy net alone - the same owner of something.com doesn't always own something.net, something.org, etc.

The more popular of the names will become the "official" (where official is defined as the system the majority of people choose to resolve with). Until then, there is no name collision, simply just choices for people, just like there are choices on IRC.

Today, I am on several IRC networks, such as DALnet, Freenode, Rizon, among others, and I'm in various channels on different networks - because the most popular channels aren't all on a single IRC network. When I talk about #dragonrealm, those on IRC would know I'm referring to DALnet's #dragonrealm, whilst if I'm talking about #bitcoin those on IRC would know I'm referring to Freenode's #bitcoin.

The same will be for domains, and instead of winner take all, we may very well see a future just like IRC - multiple namespaces and people choosing which 'network' they wish to resolve with for each name.

In my opinion, we should simply leave things as is. music on handshake is the official music on handshake, and music on legacy net is the official music on legacy net. Maybe legacy net can be inferred from the uri as a means of UX - like legacyhttps://music/ resolves with legacy net and https://music/ resolves with handshake.

[dnsguru]

Naming happens at a different layer that has sweeping, superordinate impacts to what occurs within specific os, applications or protocols. Good story, but sure the example is apples to apples comparison.

…

On Sat, May 16, 2020, 7:04 AM rasengan ***@***.***> wrote: I wanted to take a moment to share my experiences during the great internet forkage (GIF). A long time ago, in an internet far far away, IRC was the epicenter of the internet. If you were a stakeholder on the internet (e.g., net admins, developers, etc.), in the past, it was likely you were on IRC. I still remember when the HoTMaiL owners (pre Microsoft) sent me an email agreeing to link an IRC server. The good ol' days. While there were some offshoot, separated IRC Networks, there really was just one major at the time. However, there were policies on that major network that the overall internet disagreed with. These policies (re Eris' link policy) led IRC to fork and split into two - hence the birth of EFnet - Eris Free. However, there were others who had issues with EFnet. Eventually, there were a number of networks that formed, from UnderNET, to DALnet to Freenode during this time period. DALnet, in fact, reached millions of users at a time when the Internet barely had millions of users. Looking specifically at things, there was a #square (re squaresoft) on DALnet and also on EFnet. These were channels with the same name, but on different networks. EFnet came long before DALnet, but in the end, #square on DALnet was populated and EFnet's #square was a shell of its former self. I do not believe that there is a name collision here with 'music' on legacy net and 'music' on the new internet. People have proven, time and time again, that they are willing to route around bad actors and bad policies which ICANN seems to be riddled with according to journalists and the internet populace. Anyway and as a matter of fact, there are several name collisions on the legacy net alone - the same owner of something.com doesn't always own something.net, something.org, etc. The more popular of the names will become the "official" (where official is defined as the system the majority of people choose to resolve with). Until then, there is no name collision, simply just choices for people, just like there are choices on IRC. Today, I am on several IRC networks, such as DALnet, Freenode, Rizon, among others, and I'm in various channels on different networks - because the most popular channels aren't all on a single IRC network. When I talk about #dragonrealm, those on IRC would know I'm referring to DALnet's #dragonrealm, whilst if I'm talking about #bitcoin those on IRC would know I'm referring to Freenode's #bitcoin. The same will be for domains, and instead of winner take all, we may very well see a future just like IRC - multiple namespaces and people choosing which 'network' they wish to resolve with for each name. In my opinion, we should simply leave things as is. music on handshake is the official music on handshake, and music on legacy net is the official music on legacy net. Maybe legacy net can be inferred from the uri as a means of UX - like legacyhttps://music/ resolves with legacy net and https://music/ resolves with handshake. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJJDRQYQTH4N7OCHHMLRR2MPNANCNFSM4M45SS6Q> .