Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - dbrock

Pages: [1]
1
KeyID / Thoughts on TLDs and the dilemma of ownership models
« on: August 08, 2014, 10:35:06 pm »
As we prepare for the launch of the world's first DPOS DNS DAC we seem to be facing two major dilemmas:

  • It's not clear which TLDs, if any, will be associated with the domain names sold by the DAC.
  • It's not clear what the long term ownership model will be for domain names sold by the DAC.

The TLD dilemma

There has been quite a lot of discussion about which TLD or TLDs will be used to look up names in the DNS DAC using the legacy DNS system. The main contender is .P2P but other suggestions are floating around, like .OWN, .WEB, .KEY, as well as nested schemes like .OWN.P2P, etc.

Essentially, I think it would be a mistake to allocate two or more TLDs and have the DAC sell one copy of each name under each TLD.  First of all, it seems strange for the DAC to sell names under various "ICANN-compatible" TLDs even though the DAC does not own any of them.  Second, putting TLDs inside the blockchain creates a huge question mark around who will administer this list of "BitShares TLDs" --- basically begging the question of whether we need a TLD DAC to administer the list of TLDs in the DNS DAC...  Third, letting different parties buy the same name multiple times obviously implies an overall devaluation of all possible names sold by the DAC, especially considering that it may be possible to introduce an arbitrary number of even more TLDs at any time in the future.

To summarize, I think selling the same name multiple times basically amounts to hard-coding a shitstorm directly into the blockchain.

So what do I suggest?

I propose that if we in fact introduce two or more pseudo-TLDs, we should define all the TLDs to be synonymous.  It may actually be a good idea to have two or three TLDs just to emphasize their equivalence.

The word "crypto" has become synonymous with blockchain technology in the mainstream media as well as the crypto community, and I think we have a great opportunity to claim it as a TLD for the world's first DPOS namespace.  I think .P2P is also a good choice and it obviously has some momentum already.  So I personally suggest we start with .P2P and .CRYPTO.  These TLDs do not signify anything other than being suggestive of peer-to-peer and blockchain technologies.  I suggest them purely based on my own intuition about what words people would like to see at the end of their blockchain-secured domain names.

Under this scheme, then, the owner of the name BITSHARES would automatically own both BITSHARES.P2P and BITSHARES.CRYPTO, and in no way could you get to a situation where these domains are owned by different people. It would be up to the community to choose which TLDs to use for what, and domain owners could even use both domains at the same time for different purposes (simply through good old HTTP virtual hosting).

Eventually the dust might settle and we might figure out which TLDs are actually best, or maybe the landscape evolves to the point where we can drop TLDs altogether. Regardless, it will always at every point in time be crystal clear exactly who owns each name. It also avoid the scenario where malicious people register other people's names in other TLDs (i.e., the "I started company X so now I have to register X in every TLD" problem).

It's a sort of reversal of the normal hierarchy: just like WWW.BITSHARES.ORG and FTP.BITSHARES.ORG both automatically belong to the owner of BITSHARES.ORG, we would have BITSHARES.P2P and BITSHARES.CRYPTO automatically belong to the owner of BITSHARES (as well as WWW.BITSHARES.CRYPTO and WWW.BITSHARES.P2P, obviously).  We could even add and remove TLDs on the fly as we see fit if we come up with different use cases for this mechanism in the future, because the economic impact of TLD experimentation will basically be non-existent.

The core technology would not be tainted with ICANN-related cruft, since the blockchain would only register the base names and not the TLDs.

The ownership model dilemma

So then the question remains which ownership model should be used. The two main contenders are the original model (initial auction, perpetual ownership) and the leasing model (perpetual auctions, increasingly long leasing periods).  I suppose much can be said about the pros and cons of each model and I have no especially strong opinions myself.

I see no obvious way to come to a decision about which model is better, but I believe it would be very detrimental to the DAC as a whole to split the namespace based on ownership structure into one class of names for perpetual ownership and one class of names for leasing (plus the large undefined class of names under all the other potential TLDs, presumably implicitly reserved for future additions).

Instead, I propose that we partition the namespace in a way that makes more sense and is less harmful to the long-term value and quality of the individual names.

One idea would be to partition the space based on the lengths of names.  For example:

  • ICANN TLDs, etc. --- reserved (hard-coded list)
  • 1–3 characters --- reserved (for future sale or internal use)
  • 4–8 characters --- available for leasing (starting on 2014-10-01)
  • 9+ characters --- available for purchase (after initial price discovery auctions)

This would buy us some time to figure out how the leasing should actually work for the most valuable (i.e., short) names, while still allowing the system to launch and start selling longer but still first-class names that people can spend hard-earned cash to acquire safe in the knowledge that they won't have to worry about having ended up under the wrong TLD.

(If you wanted you could also do things like add /usr/share/dict/words to a hard-coded list of names which would be lease-only despite being longer than 8 characters.  But I think the length-based partition would go a long way towards avoid giving up the most valuable names too cheaply in perpetuity or having them be squatted upon.)

We may have to think this through a little bit more with regard to international names, but I think it could be worked out.  And if for some reason the leasing model should turn out to be a failure, we may simply be able to drop that part and just open up the entire namespace to the traditional ownership model.

Just my 20 mBTC.

Pages: [1]