HNS HIP-000? SLDs.md

HIP-000? : Handshake SLDs

Number:  HIP-000?
Title:   Handshake SLDs
Type:    Standards
Status:  Pre-draft
Authors: Vlad Smirnov <http://smirnov/>
Created: 2021-07-30

Abstract

A naive approach to second level domain management by handshake.

Motivation

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.

Background

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.

Body

I suggest allowing the owners of TLDs to transfer their top level domains to special hns addresses that will

1. leave the owner of TLD in control (for the holder to be able to transfer the domain).
2. 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.

Dns queries

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

The auctions may also work in a very similar manner. There will be differences though.

1. 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.
2. 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.

Domain transfers

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.

Swaps

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.

Names can contain one dot (.) (TODO: are we gonna recurse this into 3rd level domains, etc?)

Yes of course, if you have SLDs, nothing stopping you from 3rd, 4th etc levels.

So what then is the new MAX LENGTH for names? Would we keep it at 63 characters then? So if a TLD and its SLD were each 10 characters, that means third level domains could only be 10 characters or less and if they used 10 characters, then 4th-level domains would just not "fit"?

I was also thinking, this entire thing can be done without a soft or hard fork if we just don't use a dot. If the actual zone split symbol was something like -_-_- or something currently valid but not used at all. Name limit of 63 chars remains in place, and auctions are normal layer-1 on-chain auctions, where the coins get burned. Then the only work necessary would be a HIP-5 type bridge, but as I said it wouldn't have to be a plugin it could just be part of hsd. SO for example if I won an auction for the HNS name pinheadmz-_-_-smirnov you could burn your TLD smirnov after setting the NS record to HIPXXXX._hns. and then DNS requests for pinheadmz.smirnov would resolve automatically to my actual HNS TLD pinheadmz-_-_-smirnov.

However, this just drives home my very original point: If you want to own a name without any censorship risk, just get a handshake TLD. I feel like your real motivation is to find a way for TLD owners to earn income without going off chain?

Domain name length limits

See https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.4

## 2.3.4. Size limits
Various objects and parameters in the DNS have size limits.  They are
listed below.  Some could be easily changed, others are more
fundamental.
 
labels          63 octets or less
names           255 octets or less
TTL             positive values of a signed 32 bit number.

This means we will need to bump the size limit on the registered domains.

RENEW period

Also would like to spawn a discussion here about the RENEW period. At the moment the TLD has a renew period of 2 years, so the owner or some other party in some cases needs to RENEW the TLD 2 years after registration.

There were 2 questions raised by the community in telegram:

1. How to renew the SLD. Should it have the same RENEW requirements?
2. How is the TLD for an SLD is RENEWed? What if the owner of TLD doesn't renew it on time, will all owners of SLDs under the TLD loose their respective domains?

option 1

I think the logical approach to renewing the TLD would be looking at the RENEWal process as an indication that a domain name is still in use. In that sense having a RENEWed SLD on a TLD indicates that the TLD is being used, hence even without the RENEWal of TLD it should remain registered. Also it would make sense that a registration of a new SLD under the TLD should automatically reset the RENEW period for a TLD.

option 2

On the other hand if we consider a scenario where an owner of TLD looses access to his wallet all registration bids will go to nowhere (this may be a good thing), this may seems like a waste. So from one perspective it would make sense to let the TLD go up for grabs again by another perspective owner, who would then bid on the TLD, winning such TLD in a bid would mean inheriting its managed by hns status, but it would also mean receiving all future commissions from SLD registrations.

back to motivation

However, this just drives home my very original point: If you want to own a name without any censorship risk, just get a handshake TLD. I feel like your real motivation is to find a way for TLD owners to earn income without going off chain?

Well that's secondary, my primary motivation is to increase the utility of HNS. Owners making income from HNS increases utility. People getting SLDs also increases utility.

I think we should end the discussion on 'if' an SLD is needed and move to the 'hows' of it.

Blockchain hard capped at 63 mil names. Half of it is going to be filled with rubbish. Current internet users WW 4.5 billion and growing rapidly. If Handshake is going to be relevant to the internet it needs SLDs. Users should be encouraged to adopt them for various web3 applications.

As an entrepreneur i am excited by the b2b and b2c applications of HNS. However i would warn against building too much into Handshake to make it into a "fixed" thing ! The unique thing about Handshake is that is does one thing but a very critical thing that is perhaps out of reach of an individual or even entity. DNS! Everything else on it can be 'Custom Built'. That makes the whole thing flexible.

The needs of an individual who owns a .surname and wants to give SLDs to family and the needs of a registry who wants to sell SLDs to users and the needs of a holding company who wants to manage multiple entities via SLDs tethered to a common corporate TLD are very different. Currently Handshake accommodates them all.

My Two cents on some of the questions that seems to pop up...

What kind of SLDs should we encourage as a community ?

All kinds.

So some TLDs will be centralised registries like we have currently, We plan to introduce on chain SLDs via XNHNS once its completed, we are also exploring other methods. They will yield in some cases semi-decentralised and in some cases 100% decentralised SLDs. HNS can accommodate all needs. Different TLDs fulfilling different needs in society.

I sense this urgency to put everything on chain comes from an assumption that each and every SLD on every TLD needs to be absolutely 100% decentralised. And perhaps all of them TLDs will use ENS type integration on Ethereum. With close to 5 billion users we have all kinds of internet users with varying levels of digital exposure and comfort levels. So HNS as a namespace is built to accommodate them all.

I would warn against a situation where the blockchain is "overbuilt" to the point where rules about TLDs and SLDs are fixed and on chain and the flexibility and freedom to build from Root zone upwards is lost.

TLDs over time would used mostly by B2B entities working directly with DNS, dHosting, handshake, namespace related etc .
Businesses who use HNS names but have something else as core business and normal users would be better off working with SLDs.

Tools should support SLDs.

All possible work on tools that facilitate use cases such as Logins , Wallet ids , Vanity email ids, etc should be created with SLDs in mind. In fact all B2C end user applications are better off built keeping SLDs in mind.

Changing formats such as "." is not a good idea. It's not just browsers but even other ecosystems like email etc are designed to accept the "." as default. At this point there is no reason to add other form factors just the sake of it. I feel there are no tangible benefits except vanity use cases.

Third levels domains are also best left on the individual registries. We are looking into supporting these for our SLDs. But doing them in a decentralised environment is harder. Who will own the 3rd level domain ? Especially if that too is decentralised .....

Buying and Auctioning.

Not sure if there is a need to change the genesis of an SLD from registration to auction. Some specific TLDs if they wish can build auction systems for themselves on some chain but not sure it needs to be there on HNS for all SLDs universally. Also buying and selling is best done via market places. It has significantly better commercial upside for both the users and the larger community .

Also i cannot say this enough. Decentralization is NOT the only reason why Handshake is important. It serves many purposes. In India it will bring internet to over a billion folks who don't speak english. We are creating a vernacular internet. Here the priority is getting internet to people who don't have any.

Most societies east of Europe are community driven rather than individual driven and thus look at features like decentralization as a "good to have" and not a "must have". They would look at the trade off vs other features and benefits and take a call.

My impression based on my interactions with folks both users and industry and media is that Handshake has great potential to remove control of the internet from a small group to the larger community. But the bigger enthusiasm is about other innovative usecases. Every single person i met gave me some form of " Wow ! So many possibilities" Which is refreshing to see :)