Number: HIP-000?
Title: Handshake SLDs
Type: Standards
Status: Pre-draft
Authors: Vlad Smirnov <http://smirnov/>
Created: 2021-07-30
A naive approach to second level domain management by handshake.
My only personal motivation to introducing the second level domain names to handshake is to increase the utility of HNS tokens.
However for the rest of the world, which hopefully is much less self-focused than I am there could be a lot more to it than raising the value of HNS coin.
For example of the use cases for Handshake SLDs is usernames in different services. NameBase was one of the first to use Handshake domains for blog identities.
Now I own smirnov/
handshake TLD, and I have 4 sons. What if I want to pass to my sons nikita.smirnov
, denis.smirnov
etc for their global identities? Right now its not possible. Wouldn't it be nice if one could implement a Auth2.0-like identity using handshake names and that would support both the TLDs and SLDs, and wouldn't require multi-chain intergations?
There may be many more usecases where having handshake manage SLDs is logical and natural.
Whatever the use cases, the argument of handshake creators is that handshake should remain root-zone management only. Handshake is TLD-specific. That's fine, I can live with this, however we see now the implementation of SLDs on ENS. Now me, as DNS integrator, would have to integrate both ENS (ethereum based) and Handshake (to make sure the tld is delegated to ENS) into my app.
If the trend continues, Handshake will be just a ledger of delegated TLDs to Ethereum. And pretty much all integrators will just have a coinlist-like static file of known TLDs delegated to ENS.
If that's the case, wouldn't it be easier to just move functionality of Handshake (pretty primitive I must say) to ethereum too? Ethereum is also PoW (at least at the moment), its more widely accepted. So why invent a wheel?
My motivation is to increase the variety of ways how Handshake can be used, and increase the burn of HNS, so we remove some pretty obvious inlationary characteristics of HNS coins.
At the moment there is a suggestion to delegate the DNS for SLDs to external decentralised services such as (for instance) ENS smart contract on Ethereum or any ethereum-compatible blockchain. This approach has been described in HIP-0005 by Mike Carson and Matthew Zipkin.
While this is possible, the owner of the TLD looses all control over the domain. This is the only way to guarnatee that the owners of SLDs will never loose access to their domains. This is because Ethereum smart contracts can not communicate to HNS blockchain.
Ofcourse one could setup their domains to resolve via ENS according to HIP-0005 while still keeping control of the top level domain name. But that would mean that owners of SLDs would have no guarantee that they will continue to control the DNS zones of their domains if the owner for example looses control over his domain name or sells it.
I suggest allowing the owners of TLDs to transfer their top level domains to special hns addresses that will
- leave the owner of TLD in control (for the holder to be able to transfer the domain).
- forbid the owner of the TLD to modify the NS servers to anything but the spv node. that means spv node for the NS query for TLD. shall reply with the same IP that was queried by dns server, redirecting the SLD ns requests to itself. It means the spv node must be aware of its own IP address it advertised to its DNS users.
We should add a "managed by hns" status to each domain within handshake system. When set, this status is irreversible, the current holder of the domain will never be able to modify the NS server records for the TLD, it will forever be delegated to be managed by handshake. The new owners of the top level domain will inherit this property, which is guarantee to all the owners of next level domain that their posesion will not be tampered with regardless of the ownership of the upper level domain.
When a DNS user queries an spv node it works pretty much the same way as it works now, no changes to spv interaction with user of the full node is neeeded aside the fact that it will now allow for .
simbol in the DNS queries to the spv node.
The auctions may also work in a very similar manner. There will be differences though.
- If a '.' is encontered by hsd in an auction-related actions, the fact that the owner of an upper level domain has delegated the DNS of sublevel domains to hns needs to be validated. A special action needs to be introduced that irreversibly sets a domain name (TLD or SLD, or some deeper level domain) into the "managed by hns" state.
- When setting the status of domain to "managed by hns", the owner must specify how the acquisition of sub level domains should be handled. There may be a few ways to handle it. The current action system - where domains are purchased on auction, a dutch auction.
At the moment, an auction is the only method of spawning a new toplevel domain name within handshake. However, a new owner of TLD may decide to apply a different method of the subdomain spawn. One could just set a fixed price for every subdomain, or create a dutch auction for new domain names. The new sub domain spawns may be handled differently by each owner of each TLD, however if there is a fee involved in obtaining a new sub domain name - it makes sense to let the owner of upper level domain decide what portion of this fee shall go to the owner of the upper level domain name, and what portion of its shall be burnt in the same way as it is burnt right now at the end of the actions.
This is where my self-driven motivation for raising value of HNS coin comes in, the additional level domain management will give additional utility for the coin raising the demand for the HNS and enlarging the userbase. The reselling burn will add to deflationary pressures too.
Yes, I know the deflation and tokenomics were the side effects and the necessary evil to achieve the real objectives of HNS... Not the vice versa. But listen, I am also a user of HNS, and I am only expressing MY personal motivation. It may not be accepted by community, but it would be really amazing to have all level domain NS managed by one dedicated service rather than forcing a user integrate multiple solutions and query a few differnt services in order to perform a name lookup.
Sub level domains wouldn't exist in the system if the upper level domain wasn't irreversibly marked as "managed by hns". Hence all name transfers shall be allowed even if a name contains "." separator.
Interactive and non-interactive name swaps for second level domains shall be allowed, there is no difference between second and top level domain names in that regard. If a domain name exists on the handshake you hsould be able to swap it.
Yes of course, if you have SLDs, nothing stopping you from 3rd, 4th etc levels.