Quote from: arhag on August 08, 2014, 01:35:15 AM

Quote from: Empirical1 on August 08, 2014, 12:53:22 AM
I want to be able to install a browser extension which hijacks normal operation of the URL bar so when I type

google.com -> Takes me to google.com.p2p as determined by BDSN and I don't want to ever want see the .p2p. ever. Is this technically possible?

Who owns google.com.p2p? Google or someone who was lucky enough to buy the name google.com on BDSN?

The highest bidder. But I'd use a system that makes them very expensive to start the bidding for in the first year. Very high minimum opening bid which decreases over time & for the most valuable legacy ICANN domain names, the minimum auction opening bid, would be their $ value at start of DAC divided by maybe 10 000 with a 25% monthly drop.

Quote from: arhag on August 08, 2014, 01:35:15 AM
As long as we reserve the name "com" (and other current TLDs) on the BDSN global namespace, no one is able to buy any names that end with .com (or .org, or .edu, or any of the other current ICANN TLDs). Because no one is able to own those names, the browser extension is able to unambiguously know you are talking about a domain name on the legacy ICANN system. So, it will use that legacy system to find the IP address 4.53.56.93, and take you to Google's website. This means early adopters who use the BDNS browser extension can still use all old domain names like they regularly did. This helps adoption.

Thanks for the explanation! Great! I think I understand now. So we're reserving them on purpose so that BDSN takes our browser extension users to that domain name on the legacy ICANN system.

But you're saying my request it's technically possible? - For a BDSN  browser extension to completely ignore ICANN .coms & .orgs & redirect users to our .com namespaces,  or at least our .com.p2p namespaces where the .p2p is always invisible to the user? Which may or may not be owned by the same people that own the domain names on the legacy ICANN system.

If so - Woohoo!

I'm probably wrong, but I think then the current model is great & will be a success. But the current BDNS with our unique TLD's is to domains what Bitcoin is to USD but my BDNS model is to domains what BitUSD is to USD.

It's 3:30 am here, so I'll explain my thinking in the morning...

Quote from: arhag on August 08, 2014, 01:35:15 AM

Quote from: Empirical1 on August 08, 2014, 12:53:22 AM
I want to be able to install a browser extension which hijacks normal operation of the URL bar so when I type

google.com -> Takes me to google.com.p2p as determined by BDSN and I don't want to ever want see the .p2p. ever. Is this technically possible?

Who owns google.com.p2p? Google or someone who was lucky enough to buy the name google.com on BDSN?

As long as we reserve the name "com" (and other current TLDs) on the BDSN global namespace, no one is able to buy any names that end with .com (or .org, or .edu, or any of the other current ICANN TLDs). Because no one is able to own those names, the browser extension is able to unambiguously know you are talking about a domain name on the legacy ICANN system. So, it will use that legacy system to find the IP address 4.53.56.93, and take you to Google's website. This means early adopters who use the BDNS browser extension can still use all old domain names like they regularly did. This helps adoption.

+5%  BDNS operates in parallel with traditional DNS, there are no conflicts, only new TLDs

Quote from: Empirical1 on August 08, 2014, 12:53:22 AM
I want to be able to install a browser extension which hijacks normal operation of the URL bar so when I type

google.com -> Takes me to google.com.p2p as determined by BDSN and I don't want to ever want see the .p2p. ever. Is this technically possible?

Who owns google.com.p2p? Google or someone who was lucky enough to buy the name google.com on BDNS?

As long as we reserve the name "com" (and other current TLDs) on the BDNS global namespace, no one is able to buy any names that end with .com (or .org, or .edu, or any of the other current ICANN TLDs). Because no one is able to own those names, the browser extension is able to unambiguously know you are talking about a domain name on the legacy ICANN system. So, it will use that legacy system to find the IP address 4.53.56.93, and take you to Google's website. This means early adopters who use the BDNS browser extension can still use all old domain names like they regularly did. This helps adoption.

.own seems very palatable

Sorry, if I'm asking the same kind of dumb question in 5 different ways,

Quote from: arhag on August 07, 2014, 05:52:07 AM
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

I want to be able to install a browser extension which hijacks normal operation of the URL bar so when I type

google.com -> Takes me to google.com.p2p as determined by BDSN and I don't want to ever want see the .p2p. ever. Is this technically possible?

I would revise the structure to be:

Quote
.p2p or .bdns or nothing at all! (it really doesn't matter since it is just a way to mark the difference between a BitShares DNS resolver and an ICANN DNS resolver)
    .own
         .user-domain-1   (won by guaranteed-ownership model)
         .user-domain-2   ""
         ...                    ""
    .key
    .com, .org, .edu, .gov, ... (a snapshot of current TLDs)
    .legacy (the sub-namespace underneath this is dynamically determined by using ICANN DNS resolvers)
         .com
         .org
         ... (any other ICANN TLD in the future)
    .user-TLD-1   (won by carrying-cost model, perhaps agent86's model)
    .user-TLD-2   ""
    ...                ""

Quote from: toast on August 07, 2014, 11:28:21 PM
Agent86 and arhag seem to prefer #2. Disadvantages of #2 in my mind are that it is less intuitive (breaks the old way we think about TLDs) and that we better be damn sure of the final "TLD" sale model.

There is a legitimate worry that we may not get the sale model for the global TLD right from the beginning. At least the good thing about a pure leasing model is that if we have to change the rules, people can let the price readjust when their lease expires. My hope is that we don't ever have to change the rules of a sale model after it has been launched.

.p2p
    .own
    .key
    .legacy
         .com
    .user-TLD-1   (won by agent86 model)
    .user-TLD-2   ""

It is p2p DNS system. +5%

So to be clear for newcomers, we're now discussing which of these hierarchies makes more sense / is more marketable:


BDNS
    .p2p  (the ".own" model)
    .key
    .agent86-model
    .com   <-- legacy forward


.p2p
    .own
    .key
    .legacy
         .com
    .user-TLD-1   (won by agent86 model)
    .user-TLD-2   ""



Agent86 and arhag seem to prefer #2. Disadvantages of #2 in my mind are that it is less intuitive (breaks the old way we think about TLDs) and that we better be damn sure of the final "TLD" sale model.

Quote from: toast 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?

+5%  these ideas seem fine to me.

Quote from: Empirical1 on August 07, 2014, 11:18:35 PM

Quote from: toast on August 07, 2014, 11:06:35 PM
Is the good name ".p2p" still valuable if it is hidden during normal operations? If we used ".own" then it does not collide with any ICANN and so our extensions / resolvers would only need someone to type "example.own"

Is it a technical problem if it collides with any ICANN or is it an ambiguity problem?

Ambiguity. Our resolvers work like "is it a BDNS TLD? if yes look it up on blockchain, if no look it up on old DNS"

Quote from: toast on August 07, 2014, 11:06:35 PM
Is the good name ".p2p" still valuable if it is hidden during normal operations? If we used ".own" then it does not collide with any ICANN and so our extensions / resolvers would only need someone to type "example.own"

Is it a technical problem if it collides with any ICANN or is it an ambiguity problem?

As in you don't think people will want to type Amazon.com in BDNS if it doesn't resolve/take you to the real 'Amazon.com'

Is the good name ".p2p" still valuable if it is hidden during normal operations? If we used ".own" then it does not collide with any ICANN and so our extensions / resolvers would only need someone to type "example.own"

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?

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"

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