Cost of sub-namespaces

General Discussion
#1

Hi,

I just read deeper into namespaces and mosaics here: http://blog.nem.io/mosaic-and-namespace-public-testnet-release/

Be sure you have enough XEM in the account in order to create a
namespace. The fee for the creation of a root level namespace is 50,000
XEM and for a sub-namespaces it is 5,000 XEM.

That’s about $83 for a root level namespace and $8.3 for a sub-namespace. I’ve got a few questions about that:

  1. Where does the 50k/5k xem go to?
  2. Why is it so expensive?
  3. If you look at it like a domain/subdomain system, I expected to have only to pay for the root namespace and then have the possibility to create infinite sub-namespaces (free except of the tx fee)
  4. Imho, the greatest thing would be to allow a namespace owner to setup rules for sub-namespace creation: quantity, cost, expiration(?), approval needed or not, … Are you thinking about something like that?
#2
  1. Those xem go to the multisig account NAMESP-ACEWH4-MKFMBC-VFERDP-OOP4FK-7MTBXD-PZZA
  2. At the time we set the fees xem were a lot cheaper.
  3. The fee is there to protect from sub-namespace spamming. Every sub-namespace needs to be placed into the db and is cached in memory.
  4. Not planned. What would be a use case?
#3

Thanks for the answers @BloodyRookie. Some follow ups:

  1. Who has access to this account?
  2. ok, any plans to adjust them?
  3. Is it the same with mosaics? They cost 50k as well :frowning: So this feature might not suite to something like a public ledger for 1 million different ingame items of a mmo game? Like:

game:mmo:mosaic 1: Holy Sword, Qty: 2000, divisability: 0, transferable: true
game:mmo:mosaic 2: Icebreaker Blade, Qty: 25000, divisability: 0, transferable: true
…
game:mmo:mosaic 1000000: Holy Grail, Qty: 1, divisability: 0, transferable: true

Because this would 1st, flood the nodes memory and 2nd empty the game operators pocket.

Is it currently like that?

#4

and a use case to 4)

Applications could use a root level and allow customers/users to create sub-namespaces through the app. Maybe sub-namespaces or mosaics representing advertise which must be 1st approved and 2nd will expire.

Or let’s again fall back to a game metaphor:
The mmo operator could allow players to create clan sub-namespaces which cost $5/year. If the clan doesn’t pay timely, the namespace expires. Also, the operator must approve to filter offensive names.

#5
  1. Access is through the multisig protocol. Cosignatories are:
  • Saul
  • Ronel Li
  • Bloody Rookie
  • jabo38
  • gimre
  • mixmaster
    5 out of those 6 cosignatories are needed to make a transfer transaction succeed.
  1. I don’t think there are plans to adjust the namespace/sub-namespace fee.
  2. The fee for creating mosaics probably will get lowered and also the fee for transferring mosaics. But at this point nothing is decided yet.
  3. Not sure if we should use mosaics that way. Mosaics are kind of expensive in terms of management cost within NIS.
Пространства имён и мозаики (активы), псевдонимы (алиасы)
#6

Isn’t this very centralized? I thought one of the big pros of nem was the decentralized part. Wouldn’t it be better if buying a namespace etc would be treated like a normal fee (so the harvesters got the xem)?

#7

Giving harvesters the fees would lead to harvesters waiting to be able to harvest the next block and then put in many own namesapce provision transactions into the block. That would basicly mean they can get namespaces for free, so it is not a good idea :slight_smile:

#8

Couldn’t that be solved somehow? Like making the account that the xem currently goes to (for namespace purchases) spend all it’s balance on transaction fees (but implement the account/the feature directly into nem so it’s decentralized).

Anyhow you don’t see a problem with this being centralized at all BloodyRookie? I’m sure many people in this community would see this as a big flaw if this was the case in bitcoin or some other crypto.

#9

If there are funds of any kind, someone must have control over it. If it was a single person, then i would say it is a flaw because a single person can fail in many situations. If there are several persons involved in controlling a fund then the chance of failure drops considerably. It even drops more if the persons have been around for a long time and have contributed to NEM in a crucial way.
Having funds is important in order to be able to pay for third party development (for example the mobile app), marketing, payout for supernodes and so on.
So, all in all, I think our approach is reasonable.

#10

It’s true that it’s much much better that the account is controlled by multiple people and secured by multisign compared to if it was only controlled by a single person. But I still don’t think that is nearly enough, maybe for a company or for a product that handles a game or an in game currency, but not for NEM that aspires to be the internets, or maybe even the worlds currency. 6 people can easily be forced to do something against their will (or even worse harmed or killed) by a mafia or a government. As can 20 people be, as can 100 people be etc.

I don’t think such a crucial part of NEM as namespaces should be centralized in any way. I completely understand that a project as ambitious and big as NEM needs fund to be created and started, which is why I was completely okay with and backed the relatively big development funds (i.e. all xem that was created that the developers have/had control over). The difference is that those initial funds would eventually be spent and placed in the hands of NEMs users, the namespace account will “always” be there with centralized control. Like for bitcoin, funds for development on NEM can come from elsewhere than from fees placed on its users.

The coins developers/“guardians” can easily want to pull the coin/project in a very different direction (or no direction, as what happened/happens with bitcoin and the blocksize debate) than the users. I want NEM to be open and decentralized enough for it to be able to live on even if that is not the will of it’s main developers.

#11

So what do you suggest? Just get rid of it by pushing random harvesters? We already got the supernode program for the node owners.

#12

I don’t know what is the best idea, but yeah, I think sending the XEM out to random harvesters (or even better distribute it based on importance and vested balance) is a better idea than the solution currently in use. If you do that you could maybe cut down on the funding to the supernode program and use those funds for other things that are needed as well.

#13

You don’t need a node to harvest, you can just harvest on any available node. So basicly you are just distributing xem to rich/important accounts and that is not what you want i think. Supernodes on the other hand are tested and only good nodes get rewarded, that is a much better concept imo.

#14

Okay I see, maybe it’s better to give it to supernodes if that can be archived in a not to centralized way. I have gotten the impression that the importance was a “fair” way to distribute the xem from the fees etc? Wasn’t that like one of, or even the biggest, argument for using nem over nxt at the start?

But it’s not nearly as important to me how the xem from the namespace purchases are distributed as it is that it’s a decentralized system.

#15

But every other fund works the same way, why complain only about that namesapce fund?

#16

What other developer controlled fund gets new xem?

#17

Not talking about new xem but funds in general. Only two funds get new xem (namspace and mosaic fund).

#18

Yeah but the “getting new xem” is the part that i think is problematic. The other funds xem will eventuella be spread to nems users and disappear. As I said earlier: I’m sure many people in this community would see this (xem from namespace and mosaic purchases going to developer controlled funds) as a big flaw if this was the case in bitcoin or some other crypto.

#19

I don’t see it a big flaw. But you are free to raise your concerns to the community.

#20

Better to discuss this in another thread.

However, since it’s now clear that it’s not practical to create a huge amount of mosaics, the question arises how an application could master thousands of individual properties?

To become more specific, I’ve got an idea for an app which needs 10k identifiable and tradeable properties/assets. One mosaic with a quantity of 10k would not fit because they can’t be distinguished with individual information.
So is this even possible with nem? Any ideas for this?