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]

:smiling_imp: 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 notifications@github.com 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 https://github.com/handshake-org/hs-names/issues/6#issuecomment-628320479, 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 notifications@github.com 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 https://github.com/handshake-org/hs-names/issues/6#issuecomment-629650987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQTJJDRQYQTH4N7OCHHMLRR2MPNANCNFSM4M45SS6Q .

[realrasengan]

In terms of what occurs within specific os, applications or protocols, I don't think it's possible for any unused/unreleased ICANN name, like hotel/music/etc., to have any sweeping impact on much of anything - thus the Handshake music name won't be breaking anyone's computers anytime soon.

On the contrary, I'd bet there are more people using the name 'music' in their /etc/hosts file than on the ICANN system as of today.

I hope ICANN will consider its impacts on community consensus based systems like Handshake and /etc/hosts before launching any new gTLDs in the future. Ideally, if ICANN purchases the name on Handshake before announcing any name, they can avoid breaking community projects in the future. I know it looks intentional, given the .org/.com fiascos recently, but I know ICANN wants to do better.

That would be the right thing for ICANN to do, and while my absolute faith lies in blockchain, there are still very good people in the ICANN organization regardless of what the reviews on glassdoor reviews may say.

Edit 2: Actually, that might be the best way forward in the future. Currently, systems prefer /etc/hosts over ICANN's system. In the future it could be: /etc/hosts -> Handshake -> ICANN.

[skynode]

Great point @realrasengan. I think this is a perspective that needs to be continually emphasized throughout this debate: ICANN was basically grandfathered into the Handshake system with more than 24m HNS coins and is fully capable of becoming a major (centralized) player in a decentralized system of root name issuance. Capitulating to the same folks who have already received a sweetheart deal at no cost to themselves would definitely raise mighty red flags to anyone who initially took Handshake seriously.

[dnsguru]

I am not here representing ICANN or their views, and it is waay too much to unpack 20+ years of debates and discussions around the namespace, rights protections, commercial interests, privacy, security issues, etc.

I just have broken through a few Denning-Krueger ceilings there and want to spare this community that experience.

I am witnessing a lot of alarming misunderstanding about what it is (and perhaps more importantly what it isn't) within this dialog.

One massive misunderstanding is that by allocating anything to ICANN that they would be compelled to fix this community's failure to have blocked the existing TLDs comprehensively. Or an interest.

Who specifically was the person at ICANN that this was allocated to?

I see a lot of potential here - other than FOMO or profiteering from flipping TLDs in auctions. Those are not as valuable if they are not embraced by a wider community.

Just trying to keep this project and community and handshake in general from being observed as something other than the mature, inclusive and technically capable one that it is.

The community can decide what direction this goes. This is not a "fight the power" discussion; it is a "do this right" discussion, or more pointedly, an opportunity to demonstrate how to engage (or not) with Handshake.

On Sat, May 16, 2020, 10:35 AM Dexter notifications@github.com wrote:

Great point @realrasengan https://github.com/realrasengan. I think this is a perspective that needs to be continually emphasized throughout this debate: ICANN was basically grandfathered into the Handshake system with more than 24m HNS coins and is fully capable of becoming a major (centralized) player in a decentralized system of root name issuance. Capitulating to the same folks who have already received a sweetheart deal at no cost to themselves would definitely raise mighty red flags to anyone who initially took Handshake seriously.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/handshake-org/hs-names/issues/6#issuecomment-629681112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQTJORWN742SX5YYP32R3RR3FHLANCNFSM4M45SS6Q .

[realrasengan]

Given a choice between the legacy, insecure, MITM'able internet which has proven to be insecure in so many ways, or finally completing the internet in a secure way with Handshake, DANE, etc., it's really pointless to try to engage with a bureaucracy that's so far only proven it's lack of understanding with both security and, generally, how to be a good steward of the internet namespace. Furthermore, at this point, ICANN isn't even in control of itself - California controls it, frankly speaking. Decisions it makes gets over turned. This is just silly, or sometimes referred to as 'lame duck.'

If we focus on grandfathering in the legacy, we're going to get nothing done and engage in another Conway's Law loop. Bureaucracy over bureaucracy over... you get the point.

A new internet is possible and it's happening. Rather than engage with ICANN, it makes a lot more sense to engage with developers of software, developers of OS, developers of distributions, content creators, etc. We the people, who actually make up what is the internet, can actually get things done and improve our internet.

No more of this "create a moat and protect my job" bs that has produced an ICANN that clearly doesn't represent the people - and even further - ignores the people's comments and goes ahead and does exactly what the people didn't want.

This is not a fight the power movement. This is a movement where the power rests in the people and the decisions are their own. A small group of people who are quite detached from the internet as proven by its poor decisions really has proven it isn't fit to be the custodian of the root zone anymore.

It's blockchain's turn.

It's the people's turn.

Cheers, and I hope your interest in handshake continues on the merit of its technology, and not whether or not you think a discussion is mature or not. ;)

[dnsguru]

I work for myself. And aspire to potentially do some things here in HNS, but want to really gauge what level this project really is at.

I think handshake is a solid tech, just that it had some 'we didn't know what we didn't know' stuff that overlooked some important stuff.

I do not see addressing where it had some gaps as being bureaucratic so much as being consistent and thorough.

[brandondees]

@realrasengan from my perspective, this discussion has nothing to do with engaging with bureaucracy, bending over for icann, etc.

One of the negatives of these potential conflicts is that someone may spend significant money on a handshake name and find that it turns out to be worthless because of a conflict that users won't accept. On the other side, stakeholders in ICANN TLDs have definitely spent significant money and a great deal of time, which would potentially be a total loss if handshake were to become the mainstream way users access the web. It would be a bummer, but these things can happen and are not my real concern.

This is about making handshake a viable option for regular internet users, like my parents, to rely on day to day. if they have to choose between two versions of the web, they will stick with the old version that they know, which requires no action on their part. If they have to manually toggle between the two modes, they will leave it turned off and forget about it, or they will leave it turned on and forget about it until something is broken, at which point they'll turn it off and forget about it forever since nothing mainstream will be broken anymore. When some obligation forces them to try to use the handshake mode, they will struggle to understand how to accomplish that and give up in frustration, in the same way that just yesterday we were unable to have a family call over google hangouts instead of apple facetime. If they have to remember which site lives on which side, they will not understand how to keep track of that and will want to opt out to avoid confusion. I believe these things would happen at scale, for the majority of the web population. Saying "leave them behind" is at odds with how the web became successful enough for ubiquitous use. I don't believe that the major browser vendors will integrate code that imposes this kind of difficulty on web users globally. They carry a mandate to not break websites, which they take extremely seriously from what I've seen. There are further issues that can emerge when considering corporate networks, where the end user has no influence over the relevant settings. Handshake sites and services will be unreachable by default in these settings until handshake can fully achieve mainstream adoption through popular demand and broad software support.

When .music sites start coming online in a few months, will handshake already have .music sites being deployed? Maybe, but I'm guessing it's irrelevant because the default web that most of the world still uses will then have websites that are broken for handshake users.

Toggling handshake resolution off and on to open a given link on the web is not going to fly for regular people. Setting up personal whitelists or blacklists is not going to fly either. Keeping track of which devices and browsers have which customized dns lookup preferences enabled is a non-starter for regular people. I'm a software developer and I've already been tripping over this because my dns is configured at multiple layers. One browser uses DoH, another relies on my OS preference, which is connection-specific, while another machine delegates lookups to the router. Another machine uses the nextdns client, which doesn't expose the individual preferences directly, it's just an on/off switch for the remote dns provider vs the connection default. Installing something like that is the easiest option for "regular people" to use handshake today, but that's already too high a barrier to entry for many people in many contexts, and complicating it won't help. If no action is taken, any emergent TLD conflicts will break parts of the web for handshake users, which I fear will prevent general user adoption by default before we really have a chance to get to the interesting stages (General ICANN buy-in before their handshake claims expire). Even if/when the legacy TLDs are handshake enabled, these few special cases that were overlooked will still potentially be broken if no reconciliation of the namespaces is attempted. The universal TLD conflicts that should be expected to occur after the reserved lists expire mean we already have a ticking clock to either mainstream this project or accept that it will have to go on as another smaller, marginalized alternative web space like tor. Because of the handful of overlooked icann names that are already in progress towards going online, we have the opportunity to demonstrate mainstream viability by taking some action to avoid breaking the established web during the transitional phase, or we can commit to excluding users who want the existing internet to just work.

It's my understanding now that for the case of .music there is already dialogue underway to attempt to sell handshake's .music to the https://music.us/ folks for a win/win outcome this time, which hopefully means we have more time to anticipate the other potentially contentious names and work for a similar positive outcome. I hope the result will be we don't end up having certain ICANN TLDs just being broken for users of handshake before we even have a chance to acquire browser level support.

I've had a little time to mull over the potential technical changes, and I think the easiest and most generally acceptable move is to avoid any kind of potential handshake fork and just attempt to work in coordination as a community to engage with the ICANN TLD stakeholders to help them attempt to claim/buy the colliding handshake TLDs, and also to expose some messaging to potential competing bidders for those names to inform them of the situation so they can use their own judgement before burning any HNS. If a competing bidder wins a conflicting name and the ICANN TLD has sites online in the regular internet, I suspect we will tend to block the less established handshake name at the resolver level by default instead of trying to sort out how to reach conflicting website urls.

[dnsguru]

Hopefully the .MUSIC collision gets resolved in a friendly manner. If there is a divided namespace through these types of collisions, this will certainly and powerfully harm talks with certificate authorities, large resolution and CDN providers, and browser/developers and other stakeholders that could propel this project, as it is the very first question that is asked with interacting with alt root projects.

Meanwhile ... What can be done to halt the .KIDS, .HOTEL, and two Amazon strings from going into auction?

[musicregistry]

Interesting discussions. Thank you to some who have indicated some overarching issues with collisions. They are quite serious and we are afraid they are not been taken very seriously by Handshake constituents. For example, we just watched a Handshake-related Twitch video (https://www.twitch.tv/videos/621004426) which had .MUSIC in its agenda and I was heavily troubled by the overall tone by the speakers and how irresponsible some of their comments were.

Creating issues to get ICANN's attention in order for ICANN to buy Handshake coins to prevent collisions appears to be in antithesis with the Handshake community's ethos unless this really another blockchain crypto "pump and dump" money-making scheme and nothing else. How about creating some value and solving some real problems instead?

Further, some of the "Handshakes leadership" publicly stating that it would be great news for "Handshake marketing and PR" to have controversy with ICANN concerning .MUSIC reflects badly on the "Handshake community." The issue will not only be with ICANN, it will also be with the .MUSIC Registry which has been fighting tooth and nail for over a decade to prevail as a global music community led initiative for .MUSIC.

If that is not taken seriously then perhaps we can talk about some legal rights. We do have a trademark on .MUSIC in categories 35, 42 and 45. The trademark has been active in nearly 30 countries for over a decade now and active until 2029. Here are the classes which directly pertain with Handshake:

35 - Advertising; business management; business administration; office functions; management of databases, management of a database for Internet domain names and projects, also containing Internet domain names and other Internet addresses; administrative services provided in connection with registration and allotment of Internet domain names and other Internet addresses, including renewal and assignment services.

42 - Design, installation, maintenance, updating and rental of computer software; technical assistance services in the fields of telecommunications and IT; Computer services, namely research, reservation, recording and administration of Internet domain names; design, creation, hosting, maintenance and promotion of Internet web sites for others; Design of computer and telecommunications systems; engineering services for applications on large and medium-sized computer systems; computer management services, namely computer facilities management; technical support in the operation of computer, telecommunications and data transmission networks; technical appraisals relating to the installation of telecommunications terminals; technical expertise relating to Internet domain names and projects; engineering and administration (programming) of telecommunications networks; consultancy relating to electronic security and information system security; surveying relating to the installation of telecommunications terminals, national or international database servers, centres providing access to a computer network; computer rental; among other for worldwide (Internet) or private access (Intranet) telecommunications networks; computer programming; research and development of new products; scientific research for medical purposes; updating of databases and software; software maintenance services; creation of virtual and interactive images; encryption and coding of computer language; indexing of Internet sites; research and monitoring of Internet sites; computer load relief; conversion of data documents from physical to electronic media; management of a web based commercial platform of Internet domain names and projects, surveying for Internet domain names and projects, design and development of Internet projects; consultancy and appraisals relating to computer security; monitoring of data, signals and information processed by computers or by telecommunications apparatus and instruments.

45 - Domain name reservation, registration, maintenance and management services; domain name searching services; domain name registry services, namely co-ordinating the assignment of domain names and address space; technical and legal research relating to Internet domain names.

That said, Namebase has auctioned out .MUSIC to an anonymous bidder who prevailed. We alerted Namebase to do the right thing and void the auction and not collect any monetary or crypto proceeds arising from the auction. If there is any sort of monetary exchange between Namebase and the highest bidder then Namebase is liable for the obvious reasons.

We understand that it is the opinion of all that auctioning .MUSIC was a mistake and it slipped through the cracks of allocation to its rightful ICANN registry. Since the "Handshake community" allocated .COM/.NET to Verisign and all the other TLDs to their respective ICANN registries then why is the "Handshake community" treating us differently? Fix the mistake. Treat us fairly and equally like you have with the other ICANN registries.

If you cannot solve this issue then I am afraid it is clear that the "Handshake community" has incorporated weak controls, limited checks and balances and insecurity in the Handshake protocol without any sort of accountability. There is accountability. Hiding behind a technology called the blockchain is not accountability.

If you want any credibility with respect to Handshake then fix the issues, loopholes and collisions. Mistakes do happen. In those cases fix the mistakes to ensure that there is equality in treatment and consistency. If there is a technical issue then fix that too. If you cannot fix it then perhaps the entire framework is flawed at its core, which requires calibration. As the saying states: garbage in - garbage out.

Thank you

.MUSIC Registry

[tynes]

Dear @musicregistry,

I (a speaker in the video) do not represent anybody else's views besides my own. Please do not confuse my opinions with the community's opinions. If you read above, you can see that there are many different opinions in the Handshake community, all of them are equally as valid.

Creating issues to get ICANN's attention in order for ICANN to buy Handshake coins to prevent collisions appears to be in antithesis with the Handshake community's ethos unless this really another blockchain crypto "pump and dump" money-making scheme and nothing else. How about creating some value and solving some real problems instead?

This paragraph shows that you have an inherent misunderstanding of what Handshake is and your angry tone is not appreciated. ICANN is the largest holder of HNS coins and only needs to submit a DNSSEC proof of ownership to the blockchain to claim them. They do not need to claim them if they do not want to, but if they did then they would be able to win any Handshake names that they want easily. Handshake has donated quite a bit of money to open source and has quite a few innovations 1,2 so it is most certainly not a pump and dump. Programmable domain names as cryptographic assets will prove themselves to be very valuable and you should take a minute to appreciate how innovative the idea is.

That said, Namebase has auctioned out .MUSIC to an anonymous bidder who prevailed. We alerted Namebase to do the right thing and void the auction and not collect any monetary or crypto proceeds arising from the auction. If there is any sort of monetary exchange between Namebase and the highest bidder then Namebase is liable for the obvious reasons.

Namebase didn't auction off the name, its an inherent part of the protocol. You cannot blame Namebase for this. I am not a lawyer so I have no opinions on the legal aspect of it, but you should attempt to actually engage with the community before bursting in and saying that you are going to sue people.

If you want any credibility with respect to Handshake then fix the issues, loopholes and collisions.

Please submit a pull request implementing your proposal (blacklisting .music) and we will review it with thorough discussion. There are multiple ways of doing this and its unlikely that a consensus based change will be accepted so a policy based change is probably the best way of doing it. We might even help you implement it if you decide to stop being so disrespectful. By the way, what sorts of technical innovations are you working on these days?

garbage in - garbage out.

Extremely disrespectful but I will forgive you. Your tone gives the Handshake community a lot of conviction about the high value of Handshake names. Please join us in a community call. Email me at mark.tyneway@gmail.com to set this up and we will make sure that the community hears what you have to say.

[musicregistry]

Mark,

We were recently made aware of the auction and we had to act in a timely manner with Namebase to freeze the auction. We never heard of Handshake prior to this. If we were Warren Buffet then maybe our tone would convince the Handshake community that Handshake names have high value. However, we are not Warren Buffet. We are the .MUSIC Registry so this .MUSIC Handshake auction is pertinent to us and thus we have to protect our interests and others'. It does not mean that we are vindicating your business model or the value of Handshake.

Not all technical innovations create value. We look at innovation from a problem-solving perspective not creating great technical technology that the regular person will have difficulties understanding let alone adopting it. The DNS "as is" has been around for decades because it is efficient, globally distributed and adopted by mainstream browsers since the inception of the Internet. Changing "attitudes" of internet users is steep uphill battle. Convenience and familiarity always beats technical innovations. Problem solving is paramount.

Our focus is solving problems within the global music community under the .MUSIC domain. The value is the implementation of music-tailored policies that create a safe haven for music consumption under the .MUSIC umbrella. The value proposition is a trusted, secure and verified .MUSIC domain name.

.MUSIC domains will have built-in security (https) and .MUSIC registrants will be verified to ensure the artist's website represents the real artist. This creates trust, safety and adoption. Keeping it simple.

Our ask was equal treatment like other ICANN-related registries e.g. Verisign. One would assume that if Handshake is such a great technical innovation that such a problem -- delegation of a string -- is a no brainer. We did not ask for blacklisting. We asked for equal treatment. If other ICANN registries were delegated their corresponding string and that was the handshake consensus policy then we expect that .MUSIC would be assigned to us in such a predictable and consistent manner.

If you are touting Handshake as an amazing technical innovation of great value then prove it by solving a simple problem that the current domain name system does so efficiently, quickly and simply: transferring a domain from one registrant owner to another. Can Handshake handle that? Or is it too complicated technically because it is so innovative? Our understanding is that this action appears to be rocket science and would compromise Handshake somehow. If this is true then it seems that lack of accountability permeates Handshake. If this holds true then you can never have trust and security in Handshake.

We hope this can be resolved in a fair, predictable and consistent manner.

Thank you

[dnsguru]

@musicregistry the flustration is understandishable.

I just watched the 5/14 video in question. The candor in the 'let the conflict happen for pr' statements made on that conversation about allowing the conflict by design in the community video may not reflect the overall sentiment of the whole of the handshake community.

There is confusion within the handshake community about ICANN in general, and clearly this is the case or they would have had more coverage and shored this up when they attempted to do the right thing when blocking strings. The founding fathers of this missed .MUSIC and the other strings identified in the issue report. They also allocated a massive chunk of their token to ICANN.org thinking maybe they'd ever take them, and they also seem confused about ICANN in general, and sometimes mistakenly think I am with ICANN or work for .MUSIC. I also get a sense that there is not awareness that ICANN is not .MUSIC or some sense that this is about privacy, censorship or anything other than fixing something.

The sentiment that got expressed is not universal, I have found. There are also many others that recognize the collision with the ICANN namespace / IANA root names will restrict adoption. Others in the community want to see this and a few of the other conflicts identified solved in friendly ways rather than conflict. The overall handshake community would benefit to make wider adoption of these names attractive to the browsers, search and certificate resources to enable them to work, and those are sullied by this type of open conflict.

I have put out a call to the community to see if the person who won the auction will get in touch, and I will figure out if there's a way to make them whole on what they spent in the auction to transfer the TLD to your org. That is a much better outcome for .MUSIC, for Namebase, for Handshake and this community and likely for that party.

I ask for a week for this to happen from you, and that Tieshun and Namebase not manually transfer the name so that we can avoid further escalation. 10pm Eastern, 7pm Pacific, May 26th 2020.

[realrasengan]

At the end of the day, distributed and decentralized blockchain projects like Handshake are and will continue to be led by their respective communities. Thus, the community will decide how to handle this. Nobody "owns" Handshake, and Handshake is nobody.

That being said, I have some questions:

1) If my stage name is LilWayne, will I get LilWayne.music or do you plan on giving that to someone else and be the judge of who is allowed to have which name?

2) If I trademark a generic word like .constantine and make a rent seeking business called .constantine, will I be able to go on internet forums threatening legal action and ownership across all systems for that word anytime someone uses it in their name/domain system -- of which there are quite a bit for the word 'domain' and 'name' within the internet given the words' definitions?

3) What does built in security mean? Aren't you just going to charge to issue SSL certificates just like Let's Encrypt does for free? Can you guarantee another SSL provider won't issue another certificate for the same name?

These are some questions that arise after reading your messages.

Thank you.

Edit: I want to add a few more things:

1. The process was absolutely fair. There was a snapshot taken and all names in that snapshot were pre-reserved. .music was not in that snapshot.

2. There was a rather long period of time given thru notice thru many major newspapers that trademark claims were being accepted to pre-reserve names. This was absolutely not something we had to do, but we did. .music didn't make any claims.

[dnsguru]

@musicregistry can you put something on music.us website to link to this issue URL so that you can prove this is someone from music.us vs someone not representing the .MUSIC registry for the community?

[pinheadmz]

@dnsguru with the exception of music, could you provide a complete list of the names in question and if possible the range of dates you anticipate their resolution in the ICANN root zone?

There has been enough community interest that I'm willing to start looking into soft fork proposals.

[blockcrypt]

Just joined to offer my feedback on this topic. @dnsguru You make a lot of sense. If there are conflicts then this will definitely cause confusion and fragmentation. Better resolve issues now than face consequences later. @musicregistry Hopefully this will be resolved. It does appear to be an honest mistake. I think a win-win situation can be created. What is in the best interest of both the music registry and handshake is the best result here imo. @realrasengan Saying that handshake is nobody is untrue. We have not been taken over by robots just yet (I hope not!!!!!!!!!). Which major newspapers provided notice to the traditional registries? Would have been easier to contact the registries directly since their contact info is public on the icann site. How were the other registries contacted that did not have a conflict? Through the media? Never too late though to prevent these conflicts. It is good news that @dnsguru brought this up to everyone's attention. @pinheadmz I agree that it is a good idea to look into soft fork proposals to resolve all the potential conflicts coming up. Uniformity is the best outcome for all concerned.

[dnsguru]

@dnsguru with the exception of music, could you provide a complete list of the names in question and if possible the range of dates you anticipate their resolution in the ICANN root zone?

Dates certain are something unlikely to be possible without contacting the various applicants for their input. Can the strings be addressed without dates provided? I am concerned that we'll see a rehash of what unfolded with the bilateral misunderstanding of each community for each of these, and if they're stuck in their current state, it is unlikely that they can predict timing well.

There has been enough community interest that I'm willing to start looking into soft fork proposals.

This and Sean's offer are encouraging

[dnsguru]

@pinheadmz when would the soft-fork happen, and would the effect be that it would not allow these TLDs to resolve that have auctioned, and keep the others from proceeding to auction?

[pinheadmz]

Soft forks can take a long time to deploy, although with such a small mining community it might not be that bad.

First the code is written, reviewed and tested. If there is enough community support the code may be merged and released, and everyone needs to upgrade (especially miners). We would probably deploy it using BIP9 which involves moving through a series of 2-week (2,016-block) periods. BIP9 soft forks have a START time which should probably something like 3-6 months after release (I'd have to see how much advance time Bitcoin soft forks usually account for).

After the STARTED state, a period where >95% miners signal the soft fork will be followed by an LOCKED_IN state and then ACTIVE state, when all upgraded nodes on the network start enforcing the rules (rejecting non-compliant blocks as invalid). This can go fast or slow. It took Bitcoin something like 12 months to get enough miner support to activate SegWit (there is a LOT to read in Bitcoinland about softfork deployment and SegWit in particular: https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork).

This is why I was asking you for a timeline on the ICANN root zone updates, to gauge urgency.

And with a complete name list (I only see 7 above, is that all?) we can compute when the HNS auctions are supposed to roll out.

I think the easiest rule would be to blacklist the names either forever, or until the 4 year reserved period expires. So these late-comers would NOT be able to claim their names on HNS the way google and facebook can.

To be clear, I am ONLY willing to write fork code for names that HAVE NOT been auctioned yet. .music is in a whole 'nother world and has to be dealt with (or not) in some other way. If the two music owners dont come to an agreement, then the conflict will lie at the resolver's root zone preference.

[dnsguru]

As mentioned earlier, I cannot provide dates for the other strings that are in the conflicted state.
It is just not possible to do, and it is not wise to make that a condition of addressing what can be addressed.

With the various time requirements represented for BIP9, it seems unwise to have anything in the critical path of taking whatever steps without delay to fix the oversights or let other conflicts play out if they could have been avoided.

I strongly encourage the community to not let the other strings that were missed by the snapshot bootstrap identified in this issue report that are in a conflict state proceed to future auctions.

Time will tell if this is something that was important to have done or not, but in reviewing the list of impacted parties, it seems unwise to overlook that there was an opportunity to address the conflict issue.

[pinheadmz]

With the various time requirements represented for BIP9, it seems unwise to have anything in the critical path of taking whatever steps without delay to fix the oversights or let other conflicts play out if they could have been avoided.

Every day, I work as hard as I can on Handshake. No one else has to do anything. That's how open source works. I know you consider this issue the highest priority but I personally have a lot of other stuff to do before I can write brand new consensus code that I don't think I personally would even recommend anyone run. If you want this done by the end of the week, I recommend hiring your own team of developers.

Time will tell if this is something that was important to have done or not, but in reviewing the list of impacted parties, it seems unwise to overlook that there was an opportunity to address the conflict issue.

My top priority, as far as "impacted parties" are users of Handshake.

I verified the list in your OP from icann.org and checked each name against hsd. It seems like you missed .merck but that name is reserved anyway.

Names that are already reserved:

name	target (who can claim on HNS)
merck	merck.com
spa	spa.gov.my
web	web.de
webs	webs.com

Note that if ICANN delegates one of these names to an institution that is NOT currently in control over the target, there will be another conflict when that domain owner claims on chain. Theoretically such names could ALSO be blacklisted with a soft-fork.

Names that are already owned on HNS by auction winners:

idn, music, xn--jlq480n2rg

The only remaining names that could be soft-forked to prevent future auctions are:

name	rollout block	estimated date
hotel	45360	~196 days from now
kids	26208	~64 days from now
xn--cckwcxetd	51408	~239 days from now

In my opinion, two months may not be enough time to ensure a clean soft-fork in time to blacklist the name kids.

My advice to you is to contact Edmon Chung at DotKids Foundation Limited HK (info@tld.asia) and encourage them to acquire HNS tokens so they can win the auction for their name on HNS.

[dnsguru]

@pinheadmz thank you for the further review.

My advice to you is to contact Edmon Chung at DotKids Foundation Limited HK (info@tld.asia) and encourage them to acquire HNS tokens so they can win the auction for their name on HNS.

Given the trolling from this community that I have endured over .music, and the reaction from that camp, I'd hate to deny someone else in this community the dignity of experiencing the feedback that an affected ICANN TLD provides when presented the opportunity that handshake represents.

It appears also that in your update that since my reporting the issue, that Amazon's xn--jlq480n2rg TLD was also auctioned?
That will make the conversation with them about xn--cckwcxetd ... interesting and lively for this community.

Good luck!

[dnsguru]

@pinheadmz

Every day, I work as hard as I can on Handshake. No one else has to do anything. That's how open source works.

Big supporter of FOSS and get how that works. THANK YOU for looking at this and engaging on it, and for all your hard work on this project and moving it forward.

I know you consider this issue the highest priority but I personally have a lot of other stuff to do before I can write brand new consensus code that I don't think I personally would even recommend anyone run.

To me I'm telling folks their arm is on fire and suggesting some water get applied. The sense of urgency is to keep the fire from injuring them or spreading further. Important in that sense. I was suggesting this get attention and that the community not be too casual about it.

If you want this done by the end of the week, I recommend hiring your own team of developers.

Someone should. I already have a lot sunk capital into building things for handshake that these architectural mistakes have eaten through. Looking at the prices people are attempting to resale won HNS names for, it seems like those with a vested speculative stake in Handshake this could look at that path.

[dnsguru]

Update: We are now out of the realm of the theoretical.

Amazon has launched .亚马逊 (.xn--jlq480n2rg), so the Handshake project now has its first real-life collision with an ICANN delegated TLD.

The corresponding Handshake TLD was auctioned after this issue was created, while the topic was under discussion.

[pinheadmz]

That's funny, I don't remember hosting a Chinese Amazon server on my local network...

$dig @1.1.1.1 xn--jlq480n2rg
...

;; ANSWER SECTION:
xn--jlq480n2rg.         3600    IN      A       127.0.53.53

[dnsguru]

When a TLD lights up for the first time in the root zone, it undergoes a period of 'controlled interruption'. The approach was to put a wildcard record resolving to that special localhost address and let it answer for a period of time (120 days?).

August 2014 Announcement Serverfault Article

It was believed that this would cause something that was using the TLD with a conflict without being aware of the conflict of a new TLD lighting up in the DNS to go from being "we didn't know this would be an issue for us" to "ah, we have an issue, let's fix this".

So this will be the experience for where collisions between Handshake and ICANN TLDs happen, for the first 120 days or so all the major resolvers will nerf the Handshake TLD.

[pinheadmz]

for the first 120 days or so all the major resolvers will nerf the Handshake TLD.

Do you mean the major resolvers will nerf the ICANN TLD? The HNS TLD is registered:

$ hsd-rpc getnameresource xn--jlq480n2rg
{
  "records": [
    {
      "type": "GLUE4",
      "ns": "ns1.xn--jlq480n2rg.",
      "address": "44.231.6.183"
    },
    {
      "type": "NS",
      "ns": "ns1.xn--jlq480n2rg."
    }
  ]
}

...although not completely configured:

$ dig xn--jlq480n2rg

; <<>> DiG 9.16.3 <<>> xn--jlq480n2rg
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11221
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: eb88527940306333 (echoed)
;; QUESTION SECTION:
;xn--jlq480n2rg.            IN  A

;; AUTHORITY SECTION:
xn--jlq480n2rg.     1029    IN  SOA a.misconfigured.powerdns.server. hostmaster.xn--jlq480n2rg. 2020052801 10800 3600 604800 3600

;; SIG0 PSEUDOSECTION:
.           0   ANY SIG 0 253 0 0 20200603212020 20200603092020 40474 . GkmqajqZ5AF207H/UpnKufINhKezRM3ZK6DIIlcSOPIu6uowqxED76QV jWnUEeMFQrSLyy0GPdp6tzRV2/BNgg==

;; Query time: 532 msec
;; SERVER: 64.227.15.172#53(64.227.15.172)
;; WHEN: Wed Jun 03 11:20:20 EDT 2020
;; MSG SIZE  rcvd: 227

If the HNS user that owns this name had A records set up, Handshake users would be able to access the content today.

[dnsguru]

The world at large will see the synthesized localhost answer, as you experienced with Cloudflare's resolver...

That's funny, I don't remember hosting a Chinese Amazon server on my local network...

$dig @1.1.1.1 xn--jlq480n2rg
...

;; ANSWER SECTION:
xn--jlq480n2rg.         3600    IN      A       127.0.53.53

The example you provided shows that HNS answers for the Handshake .xn--jlq480n2rg, and that Handshake users speaking to HNS for resolving names in general routes around this issue of 'controlled interruption' in the ICANN root having some impact on HNS domains when a conflicting TLD lights up in the ICANN/IANA Root system that the general population of the earth is currently using.

On the one hand, this is a solution to question as to if the Handshake domain is nerfed or not within Handshake, so it seems that the Handshake experience may not be hobbled in THIS way by the conflicts where someone is talking directly to a resolver.

I could see another experience, where someone is in an environment that opaquely supports the HNS namespace being a desired future state. What does this conflict look like with NextDNS in the middle, or an upstream ISP that integrates some support for Handshake? That's worth looking at to determine that it matches the same results that you received on the command line tools @pinheadmz

The conflicting experience is worth knowing. If it is possible to get more understanding on the impact of conflict, this could be helpful with the effect on the general adoption constraints. Specifically, that this example helps or harms Cloudflare (1.1.1.1 from the earlier example) etc all get attracted to supporting / adopting use of Handshake names.

Knowing the impact is going to be helpful.

[pinheadmz]

As the mathematicians like to say "the solution exists". https://github.com/handshake-org/hsd/pull/558 is merged, and the https://github.com/pinheadmz/holdmyhand plugin has been released. Users or services interested in applying extra protection can do so in the application layer (i.e. with a plugin) and so I don't think this is a relevant issue anymore. This repo in particular was only used to generate consensus parameters and so this issue is a bit misplaced anyway. I don't seem to have access to this repo so I can't close it! @chjj

[dnsguru]

I understand the motivation to close this, but there may not be consensus on this being "solved".

On Sat, Mar 13, 2021, 7:35 AM Matthew Zipkin @.***> wrote:

As the mathematicians like to say "the solution exists". handshake-org/hsd#558 https://github.com/handshake-org/hsd/pull/558 is merged, and the https://github.com/pinheadmz/holdmyhand plugin has been released. Users or services interested in applying extra protection can do so in the application layer (i.e. with a plugin) and so I don't think this is a relevant issue anymore. This repo in particular was only used to generate consensus parameters and so this issue is a bit misplaced anyway. I don't seem to have access to this repo so I can't close it! @chjj https://github.com/chjj

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/handshake-org/hs-names/issues/6#issuecomment-798520833, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQTJJUFKSJBPPWORIBMV3TDNZ4JANCNFSM4M45SS6Q .