Namecoin was a good idea, but it suffers from many flaws due to its DNS-based architecture, it's single block chain, and of course, the fact that it is based on the bitcoin block chain, limiting it's flexibility somewhat.
A few issues typical of the todays DNS systems (*but not Namecoin) are as follows:
"Parked" domains and hoarding
Commercial DNS redirection*
Tracking and traffic analysis*
Limited to specific domains
As you may know, Namecoin is one solution to Zooko's Triangle
, that is, addresses are secure, memorable, and global as well. The traditional DNS system is close, but not quite global due to consensus issues and censorship.
Namecoin is also easily susceptible to hoarders and "parked" websites caused by the way it is modelled on ordinary dns servers. It is also, by nature, impermanent due to the irreversible loss of coins upon creation of an address.
It is fairly simple to build a system that circumvents these issues and builds upon the decentralized and flexible nature of the Ethereum blockchain. Please let me know if you have any ideas for the following potential project.
If the implementation is based on Namecoin, we would have a single "name contract" and Ethereum would be spent in creating new addresses within the contract, the memory of which could quickly balloon and become costly in terms of processing power. On the Ethereum blockchain, a single name contract would be inefficient, due to these increasing costs.
Ie, the first address added would cost x ether to add to memory (including checks on whether it already exists, which grow as the number of addresses increase) , the nth address could therefore cost significantly more than the first. This may be a good thing, in that it prevents a exceedingly large number of addresses to be claimed for no content, but disproportionately benefits early users and domain trolling, which are both significant problems with Namecoin and the DNS system.
In an alternative situation, there are many "name contracts" with relatively small memories, and trust relationships between them.
A contract, [internally] named "hello" acts as a root server to a hypothetical user.
The contents of the memory of a contract can be used to either point to resources on or off the blockchain.
In the case of the "hello" contract,
(0,"hello", "[own contract address]")
(1,"jam10o", "[other name-contract address ]")
(3,"...", "... ")
Users can select their own root contract, and gain access to all contracts and addresses it links to. Name contracts can either
a) accept "submitted" addresses with address deletion controlled by a "moderator" or muiltiple moderators, using a scheme similar to the DAC example in the wiki,
b) be completely under the control of a single owner (such as, hypothetically me, owning the Jam10o name contract example above).
In the case of the above contract, the URL hello:world points to the Ethereum homepage. These relationships could be used to create a chain to any resource defined in any compatible contract, given the network is sufficiently linked. Potentially, it could also introduce annoying recursive urls, such as hello:jam10o:hello:jam10o:... ...:hello:world or, if contracts do not "return" links, an issue of "non-reversible" urls may come into play (hello:jam10o is valid, whereas jam10o:hello is not).
Using these contracts, anyone who needs to can own their own vanity url that is both memorable, secure, and globally accessible (with certain caveats) due to the need to have contracts link to each other. An unsavoury character may "park" muiltiple contracts on the blockchain, but without any users finding utility in them, their contracts will be "orphaned" from the web, which may act as a web of trust. A trusted user who provides utility to the community however, will certainly be linked by muiltiple contracts, increasing their visibility and traffic. Content may be self-censored in this manner, however due to the fact that the "censored" contract is still on the blockchain, it can still be easily accessed.
Therefore you have an un-censorable, but still moderatable and safe, dynamic naming system. Name resolution would need to be handled by an external client, which is why I put this in the "Projects" section of the forum:
A successful implementation of this system relies on a few elements:
A standard structure for participating contracts
An external DNS server linked to the Ethereum blockchain, capable of parsing the links between contracts
[and at some point in the future, a protocol that allows users to connect to one another without interception. Cjdns integration anyone?]
I'd love to hear what anyone has to say about this idea, feel free to implement it on the blockchain on release if it seems doable for you, (as the code will undoubtedly be reused by others). Discussion on possible contract standards, dns servers, and criticism of any flaws in the concept is welcome.