BitShares Forum
Other => Graveyard => KeyID => Topic started by: toast 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.
-
This sounds like something we should discuss this with marketing.
-
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.
-
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 (https://bitsharestalk.org/index.php?topic=6561.msg87104#msg87104), a variation of it, maybe the domain tax model (https://bitsharestalk.org/index.php?topic=6561.msg88961#msg88961) 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 (http://data.iana.org/TLD/tlds-alpha-by-domain.txt) 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.
-
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?
-
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.
-
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"?
-
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.
-
+5% I generally agree with arhag's thoughts on this subject.
-
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...)
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.
-
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!" ?
-
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.
-
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).
-
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"
-
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?
-
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 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"
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"
-
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.
-
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.
-
.p2p
.own
.key
.legacy
.com
.user-TLD-1 (won by agent86 model)
.user-TLD-2 ""
It is p2p DNS system. +5%
-
I would revise the structure to be:
.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 ""
... ""
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.
-
Sorry, if I'm asking the same kind of dumb question in 5 different ways,
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?
-
.own seems very palatable
-
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.
-
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
-
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.
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...
-
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.
Sure, it's possible, but I think it's a bad idea. It's better for adoption (and less user confusion) if BDNS users using domains on legacy TLDs get to the same website they would get to if they were using a browser without the the BDNS extension. It is only when they use the newly created BDNS TLDs (leased using the carrying-cost model) or domains under the new .key or .own TLDs that they will take advantage of the BitShares DNS system.
Getting back to the Google example: a user Alice could always buy google.own in the auction by bidding the most; a user Bob could always register google as a KeyID if they were the first one to get it; and, a user Charlie could always bid the highest lease rate to lease the TLD google. The URL "http://google/" would take the web browser to Charlie's website. The URL "http://google.key/" would take the web browser to Bob's website. The URL "http://google.own/" would take the web browser to Alice's website. And the URL "http://google.com/" would of course take the web browser to Google's website. Now if Google decides they want to give this BitShares DNS thing a try, they cannot take over google.key, but they can take over the google TLD and also the google.own domain, if they are willing to pay for it. They can easily raise Charlie's lease rate until he is forced to give up the lease to Google. And, they can also buy google.own (if they even care since they would already have the more desirable TLD) from Alice (or maybe just threaten to sue her for trademark infringement if they can figure out her true identity).
-
By the way, I would also reserve "localhost" on the global TLD namespace. It isn't strictly necessary since I don't think anyone would pay any money to lease a TLD that will be useless since every machine is going to be setup to override it to 127.0.0.1, but we might as well reserve it.
-
I was thinking most of this evening and I came to the conclusion that agent's model needs and explicit TLD, that there should not be any implicit meta-tld, the "system name" should not be .p2p, and the global namespace should not have a mix of network- and user-managed TLDs. I will explain tomorrow.
Sent from my SCH-I535 using Tapatalk
-
@arhag here are some more thoughts about your proposed hierarchy:
* The "no TLD" default mode for our master sales model has usability problems because all browsers nowadays have omnibars (I use mine all the time). So whatever the master sales model is, it needs its own dedicated TLD. Suppose just for this post that we call it ".agent"
* I think having ".p2p" as the "meta-TLD / ICANN replacement" reads like a type error. Since you'd have to type the full sub-TLD every time, and it is unambiguous with just the sub-TLD, there wouldn't actually be any .p2p domains. It would be either "name.agent" or "name.own", which are both implicitly "name.agent.p2p" and "name.own.p2p".
* The solution where most ".p2p" names are from the agent model, but a few are reserved for other models, is also a mental type error. Imagine explaining "example.own.p2p was sold via ownership model, but example.pwn.p2p is a subdomain of a name sold via cost carrying model"
In conclusion, I think this is the correct thing to do:
BlockchainDNS ("decentralized ICANN")
.own ownership model
.web cost-carrying model
.key KeyID
But it seems like a shame to not use ".p2p" and so I think we should "waste" it, giving us these options:
BlockchainDNS
.own
.p2p
.key
OR
BlockchainDNS
.p2p
.web
.key
I prefer the 2nd one.
-
* I think having ".p2p" as the "meta-TLD / ICANN replacement" reads like a type error. Since you'd have to type the full sub-TLD every time, and it is unambiguous with just the sub-TLD, there wouldn't actually be any .p2p domains.
Agreed, there is no need for meta-TLDs.
* The "no TLD" default mode for our master sales model has usability problems because all browsers nowadays have omnibars (I use mine all the time). So whatever the master sales model is, it needs its own dedicated TLD. Suppose just for this post that we call it ".agent"
I don't think this is as much of an issue as you are making out to be. In chrome, you can configure your search engines to use whatever keyword you want. By default, you can type "google.com<space>search terms" and it will do what you expect. But you can also set it up to be more convenient by going into Settings -> Manage search engines, and changing the keyword to say "g". This allows me to search by just typing "g<space>search terms". Since a space before the first / means the text in the Omnibar is not a valid URL to a domain, Chrome is able to know you are not talking about the TLD g.
* The solution where most ".p2p" names are from the agent model, but a few are reserved for other models, is also a mental type error. Imagine explaining "example.own.p2p was sold via ownership model, but example.pwn.p2p is a subdomain of a name sold via cost carrying model"
Do users really care which model was used to purchase a domain? Only the buyers should care about that. They can afford that slight mental burden in my opinion.
-
* The "no TLD" default mode for our master sales model has usability problems because all browsers nowadays have omnibars (I use mine all the time). So whatever the master sales model is, it needs its own dedicated TLD. Suppose just for this post that we call it ".agent"
I don't think this is as much of an issue as you are making out to be. In chrome, you can configure your search engines to use whatever keyword you want. By default, you can type "google.com<space>search terms" and it will do what you expect. But you can also set it up to be more convenient by going into Settings -> Manage search engines, and changing the keyword to say "g". This allows me to search by just typing "g<space>search terms". Since a space before the first / means the text in the Omnibar is not a valid URL to a domain, Chrome is able to know you are not talking about the TLD g.
I think it's a bigger deal than you think. There is absolutely no reason to break millions of users' habits, especially if we agree that there doesn't need to be a meta-TLD and so all domains explicitly end in TLD.
* The solution where most ".p2p" names are from the agent model, but a few are reserved for other models, is also a mental type error. Imagine explaining "example.own.p2p was sold via ownership model, but example.pwn.p2p is a subdomain of a name sold via cost carrying model"
Do users really care which model was used to purchase a domain? Only the buyers should care about that. They can afford that slight mental burden in my opinion.
It matters because it is totally unintuitive that a few special TLDs have different rules for "subdomains" - in almost every case "sub.name.p2p" and "sub2.name.p2p" are controlled by the same entity, but not in the case of "sub.own.p2p" and "sub2.own.p2p". This matters to the user, not just the buyer.
Point is, we need explicit TLDs for each ruleset.
Let's get back to talking about: What is a good TLD for agent's model?
You guys seem to want to use ".p2p" for agent's model and ".own" for the ownership model. I'd rather use ".p2p" for the ownership model and ".web" for agent's model, if we can use ".web" without trouble.
-
I disagree with your opinion about the omnibar. Since chrome has been invented, when the average person types "Hercules" in the omnibar they want to search google for information on the movie or the historical character. I don't want to go to the website for the Bluetooth device. (Hercules.com) I certainly don't want to have to change any settings to search for anything.
I agree with @Toast. I like the second method.
* I think having ".p2p" as the "meta-TLD / ICANN replacement" reads like a type error. Since you'd have to type the full sub-TLD every time, and it is unambiguous with just the sub-TLD, there wouldn't actually be any .p2p domains.
Agreed, there is no need for meta-TLDs.
* The "no TLD" default mode for our master sales model has usability problems because all browsers nowadays have omnibars (I use mine all the time). So whatever the master sales model is, it needs its own dedicated TLD. Suppose just for this post that we call it ".agent"
I don't think this is as much of an issue as you are making out to be. In chrome, you can configure your search engines to use whatever keyword you want. By default, you can type "google.com<space>search terms" and it will do what you expect. But you can also set it up to be more convenient by going into Settings -> Manage search engines, and changing the keyword to say "g". This allows me to search by just typing "g<space>search terms". Since a space before the first / means the text in the Omnibar is not a valid URL to a domain, Chrome is able to know you are not talking about the TLD g.
* The solution where most ".p2p" names are from the agent model, but a few are reserved for other models, is also a mental type error. Imagine explaining "example.own.p2p was sold via ownership model, but example.pwn.p2p is a subdomain of a name sold via cost carrying model"
Do users really care which model was used to purchase a domain? Only the buyers should care about that. They can afford that slight mental burden in my opinion.
-
I worry that this makes BitShares DNS less powerful than it could be. Big companies are soon enough going to be able to get desirable TLDs like .google, .facebook, .apple from ICANN. But in BitShares DNS the best that we will ever let them get is google.own or google.web? Convincing companies to join our system is already going to be hard enough.
I disagree with your opinion about the omnibar. Since chrome has been invented, when the average person types "Hercules" in the omnibar they want to search google for information on the movie or the historical character. I don't want to go to the website for the Bluetooth device. (Hercules.com) I certainly don't want to have to change any settings to search for anything.
Keep in my mind that if you type a search query with more than one word, Chrome will know you want to search and are not trying to type a URL. So if you type "Hercules movie" everything would still work just like you are used to even in my proposed model. Personally I think typing a one word name into the Omnibar and going to the best website for that name (as determined by market prices) wouldn't be so bad. Think of it as the "I'm feeling lucky" option in Google search.
Anyway, if the community decides against leasing TLDs then at least my preference would be to have .own for the guaranteed-ownership model and .web for the carrying-cost model.
-
I suppose another way to ask this could be, "what is a good TLD to experiment the carrying-cost model with before it is upgraded to become the TLD meta-TLD".
So if your vote is ".web" then maybe eventually "google.web" would just be "google" while "google.own" would remain "google.own"
-
I suppose another way to ask this could be, "what is a good TLD to experiment the carrying-cost model with before it is upgraded to become the TLD meta-TLD".
So if your vote is ".web" then maybe eventually "google.web" would just be "google" while "google.own" would remain "google.own"
That could be a fair compromise. Obviously, if we do later make such a change, the price of names in the .web namespace are going to all drastically change. Most names would become more valuable. But some names like "key", "own", "localhost", "com", "org", etc. would drop to zero value all of a sudden.
-
For the record I'm against the TLD ownership perspective, I'm just trying to get people talking about TLD names =P
So we've come to ".web" - great. What happens if ".web" gives us too much trouble (it is like a squatted TLD that ICANN can't get figured out).
Perhaps ".we" ?
-
Fair enough on the omnibar concept.
But seriously, .own? Sorry arhag, but I would rather not have any association to the Oprah Winfrey Network. .web is great because it's generic and already means something. And I really like the idea of keeping around .p2p. Still siding with Toast on this one.
-
How about .P2P and .P2PTLD?
-
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.
-
Why not make new TLDs createable if there is enough demand? It could have a system where anyone can start a new TLD for free (as long as it doesn't interfere with any reserved words, like existing TLDs and large company names) and if enough people put money down for names under this TLD, then it is created and shareholders turn a profit. The best new TLDs will naturally pick up steam, as others will want a slice of that pie. Every name would be sold as an auction, so early 'squatters' of that TLD would just get outbid.
If .p2p (or .own or .dac or anything else) is desirable, the market will speak for itself.