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.