ISO-3166-1 and creating a long-term compatibility with IANA / ICANN / ICP-3 legacy root

[dnsguru]

tl;dr: the following two character strings are the only ones that should be allowed in HNS to avoid later problems (case insensitive):

• aa
• oo
• zz
• q[m-z]
• x[a-z]

These are generally available without assignment by ISO-3166/MA

If one reviews the Alpha-2 table that is present on wikipedia, only the user-assigned strings technically qualify as 'available' outside of the ISO-3166/MA

[dnsguru]

Even if assigning the above, these are similar to the RFC1918 IP address space used in NAT (ala 192.168.0.1) and could potentially create problematic collisions where these have been privately used.

In considering the allocation of ANY two character TLDs, it would be wise to consult the ISO3166 MA.

[dnsguru]

New IETF Draft: Top-level Domains for Private Internets

[dnsguru]

https://www.namebase.io/domains/eh auctioned 2020-07-15 vs https://www.iana.org/domains/root/db/eh.html

[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'd argue it is not closed by hsd/#558 in a manner that addresses the interop issues that are present in the collision issues raised.

Improvement, yes. Solved, kinda-sorta, but not mostly.

While this brilliant plug-in concept offers a workaround that some can opt in to if aware of, there may not be concensus on this being the holistic solution required to the collisions that satisfies the concerns that large-scale providers might need to see addressed with the protocol in general.

I understand there is an objective by many investors to cancel, bury or downplay inconvenient narrative or disclaimers that might expose some of the flaws in the project and how those may be in the way of adoption or growth, but it is important that these remain openly discussed.

[pinheadmz]

@dnsguru we aren't changing any "general protocol" rules any time soon, maybe ever. I recommend you focus your energy on convincing users and services to run hsd with the holdmyhand plug-in. I don't think activity on GitHub issues in this organization is productive until the community sentiment changes significantly. We've been discussing this ad naseum for months and your concerns are not shared by a majority of the community. The plug-in means you have a tool to address the issue yourself without help from handshake-org developers.

[dnsguru]

You keep saying that this was written for me... I appreciate that but hope it isn't literal

As people discover Handshake- either through research or promoted dialog, I get asked by registrars, registries, ca's, dns providers frequently if this handshake experiment a safe platform or all hype and pump.

I point them at the github so they can see that there is active awareness and authentic appreciation of what will be considered broken from their perspective. When they see these, they appreciate that the project "gets it" and wants to be embraced.

I am concerned that closing these issues results in effectively censoring that authenticity the project has.

That aspect may send a message to some very influential groups outside of the Handshake project of Handshake community stakeholders having either active unawareness of the sandbox that is playing in or things are being brushed under the rug that don't match the "it all works" narrative.

When someone looks at a repo issues that are open are initially the filter in view to them. And those closed typically represent those "solved".

This really is not solved, nor will it necessarily be. But awareness of the issue is more the objective than the fix here.

On Sun, Mar 14, 2021, 4:58 AM Matthew Zipkin @.***> wrote:

@dnsguru https://github.com/dnsguru we aren't changing any "general protocol" rules any time soon, maybe ever. I recommend you focus your energy on convincing users and services to run hsd with the holdmyhand plug-in. I don't think activity on GitHub issues in this organization is productive until the community sentiment changes significantly. We've been discussing this ad naseum for months and your concerns are not shared by a majority of the community. The plug-in means you have a tool to address the issue yourself without help from handshake-org developers.

— 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/8#issuecomment-798894664, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQTJJPHJHIAWEQIY7FATTTDSQHHANCNFSM4M47J23A .

[brandondees]

I think it's extremely premature to make any conclusions about the opinion of the majority of the community on this. Most don't know about this issue and there's not been much/any discussion of it outside of github, where most of the active community members don't frequent. I agree with @dnsguru that WONTFIX here has a significant impact on how HNS looks from the outside and shouldn't be treated too casually. Perhaps we need a more appropriate perpetual home for any such ongoing debates, and more effort to have the community participants become aware of the problems and voice their views on these types of things.

@dnsguru beyond a fork here to remove names from availability in HNS, do you have any other specific proposal ideas for addressing this issue? I think it's probably easier to push through community adoption of a default/de-facto plugin configuration before any network forking considerations, but if it comes to that it'll also mean forking the source repos under different maintainership.