Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: TLD suggestions for Agent86's model.  (Read 1432 times)

Offline toast

TLD suggestions for Agent86's model.
« on: August 05, 2014, 12:47:24 AM »

Alright, you win... the other model might be better for long-term growth. If I don't do it someone else will.  It has to be delayed until either bips or bitUSD is added to DNS DAC though, so we will launch without it. Plus we can milk .p2p for a while.

https://bitsharestalk.org/index.php?topic=6561.0

.p2p will appeal to:  crypto-ancap! property rights! government can't steal my domain if it's .p2p! Blockchain tech rules!

.???  will appeal to:  .com is sooo 20xx! We took back the internet and made it for the people!

I wanted ".pub" but it is taken. Maybe ".we"? Or we can buy ".web" from the TLD squatter who has it now.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline yellowecho

Re: TLD suggestions for Agent86's model.
« Reply #1 on: August 05, 2014, 03:13:20 AM »
This sounds like something we should discuss this with marketing.
696c6f766562726f776e696573

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
Re: TLD suggestions for Agent86's model.
« Reply #2 on: August 05, 2014, 05:25:32 AM »
Are you going to  include the 'workers' part?

With the 'worker' part it solves the inflation concerns (at least from my point of view) and gives you the unlimited growth/capitalization that you wanted to achieve with the dilution model.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: TLD suggestions for Agent86's model.
« Reply #3 on: August 07, 2014, 04:50:03 AM »
I am not sure about Agent86's particular model, but I do think it is important to have at least two different models in BitShares DNS. One is the model where you can buy a name at a fair market price (at the time) but once you own it it is virtually free to keep it for however long you want (basically the original .p2p model). The other is a model where there is some carrying cost to owning a domain to discentivize squatting. This could be Agent86's model, a variation of it, maybe the domain tax model that I suggested in that thread, or something entirely different. The point of this model is to use carrying costs to significantly discentivize squatting at the cost that a rich individual/company can price you out of being able to maintain your  established name. It also provides greater long term value to the DAC.

Because the carrying-cost model is more likely to have more desirable names available at a reasonable cost, I think it is the serious one that can be considered the .com replacement. It is the model that is more likely to have company brand names available for the companies to buy and maintain at a reasonable cost. So my suggestion is to prioritize that model over the original guaranteed-ownership model. What I mean by that is the guaranteed-ownership model can be considered a sub-namespace in the carrying-cost model namespace. If carrying-cost model domains have an ending of .p2p, then guaranteed-ownership model domains could have an ending of .own.p2p, for example (better name likely needed). The name "own" (or something better) would be a reserved name in the carrying-cost model namespace, so that people who wanted guaranteed ownership of their name, could, for example, register the name "mycoolwebsite" on the guaranteed-ownership model and access it using mycoolwebsite.own.p2p.

But the entire reason we have .p2p in the first place is because we want to coexist with the existing DNS system. If BitShares DNS became extremely popular, people would stop using the .p2p extension. In this case, the names in the carry-cost model would be the TLDs (like mail.google instead of mail.google.p2p). And names in the guaranteed-ownership model would look like the regular domains we have today (www.mycoolwebsite.own instead of www.mycoolwebsite.own.p2p). Until that future point in time, we have to deal with coexistence with legacy systems. Using the currently unused .p2p ICANN TLD is a fine idea for disambiguating BitShares DNS names from legitimate ICANN names in the context of a web browser. There are other options that can be used at the same time, such as a centralized service that redirects from <BitShares DNS name>.bitshar.es to the current registered IP address of that BitShares DNS name, so that legacy users without a browser extension can at least be able to access the sites (although a secure encrypted connection would not be possible). Perhaps delegates could provide such a service. The point is that the .p2p is just there for disambiguation from legacy systems and we should allow ourselves to be flexible enough to change it. What if at some point in the future ICANN decides to add p2p to their already long list of TLDs, and many popular websites start using it. If BitShares DNS isn't popular enough by then, we may be forced to transition to another extension for the sake of unambiguity.

We can even go further with the sub-namespace idea and reserve the word "key" on the carrying-cost model, so that people could use KeyIDs to access users' personal websites (like arhag.key.p2p or maybe later in the future just arhag.key). For example, consider a DHT (to not overburden the DAC with too many users' data) that contained a statement with a timestamp saying arhag.key redirects to the attached list of IP addresses of mirror servers and uses the attached SSL key, and this statement could be signed with the Owner Key that can be verified on the DAC to belong to the registered user arhag. Or you can have the statements that point to tor hidden services.

Finally, we can create multiple sub-namespaces for the different ICANN TLDs currently available. So, "com", "org", "gov", etc. would all be reserved. This could allow legacy domain names to be accessible from the BitShares DNS system. The domain google.com.p2p would automatically redirect to google.com. This is pretty powerful when you realize that you can extend browsers to enforce BitShares DNS naming convention by default. Meaning if BitShares had registered the name bitshares on BitShares DNS using the carrying-cost model, and they set up a child account talk.bitshares which pointed to this forum, I could access this forum by just typing "talk.bitshares" as a URL in my browser. But if I type "bitsharestalk.org" into the browser, the extension would be smart enough to know that "org" is a reserved legacy name in BitShares DNS, and would instead rely on the legacy DNS mechanism to get me to this site.

So, to summarize my suggestions:
  • The global BitShares DNS namespace would have multiple sub-namespaces referred to by certain reserved names.
  • The name "own" would be reserved in the global namespace to denote the sub-namespace used by names purchased using the guaranteed-ownership model.
  • The name "key" would be reserved in the global namespace to denote the sub-namespace used for discovering services provided by KeyID users. Technically, the DAC doesn't need to do any additional work to support this functionality other than just reserving the name "key".
  • The current ICANN TLDs would be reserved names in the global namespace to: avoid confusion; provide a means of legacy access to ICANN domains; and, perhaps in the future allowing current ICANN domain holders to somehow transition over to BitShares DNS with their same name.
  • Every other name in the global namespace would be available to purchase/lease with the carrying-cost model.
  • Initially BitShares DNS would launch with just the guaranteed-ownership model supported, meaning people could only buy names in the "own" sub-namespace. Later, when the carrying-cost model was implemented, people could begin buying on the global namespace.
« Last Edit: August 07, 2014, 05:08:35 AM by arhag »

Offline toast

Re: TLD suggestions for Agent86's model.
« Reply #4 on: August 07, 2014, 05:20:51 AM »
Is it fair to say your suggestion is equivalent to changing ".p2p" to ".own" and applying your plans for other sub-TLDs as their own TLDs?

I already had thought about your idea for ".key" for legacy TLDs, but why have them as sub-TLD instead of their own thing?
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: TLD suggestions for Agent86's model.
« Reply #5 on: August 07, 2014, 05:52:07 AM »
Is it fair to say your suggestion is equivalent to changing ".p2p" to ".own" and applying your plans for other sub-TLDs as their own TLDs?

I already had thought about your idea for ".key" for legacy TLDs, but why have them as sub-TLD instead of their own thing?

My point is that I want to be able to install a browser extension which hijacks normal operation of the URL bar so when I type the following in my browsers URL bar I can get to the following corresponding websites:
  • google.com -> Takes me to google.com servers as determined by current ICANN DNS system
  • overstock -> Takes me to overstock.com servers as determined by the carrying-cost model name leased by Overstock
  • bitshares.own -> Takes me to bitshares.org servers as determined by the guarantee-ownership model name purchased by I3
  • toast.key -> Takes me some server you are hosting for your personal blog as determined through a lookup in DHT and cross-referencing with your verified Owner Key

A few notes about the above:

Google would not have to do anything for the google.com URL to work. The browser extension would just handle it. And since no one could legitimately buy the name "com", there is no conflict.

Overstock would use the carrying-cost model, because they can afford to bid up the carrying cost of squatters to take their name from the squatter. It may be cheaper to go that way than trying to buy from the squatter who owns "overstock.own" through the guarantee-ownership model. Besides, they would prefer to own the more desirable "overstock" name rather than the less convenient "overstock.own" name.

Invictus Innovations would not want to waste precious funds for a slightly more desirable name. They just want to pay a fair fee to own "bitshares.own" once and not have to worry about ever losing that name ever again.

You (toast) could host your blog at the name "toast.key" as long as you were able to register that KeyID before anyone else. You do not have to pay any fee whatsoever to register that name. It is already yours forever.


Now if we want to also append a .p2p extension to all of the above to make things less ambiguous, I guess we can do that. I would be more interested in other solutions. For example, could we extend the browser to take advantage of the URI scheme instead? We are already using it for btsx:// links. So maybe dns://bitshares.own, or dns://toast.key, or dns://overstock. And to provide access to people who do not have the extension installed, they can always use something like bitshares.own.bitshar.es, toast.key.bitshar.es, and overstock.bitshar.es.
« Last Edit: August 07, 2014, 06:01:59 AM by arhag »

Offline toast

Re: TLD suggestions for Agent86's model.
« Reply #6 on: August 07, 2014, 03:05:45 PM »
You have pretty much exactly the same plan as I do except you seem to want to not use ".p2p" as the first TLD and instead use it as a sort of higher-level TLD to disambiguate between ICANN and our domains? And you want to use ".own" for what is currently planned for ".p2p"?
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline 天籁

  • Hero Member
  • *****
  • Posts: 536
    • View Profile
Re: TLD suggestions for Agent86's model.
« Reply #7 on: August 07, 2014, 03:24:40 PM »
You have pretty much exactly the same plan as I do except you seem to want to not use ".p2p" as the first TLD and instead use it as a sort of higher-level TLD to disambiguate between ICANN and our domains? And you want to use ".own" for what is currently planned for ".p2p"?
I prefer the concept of p2p being ICANN in peer to peer network.
« Last Edit: August 07, 2014, 03:33:17 PM by 天籁 »
BTS account: disneyland
PLAY account: playone

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: TLD suggestions for Agent86's model.
« Reply #8 on: August 07, 2014, 07:27:59 PM »
 +5% I generally agree with arhag's thoughts on this subject.

Offline toast

Re: TLD suggestions for Agent86's model.
« Reply #9 on: August 07, 2014, 07:56:36 PM »
I also agree with arhag's thoughts except that I am still confused about why he wants to swap out ".p2p" with ".own" if he is saying that the ".p2p" TLD is going to be implicit eventually anyway.

Is it just that ".p2p" serves as the best "meta-TLD"?  Why shouldn't ".p2p" be the guaranteed ownership model, with no meta-TLD at all? (since users won't be typing it...)

Quote
So, to summarize my suggestions:
The global BitShares DNS namespace would have multiple sub-namespaces referred to by certain reserved names.
The name "own" would be reserved in the global namespace to denote the sub-namespace used by names purchased using the guaranteed-ownership model.
The name "key" would be reserved in the global namespace to denote the sub-namespace used for discovering services provided by KeyID users. Technically, the DAC doesn't need to do any additional work to support this functionality other than just reserving the name "key".
The current ICANN TLDs would be reserved names in the global namespace to: avoid confusion; provide a means of legacy access to ICANN domains; and, perhaps in the future allowing current ICANN domain holders to somehow transition over to BitShares DNS with their same name.
Every other name in the global namespace would be available to purchase/lease with the carrying-cost model.
Initially BitShares DNS would launch with just the guaranteed-ownership model supported, meaning people could only buy names in the "own" sub-namespace. Later, when the carrying-cost model was implemented, people could begin buying on the global namespace.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline toast

Re: TLD suggestions for Agent86's model.
« Reply #10 on: August 07, 2014, 08:00:05 PM »
I think it would be far less confusing to present it like:  ".p2p - a new TLD!"  then later:  ".key  - yet another new TLD!".   No need to disambiguate from ICANN TLDs if we never collide with them. You can still always resolve everything as you would expect. Everything you suggested is still equally possible.

If you must have a meta-TLD then why not ".bts" or similar?

If you think ".p2p" is the best meta-TLD then are you saying our marketing has to start with ".own - a new TLD!" or even worse ".own.p2p - a new TLD!" ?
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: TLD suggestions for Agent86's model.
« Reply #11 on: August 07, 2014, 10:20:41 PM »
You have pretty much exactly the same plan as I do except you seem to want to not use ".p2p" as the first TLD and instead use it as a sort of higher-level TLD to disambiguate between ICANN and our domains? And you want to use ".own" for what is currently planned for ".p2p"?

I guess it is fair to say that. We could use "p2p" instead of "own" as the reserved word for the guaranteed-ownership model. Although, I prefer "own" because it is easier to type (no numbers) and it indicates the model (full ownership). My goal is to give the carrying-cost model a more convenient name than the guaranteed-ownership model by making the guaranteed-ownership namespace a subspace of the carrying-cost namespace. The reason for this is to make the carrying-cost names more attractive to buyers since it is likely going to have a higher total cost of ownership.

Basically think of the guaranteed-ownership names as buying your own domain and the carrying-cost names as leasing your very own TLD. Getting a your own TLD is very attractive that you would be willing to put up with the higher fees.

I think it would be far less confusing to present it like:  ".p2p - a new TLD!"  then later:  ".key  - yet another new TLD!".   No need to disambiguate from ICANN TLDs if we never collide with them. You can still always resolve everything as you would expect. Everything you suggested is still equally possible.

Sure. From a marketing perspective, I view my proposal as the following. BitShares DNS provides two new TLDs on top of the current ICANN TLDs: .own domains which you can purchase at an auction and be guaranteed to own forever (but you can always sell them if you want since they are your property); and, .key domains which are a way for people to reach your personal website for your already established KeyID name (no bidding required!). BitShares DNS also allows you to create your very own unique TLD which you must lease at the fair market rate.

This approach has the problem that if ICANN adds any new TLDs which conflict with .own, .key or any of the new names (TLDs) leased using the carrying-cost model, then we are going to have an ambiguity problem. The same problem was possible if ICANN registered .p2p as a new TLD (although the likelihood of conflict is much less).  But I don't think we should make our system's names less convenient to dance around the ICANN conflicts. The fact that it would already have legacy TLDs like .com, .org, .edu, .gov, the various two letter country name extensions, etc. reserved is already good enough IMHO. If we want we could also reserve a catch-all TLD .legacy to contain all the new TLDs ICANN creates after our snapshot.


Offline toast

Re: TLD suggestions for Agent86's model.
« Reply #12 on: August 07, 2014, 10:31:04 PM »
How about simply ".bdns" as the meta-TLD / "perfect ownership model TLD", and use ".p2p" how you want to use ".own".

So early on when we are pushing this to blockchain/crypto fanatics and we only have one TLD with the ownership model we can promote it as ".p2p", afterwards we expand and promote "own your own TLD on Blockchain DNS".

So we don't need to reserve words on ".p2p" because ".bdns" is not implemented yet (though we will anyway just to avoid confusion).
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: TLD suggestions for Agent86's model.
« Reply #13 on: August 07, 2014, 10:53:55 PM »
I think arhag may share my view that the ownership model with fixed nominal renewal is not going to end up being very valuable and it's a shame to waste a more broadly descriptive TLD idea like .p2p on it.

I support arhag's proposed naming scheme.  I also like ".own"

Offline toast

Re: TLD suggestions for Agent86's model.
« Reply #14 on: August 07, 2014, 10:58:05 PM »
What do you think of having the "good" sale model be for other "TLDs" (as opposed to having a single "good model" TLD)?

So initial model names are "example.own.p2p", but then all others would be "example2.p2p" ?

Do you think there needs to be a sub-TLD which experiment with the leasing model before it is promoted to a full TLD?
« Last Edit: August 07, 2014, 11:05:43 PM by toast »
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

 

Google+