Well, let’s find out, shall we?
We never wrote much about our design for identity. Our plan was to borrow a lot from folks we thought were getting this right with XDI/XRI/i-names.
This is basically “markdown for names”.
- “=” indicates “names for people”
- “@” indicates “names for organizations”
- “+” indicates “names for generic concepts”
- And many more intelligently conceived but confusing idioms
So they got the nomenclature down. But how about assignation of namespaces?
Ceptr’s identity model is similar in many ways [to XDR/XRI/i-names] with the biggest differences being that we use contextual name resolution instead of having a global top to the namespace…However, the fact that there is a central authority for addresses and names (even if they delegate some powers to ISPs and registrars)…point to some of the reasons why we need an even more open infrastructure that could operate completely peer-to-peer.
So that’s the why. As for the how, the MetaCurrency Project (MCP is to Ceptr as Maidsafe is to the SAFE Network) dives into a bit of detail (see my [interjections] for clarification):
##MCP Addresses & Namespaces
###Background
Central to any network is addressing and namespaces…[A] separation of concerns between the two levels of domain names [namespaces] and IP addresses [addressing], is that of “human-friendly” and “machine-friendly.” Humans find it hard to remember IP numbers strings, but easy to remember names that map well into our language space…
###MCP approach and assumptions
The meta-currency project’s approach to addressing: 1) Identity: MCP assumes that determination of the “true” identity of players will be an ever evolving process, so it does not build in identity into its addressing scheme. [This is mostly talking along the lines of Proof of Unique Human] 2) Location: MCP does not assume that players are directly accessible on the Internet. They may be behind telephones, carrier pigeons, etc, thus an MCP address is always considered a proxy for some other service that handles interaction with the “true” player, thus there is a layer of MCP addresses that are abstract and mapped onto internet addresses for use on the Internet. 3) Sovereignty: the MCP addressing scheme is designed around “inverted hierarchies”, which allow for mutual sovereignty between individuals and groups. [See below]
We also take a two level approach to addressing: 1) Meta-currency identifier (MCI) [namespace]. This address locates a player on the network abstractly. MCIs are the equivalent of domain names for the Meta-currency network. 2) URI [addressing]. All MCI resolve to a URI. The URI is a pointer to the peer(s) handling that MCI at given time. These URIs are equivalent of IP addresses for the meta-currency network. Just as an IP address of a given domain can change, so can the URI of a given MCI change. But MCI are unique. [Absolutely no explanation as to how the unique identifiers are created, determined, or enforced]
###Inverted Hierarchies
Internet domain names are classic top-down hierarchies. ICANN manages the top of this hierarchy, and all names live under it starting with the top level domains. This [MCP] model replicates the classical notions of ownership of a territory. The meta-currency project implements a looser, more flexible strategy for generating address space hierarchies. The idea is simply that: 1) there is no top level & 2) any group can associate with another group to form a new level above the two of them. [No explanation as to how the groups get their initial names] Thus the hierarchy emerges from cooperative behavior rather than being enforced from the top. The spaces that emerge then tend to be more about joint stewardship of a common resource, than ownership of a territory.
– Design for a MetaCurrency Platform - 2009 - pg. 9-10
As an aside, that last bit - “any group can associate with another group to form a new level above the two of them.” - is quite similar to how the GNUnet Name System operates (the up-down wording convention is flipped, but it is the same concept):
GNUnet includes an implementation of the GNU Name System (GNS), a decentralized and censorship-resistant replacement for DNS. In GNS, each user manages his own master zone which is mapped into the DNS namespace under the
.gnutop-level domain. Users can delegate subdomains to zones managed by other users [New level by combining the two]…A major problem of this approach is that names are no longer globally unique, requiring the use of proxies and other workarounds to address common requirements of legacy applications.
– GNUnet - Wikipedia
But by MCP/Ceptr, no more at all was said on the matter. While I agree with the motivation, I just can’t imagine that they gave this much thought on any technical level. For example:
As mentioned, this certainly includes the ability to have universal IDs, but that is fairly negligible part of the problem we’re addressing (so we don’t even mention it in our list). We can use something like OpenID for now, but in the long run we need a completely un-enclosable namespace with no central or top authority. [But that is a conversation we’ll reserve for another time.]
– Arthur Brock - 2009
But they do see it as an issue that “development of CEPTR protocols and platforms” is meant to solve.
This also demands…solutions to centralized namespace issues like DNS. We are currently addressing these problems with the development of CEPTR protocols and platforms.
– Metacurrency Project’s Linkedin
The one point that, if possible, I would impress upon the CEPTR members is that in a decentralized system, the solution is always going whatever is considered the lesser of two evils - there’s no ability to have unique absolute/global namespaces that prevent namesquatting. These two issues are mutually exclusive. Pick one.
So no, @happybeing, I do not think that they have any solution for “domain name squatting / namespace competition”, although they do recognize it as an issue, and I applaud them for their foresight.
EDIT:
P.S. Talking about namespaces, IMO they have a better name than us…