Page 1 of 1

Established namespaces vs. new namespaces - analyzing

Posted: Fri Mar 14, 2014 3:32 pm
by virtual_master
Let us see what advantage and disadvantage have to use an established namespace for a specific purpose over a new namespace:
Advantage:
- using some existing infrastructure(like nameid.org for id/ or proxies for d/)
- using existing implementations(like Bitmessage or OpenID support for id/ or existing browser plugin for d/)
- having already users which are using this namespaces, which have their IDs or .bit domains and new implementations can rely on them
Disadvantage:
- heavy name-squatting on established namespaces can make them less attractive
- a new service which expects many users and want to make his own community closed and more connected to his service could be motivated to create an own namespace
- namespaces with established infrastructure could(and probably will have) higher fee so this could be a migration reason toward other namespaces
---------------
My conclusion:
- Namespace entry registration fee scaling should not rely only on namespace difference but on other factors also like: name length and amount of data feeded in the blockchain. The higher fee for the implemented namespace should be in balance with the invested support in that infrastructure.
- Another possibility would be that all namespaces would have the same fee structure. In this case the supporting infrastructure for already implemented namespaces would collect fee. For example such a support infrastructure(like a proxy or nameid.org request or browser plugin) could collect 0.01 NMC in advance for 1000 user requests for a namespace entry. This would be more difficult to implement but would give a higher scalability for the network and could involve other parties which otherwise wouldn't take part by the Namecoin network.
----------------
Feel free to comment.

Re: Established namespaces vs. new namespaces - analyzing

Posted: Tue Mar 18, 2014 9:56 am
by biolizard89
My understanding is that duplicate namespaces actually make squatting worse. This can be seen with the massive rush to register high-value names every time a new TLD comes out. If I recall correctly, a bunch of major companies were pressured into buying .xxx domains because "you wouldn't want someone else to register your company name and put xxx content on the site, would you?"

Re: Established namespaces vs. new namespaces - analyzing

Posted: Tue Mar 18, 2014 7:32 pm
by virtual_master
Thanks for the answer.
biolizard89 wrote:My understanding is that duplicate namespaces actually make squatting worse.
I don't know if it will be worse but it will be two dimensional.
It was no advice from me to use new namespaces for established services I just analyzed what reasons could motivate new users to one or another solution.
biolizard89 wrote:This can be seen with the massive rush to register high-value names every time a new TLD comes out. If I recall correctly, a bunch of major companies were pressured into buying .xxx domains because "you wouldn't want someone else to register your company name and put xxx content on the site, would you?"
Somehow yes. It is also a good comparison.
But it doesn't matter what would I do. If our space has 2 dimensions some people will run using both dimensions.
It is like a swimming pool where some people want to swim straight but others zigzag. :)
We can put some markers to signal the swimming direction but if it is a free swimming pool then anybody can swim in whatever direction he likes.

Re: Established namespaces vs. new namespaces - analyzing

Posted: Tue Mar 25, 2014 2:23 pm
by georgem
hm, suppose I create a scifi multiplayergame (not realtime) where information about users/gameassets are stored in the namecoin blockchain...
say in the namespace mmpg/

Then I would go on and enter data in the form

mmpg/user123654

where I would enter a JSON string that I will associate with this user, so I can save a few informations about the game situation this user is in...
for example how many credits he has, what planets he owns, etc...
Most of the gamedata (that is not so important) would be saved on the server, outside of the blockchain ofcourse, but the most important most secured data (which could probably be expressed in 100 characters or less) would be placed inside the namecoin blockchain.

What problems do you see with such a scenario?

Ofcourse, why would anyone need to save gamedata on the blockchain, but I am just thinking out loud.

Re: Established namespaces vs. new namespaces - analyzing

Posted: Tue Apr 01, 2014 4:10 am
by biolizard89
georgem wrote:hm, suppose I create a scifi multiplayergame (not realtime) where information about users/gameassets are stored in the namecoin blockchain...
say in the namespace mmpg/

Then I would go on and enter data in the form

mmpg/user123654

where I would enter a JSON string that I will associate with this user, so I can save a few informations about the game situation this user is in...
for example how many credits he has, what planets he owns, etc...
Most of the gamedata (that is not so important) would be saved on the server, outside of the blockchain ofcourse, but the most important most secured data (which could probably be expressed in 100 characters or less) would be placed inside the namecoin blockchain.

What problems do you see with such a scenario?

Ofcourse, why would anyone need to save gamedata on the blockchain, but I am just thinking out loud.
There's nothing wrong with storing small amounts of data in the blockchain for arbitrary purposes, in my opinion. Just keep in mind that under the current fee system, the world population of ~8 billion people has a total supply of 2.1 billion names. So if your application will completely fail due to laws of supply/demand once Namecoin becomes more popular, then you may want to rethink your application.

Re: Established namespaces vs. new namespaces - analyzing

Posted: Wed Apr 02, 2014 9:27 am
by phelix
Image
Are all these new domains u/ ?

~40000 * 1kb (name_new + name_firstupdate) = 40mb of chain data... :roll:

Re: Established namespaces vs. new namespaces - analyzing

Posted: Wed Apr 02, 2014 11:15 am
by domob
phelix wrote:Image
Are all these new domains u/ ?

~40000 * 1kb (name_new + name_firstupdate) = 40mb of chain data... :roll:
Not sure. The rise started well before OneName was announced. Also, they told me recently that they have around 7,000 users at the moment. This is not few, but way less than 40,000.

Re: Established namespaces vs. new namespaces - analyzing

Posted: Thu Apr 03, 2014 1:16 pm
by phelix
domob wrote:
phelix wrote: Are all these new domains u/ ?

~40000 * 1kb (name_new + name_firstupdate) = 40mb of chain data... :roll:
Not sure. The rise started well before OneName was announced. Also, they told me recently that they have around 7,000 users at the moment. This is not few, but way less than 40,000.
hmmm.... users != names registered

But from a quick glance it seems there really are only 8600 names in u/ so far.

Re: Established namespaces vs. new namespaces - analyzing

Posted: Mon Apr 07, 2014 2:35 pm
by tosh0
oh, i write a long answer to this, and then didn't save it.
well, anyway.

As far as i know the fee it is the same for any namespace, people are free to use their namecoin any way they want to store data.

However it is recomended that you post what you are doing, and contribute to this open project, if you want any other people to be able to use your "new" namespace, atleast to prevent any conflict with other people and mainly so other people can write/use the same standarized rules. (ex. id\ u\ data\ etc)

Re: Established namespaces vs. new namespaces - analyzing

Posted: Wed May 14, 2014 8:50 am
by biolizard89
tosh0 wrote:oh, i write a long answer to this, and then didn't save it.
well, anyway.

As far as i know the fee it is the same for any namespace, people are free to use their namecoin any way they want to store data.

However it is recomended that you post what you are doing, and contribute to this open project, if you want any other people to be able to use your "new" namespace, atleast to prevent any conflict with other people and mainly so other people can write/use the same standarized rules. (ex. id\ u\ data\ etc)
Agreed. The non-enforcement of namespaces is intended as a check on the power of developers/miners, i.e. if we refuse to implement a feature, we can be overruled by users. This doesn't mean it's a good idea for people to be making up their own namespaces for public applications... things should be standardized whenever possible to maximize interoperability and reduce the risk of poor engineering.