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.


Messages - dbrock

Pages: [1]
1
Thank you!!

2
KeyID / Re: DRAFT: Domain Specification
« on: August 21, 2014, 10:40:39 pm »
Hi all,

I'm working on getting the DNS GUI in place. Here's a working draft of the record editor—

https://danielbrockman.se/2014/bts-dns-editor/1/

Right now I'm focusing on getting the basic structure right, and there's quite a bit of surface polishing to be done still, but feel free to comment, especially if you see anything that doesn't seem to make sense logically.

(Subdomain mappings will be handled outside of this UI in a way that basically puts the root domain plus all subdomains next to each other in a flat list.)

Thanks,
Daniel

3
KeyID / Re: Thoughts on TLDs and the dilemma of ownership models
« on: August 09, 2014, 07:05:54 pm »
I just realized an alternative to selling TLDs might be to sell second-level domains without any regard to TLDs, kind of like how third-level .NAME registrations work, so that you could register ANYTHING.WHATEVER (but not just ANYTHING).

Probably not a good idea, but something to consider.

4
KeyID / Re: TLD suggestions for Agent86's model.
« on: August 09, 2014, 01:41:49 am »
Although it's not 100% clear why TLD registration should follow a particular model and maybe Toast is right that selling TLDs is trying to do too much at this point. I'm beginning to see the benefits of starting out a bit more cautiously by simply selling names under one or a few specific TLDs... It's the least limiting strategy in terms of future options.

5
KeyID / Re: TLD suggestions for Agent86's model.
« on: August 09, 2014, 01:33:52 am »
How about .P2P and .P2PTLD?

6
KeyID / Re: Thoughts on TLDs and the dilemma of ownership models
« on: August 09, 2014, 12:51:53 am »
Hmm... I'm not sold on this.

Quote
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.
 
The DAC would not be selling any ICANN TLDs to begin with. Maybe I misunderstood?

Quote
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...
This is decided by the DAC's shareholders. Adding a new TLD requires a hard fork which requires shareholder approval through their delegates.

Quote
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.
Not convinced by this, it seems to work fine for ICANN names. Adding new TLDs does not devalue anyone except for existing name holders. If you are holding only to speculate then I don't care if you are devalued. If your name is valuable because it is well known then you are not devalued by someone registering the same thing on a different TLD (e.g. money.org vs money.com).

I think we would get more revenue from new names being registered on new TLDs than we would from people paying extra because there is only one TLD to compete in. Look at how many ridiculous TLDs ICANN is milking.

I think it is a good thing that we leave ourselves the possibility to create different TLDs with different rules in the future. Slicing up the one true namespace in anticipation of what we think the "one better" and "one worse" models is painting ourselves into a corner.

The idea that some parameters can be set based on the name lengths is appealing, though. For example, for the ownership model, the fixed renewal rate can be set by length.

You may be right. My mind explodes a little bit every time I think about the whole thing. It's true that ICANN are making a lot of money by doing things the way they're doing it, that's a good point.

Maybe I'm not thinking about the situation correctly. I guess I'm forgetting that BTS DNS is direct competition with ICANN and that claiming TLDs in competition with them is a necessary part of building an alternative DNS system.

So then .P2P is only the first step and BTS DNS may eventually take on selling domains under other TLDs, or indeed start selling the TLDs themselves, but the whole thing is by definition meant to compete with(in) the ICANN system.

So as Toast has been emphasizing you really will be buying "FOO.P2P" --- neither more nor less --- regardless of whether it may become possible to buy "FOO.WHATEVER" through the DAC in the future for whatever reason.

Yeah, I guess it makes a bit more sense to me now...

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

8
KeyID / Re: lets find a name for the DNS DAC
« on: August 06, 2014, 11:15:22 pm »
I think "BitShares DNS" is the best name for now because it is the least arbitrary.

It seems pretty important not to choose a silly or arbitrary name for this DAC, since we are talking about a completely generic global namespace that will be around for a long time—kind of the namespace to rule all namespaces. And there can really only be one, right?

So there shouldn't be any confusion about whether or not this is actually the one and only DPOS-based DNS blockchain officially endorsed by the BitShares community long-term.

Like for example the .P2P TLD is actually a kind of kludge for playing nicely with legacy DNS and may even have to change in the future (if someone comes along and buys it from ICANN) so that should maybe not be emphasized too much?

I think when talking about a generic namespace, having any name whatsoever is actually a disadvantage because the name of the namespace will inescapably "taint" or "color" the names inside the namespace. So I'd say the name "BitShares DNS" has the paradoxical advantage of almost not even being a name at all.

(The association with BitShares X ought to be beneficial as well since BTSX is awesome and hopefully will command even more respect as more features start rolling out.)

Just my 20 mBTC.

Pages: [1]