You proved my point, the fees alone would prevent namecoin from scaling to the point that BitMessage + Namecoin could be a viable alternative to email.
Sure, you could claim that you do not believe it would see that level of adoption and that you *want* to limit the growth artificially but I believe that is copping out. Why wouldn't we want everyone who is using email now to use BitMessage in the future?
BitMessage scales, so all we need is a naming solution that also scales.
Also, people expect email accounts to be free. How long does it take them to mine enough namecoin to register an account?
Everyone using email can use bitmessage in the future instead of email, if they wanted? what is your point?
you can get 1 NMC to register >50 names for 0.4$
Free email accounts are sponsored by ads anyway. So it's ok for names to be non-free. Ad-sponsored coin faucets can mimic the ecosystem of ad-sponsored free emails, I believe (when the adoption becomes large enough).
BitMessage itself has hidden fees (in terms of required proof-of-work to send messages).
Sure, it is cheap to register names today the point is that if demand picked up then it would no longer be cheap. Also, hidden fees (proof-of-work) is kind of like hidden ads and people can accept that as long as they don't need to pull out actual money to use the system.
Ad-sponsored faucets... now there is an idea. Of course, that idea doesn't really scale well if the prices get as high as they would under the demand of 500 million users. The problem is the bandwidth usage & storage requirements which are just too costly with Namecoin when 500 million users are using the system (assuming they all run a full node).
So instead of just complaining about the bandwidth and storage requirements of namecoin let me make a proposal:
1) separate out the concept of name -> pubkey pairing from name - value pairing. For the purpose of BitMessage all you really need is the public key (33 bytes) for a given name.
2) don't store the name in the database, just store a 64 bit hash of the name. This will give you the best possible compression with only a 50% probability of a single collision with 1 billion users and a collision just means they have to pick a different name.
3) entirely eliminate signatures from the database, signatures are 65+ bytes each and provide no value for the purpose name=>key pairing
4) don't have it based upon a currency, no one wants to 'pay' for a 'user name' or 'email account', these things are disposable and people just select a different name if their first choice is in use, such as bytemaster1 if bytemaster is already taken. The purpose of the names is to make it easy to share your 'bitmessage address' with others.
Without any bookkeeping overhead, the minimal size per record is 41 bytes which would be 41 GB for 1 billion users and totally reasonable by the time we got to that many users. Of course, there must be *some* book keeping overhead in order to prove who has rights to what name and resolve conflicts. So I propose 'merged mining' on names / blocks. The minimal difficulty for mining a name is 1 CPU hour ($0.01 electricity). The difficulty would adjust so that one block is found every 5 minutes and no more than 10,000 names per block are registered per block and thereby enable about 1 billion renewals per year. The difficulty of the block is the average difficulty of the names included in the block * the total number of names. People mine for their own name only.
So what information would be required for a name registration transaction? nonce, time, prev_block_hash, merkle_root, name_hash, public_key all of which could fit into 82 bytes and when compressed into a block with 10,000 names would only require 720KB / block. This would require an average of 20 kbit / sec sustained with 1 billion users.
By requiring yearly renewal you can eliminate all blocks older than 1 year and each user contributes to securing the network once per year by mining their name for an hour. This process could be spread out as 10 seconds per day average mining effort.
No one would squat a name because they are not transferrable until they expire (transfers require signatures). A special exception may be made for canceling a name in the event your key is stolen.
Once you have this in place, Namecoin can be reserved for name->value storage which has entirely different requirements / costs.
I only bring this up because I want a universal name->public key system that is fully decentralized even if everyone in the world adopted it.
