a proposal for a proposal: non-canonical namespace

[alexlyee]

hey everybody! I'm Alex. I've an idea for something I'm calling 'non-canonical namespace', and I'm wondering if we could have some discussion on it before I submit a PR for it. I think it could really use the input of people who would have more insight as to how it would be implemented at the blockchain, and if that is even realistically possible. Here it is:

HIP-0018: Non-canonical namespace

Number:  HIP-0018
Title:   Non-canonical namespace
Type:    Informational
Status:  Draft
Author:  Alex Lindstrom <https://github.com/alexlyee>
Created: 2023-08-14

Abstract

This HIP proposes allowing Handshake users to purchase names that were already auctioned on mainnet in order to assign them to an alternative namespace. This provides a method for users to create customized hierarchies and domain name preferences without needing to modify the main Handshake namespace.

Motivation

Alternative namespaces give users more control and flexibility to structure domains and assign names in a way that aligns with their preferences. For example, a squatted-but-unused domain name could be purchased for non-canonical ownership of that name by someone who makes good use of it, and in time people of the internet could come to naturally recognize that as the true owner of that space if the canonical owner does not do something with it. This in-turn would encourage fruitful usage of limited memoizable namespace, and discourage name-squatting.

Rather than needing to change the root Handshake namespace to achieve this, users can customize and share their own alternative namespaces while still building on top of the main Handshake blockchain. This would be achieved with a portable (re)configuration file denoting the overwrites that one would like to make over the canonical chain, which may involve moving, deleting, or even adding new domains. The possibility to rearrange namespace for oneself and those that trust them may better reflect the decentralized nature of trust on the internet, and the portability of these reconfiguration files may allow for a future reputation network to be built for them, allowing for the strong security of a single canonical namespace with true ownership, as well as the benefits of having that quietly in competition with a community-made namespace or namespaces that also leverages the same strong security mechanisms.

In addition to name-squatting, there will likely be abandoned domain names, and without a system like this in place, there will likely be no accessible way for any abandoned name to be reused without waiting years for repayments to stop or a hard fork to 'clean' the decaying namespace.

Thus, from here on a distinction will be made between the canonical namespace and a user's non-canonical namespace.

It may be a desirable future of internet browsing to have an icon which indicates a number of alternative domains that exist for the current site, if they exist, and allows the user to surf to alternative (probably non-canonical) sites, and even rearrange their own trusted (probably non-canonical) namespace. It could indicate any differences between their non-canonical namespace resolution and the canonical one, allowing for a natural flow between the canonical web and their own, and intuitive way to develop that.

Specification

The non-canonical namespace will function as follows:

Purchasing Names: Users can purchase any name that has been previously auctioned on the main Handshake namespace for the price it originally sold for at auction¹. Purchased names are pushed below the current, canonical TLD and made accessible by HNSD/HSD (which, again, may or may not modify this namespace with a reconfiguration file)

DNS Resolution: There are a few ways this could be handled by HNSD/HSD, and perhaps each are desirable in different situations:

• reply with all records in a typical DNS fashion in order of precedence, or not.
• reply with canonical records and then separately one's reconfigured records, or just one or the other.

Ultimately, though, the best way to handle this for a browser-integration like the one elucidated earlier would be through an API:

• providing all records, or a subset thereof, of the canonical namespace
• providing all records, or a subset thereof, of the reconfigured namespace
• providing the reconfiguration file
• (if has permissions) commands to modify the reconfiguration file

Ownership: While reusing names from the main namespace, the alternative namespace will have a separate ownership and management model. Non-canonical name ownership does not confer ownership of that name in the main (canonical) namespace.

Incentives: Users are incentivized to purchase and make use of names that are underutilized, for there is a significant likelihood that they then could take eventual ownership of the domain virtually via. an entrusted non-canonical namespace, and eventually literally via. the canonical one. Premium, unused names can be obtained for reasonable fixed prices so long as they are used as per the decision of the collective. A window of time could also be instantiated after a name expires by which those with secondary ownership of that name are given an exclusive opportunity to be the next canonical owners of it² .

Deployment: Client software upgrades will be needed to support non-canonical namespaces. Initial releases would target advanced users and any that share their self-hosted HNSD/HSD. Eventual browser integration could make non-canonical namespaces accessible to mainstream users.

Limitations

The Handshake namespace currently has a fixed supply of ~150 million names. With nearly 2% of names registered in the first 2 years³, scarcity is a growing concern. Assuming these non-canonical names would count towards this limit, allowing users to purchase previously auctioned names in a non-canonical namespace may lead to more names to be desired by users than would otherwise.

Comments

This would fundamentally change the incentive structure of 'the' namespace of the internet by putting it in competition with alternative webs of trust while maintaining all of the security that Handshake offers. It would also create a natural mechanism by which archaic and monopolistic domain authorities (i.e. ICANN) can be out-competed by market forces.

Footnotes

1. It may be problematic to charge the price sold at-auction for supplementary ownership of a domain. This may encourage users squatting on names to burn exorbitant amounts on a domain to make the cost of it out of reach for most people. Or maybe that's a good thing. I don't know. Certainly though some of the price paid at auction for a canonical domain on Handshake would be the fact that it is the canonical name. Alternatively, I think, purchase and renewal rates for non-canonical domains could be locked at a rate relative to network congestion and/or blockchain usage. ↩

2. I've considered if it is a good idea to consider the order in which these secondary names are (i.e. who has owned the name non-canonically longer) for preference in this opportunity, but realized that this would create an problematically large incentive for people to then name-squat the non-canonical domains! Therefore, it may be best for there to be a 24-72 hour window after a name expires where any non-canonical owners of the name can start an auction war for the name that will be exclusively amongst themselves. This is just an idea. ↩

3. https://www.shakestats.com ↩