MCP DNS
One of the early problems conceptually with MCP was maintaining uniqueness of usernames. In a distributed, eventual-consistency system alone, you can't make those kinds of guarantees. MCP adds on a layer of signature blocking, which means that no read can occur except between writes, and no writes can collide with each other. Whenever you read, you are guaranteed the latest available version of the document. However, the overhead and the mob of write traffic makes this seem kind of impractical for large-scale uniquing. Things looked dark.
The answer came in the form of breaking the namespace up into virtual subdomains, with each level of heirarchy having its own MCP document. The transactional costs therefor become reasonable, your cache remains valuable, it's pretty simple to bootstrap the system, and the subdomains can go as deep as you want.
Basically, this is the same problem facing Hyperboria's DNS system right now, and in fact, DNS security on the world wide web as well. At least, the problem is similar enough for it to have a common solution. I've been working very, very hard over the last couple months to solidify the concepts and the code involved in a ConcurrenTree based, community-maintained registry. For the next few days, I'm going to post a series of Google+ articles detailing the continuing evolution of the registry system, and taking advice on what custom permissions flags registry documents need to support.
One of the greatest things is that as long as we can agree on some permissions flag meanings, subdomain registry setups can work according to any rules we want. The whole permissions system is based on high-level transformation constraints, enforced and verified by the participanting nodes in a document. With high-volume, high-participant documents like top-level registries, anyone operations that break the rules will be community-rejected at a machine level. Your device is part of the spam filter.