A Zooko name system can only be useful inside a user interface that detects name collisions in human readable names by looking at the globally unique public key and substitutes, or insists on someone substituting, a securely unique local human readable name (petname).
Without this essential piece of machinery, which no one ever gets around to implementing, the unbearable load of distinguishing public keys is dumped on the end user.
Zooko's triangle is thus a design for enabling humans to navigate public key systems, an as yet unimplemented design, though everyone, by rubbing up against problems, usually winds up implementing ad hoc something resembling a partial, incomplete, internally incosistent, and somewhat defective implementation of the Zooko name system.
- [Lambda for Humans: The PetName Markup Language](http://www.erights.org/elib/capability/pnml.html)
Each identity, whether a human, a server, or something else, has a globally
unique cryptographic identifier, which is not human readable or human
memorable, a title or display name, which is human readable but not
necessarily easy to type correctly or reproduce exactly from memory, a
nickname, which is not globally unique, is likely to be unique among the entities that you are dealing with, but not necessarily unique, even among them.
The petname is the name that your system calls this entity, not necessarily
what any other system calls this entity, a name constructed by or your computer, typically constructed from, or identical to, the nickname.
The petname is locally unique, human readable, and human typeable. It is how you know this entity and reference it.
The computer is responsible for doing the mapping as needed, and
makes sure that when you connect to Bob, you are connecting to the right Bob.
Typically the globally unique cryptographic identifier is a public key, and
only Bob knows the correct corresponding secret key. If the thing
identified is an immutable data structure, the globally unique
cryptographic identifier is a hash of that data, according to the hashing
rules for that data type and data structure, which type and structure you
very likely do not know and will not learn until you contact the system
that has the data.
# Zooko’s triangle today
We now have a lot of systems that to a greater or lesser extent implement
Zooko’s triangle, and while they are frequently incomplete and
unsatisfactory implementations, they all do a sufficient job of making sure
you are talking to the right Bob.
The way it works as (more or less) implemented today (frequently less) is
as follows:
In private messaging, there are separate message threads for each public
key, just as when you text on a phone to and from a particular person,
there are separate threads for each phone number, unless you have
manually associated two different phone numbers with the same identifier,
and where the name appears in text in public or private messages your
local computer should associate a unique local petname with each public key.
And mostly they do, though existing software is frequently half assed
about this.
The petname is generated by mangling the nickname (and possibly part of
the display name) down to a valid locally unique identifier, unique on your
computer and following your computer’s local rules for valid identifiers,
which rules might well depend on the language locale in which the
computer is running.
Existing software fouls up on the local petname issue in a variety of ways,
but does a sufficient job to ensure that one person cannot impersonate
another person
The petnames appear in the text, and in the equivalent of reply-to and cc
fields, as @petname, but if “petname” is a local petname corresponding to
a public key that corresponds to the other party’s private key, it is colored
differently to the text and/or looks like a link in html. If you hover over the
link, you see the other party’s display name and nickname, and if you click
> As much as I think BitMessage is an interesting concept, you
> cannot avoid realizing that it's massively unattractive for wide adoption.
The Bitmessage UI is unbearable. What is needed for it to be popular is a
full Zooko name system. With a full Zooko name system, it is going to feel
much like one of the more popular apps.
A Zooko name consists of
- the Guid, the Globally unique identifier, for example the bitmessage Guid, "`BM-NB5cJuoFTkcmNEKDcBwn1RDxYDX3gGbq`", which represents
the public elliptic point of a secret scalar known only to the sender.
- the nickname, which is global and chosen by the entity named, but
probably not unique, Many people can, and usually do, have the same
nickname. The nickname starts with a letter, and is composed of
letters, numbers, and underscore characters, for example "John_Smith".
- The full name: The full name is likely to be unique, but only if the entity
named chooses it to be likely unique, for example
{John_Smith, Dark Lord of attack resistant cryptography}. The full
name can be any sequence of unicode characters that does not
contain unbalanced curly brackets, and the nickname is the first
sequence within the full name of three or more alphabetic, numeric,
or underscore characters starting with an alphabetic character.
- The petname, which is the local name of someone else on your
computer. This is locally unique, and defaults to the nickname, or a
name constructed from the nickname, unless that petname already
exists and names a different guid.
When your system locally constructs a default petname from a nickname,
it may mangle it in such a way that nicknames that look similar do
not have petnames that look similar.
When sending a message, you can reference a guid by the petname
For example, if Bob's petname for John_Smith is John_Smith71 (because he already had John_Smiths one to seventy as petnames on his computer), but Carol's petname for John_Smith is JohnSmith, and Bob sends a message to Carol containing the the text
So the other side of the transaction needs to be authenticated by a secret
that *he* controls, not a secret controlled by registrars and certificate
authorities. Enabling people to own their own names is an important step
towards enabling [sovereign corporations].
Most of the value in the world is not in productive machinery and land. It
is in “goodwill” – the value of names linked by names. And governments
registrars, and so on and so forth keep skimming that value, and from time
to time recklessly destroy it.
But someone has to be paid for enabling people to own their own
reputations.
How do we make money out of enabling people and groups of people to
own their own reputations?
The easiest and most obvious way is if we issue the money that they use to
transact on these reputations. Cryptographic transfer of funds is one half of
the problem. The other half is wondering whether the person you are
transferring it to will hold up his end of the bargain. Both parts need to be
integrated.
Reputations have value by being embedded in a network of reputations.
Google made a lot of money by analysing the network and making the
information readily available. My fundamental plan is that the keys used
for identity will be rooted in the same wallet as the keys used for
cryptographic coins, and thus communication carrying metadata about
transactions rooted in that wallet, resulting in an intimate linkage between
the crypto currency being valuable, and the information about reputation
secured by the same wallets being readily available.
And to make reputation embedded in the network of links from
reputations to reputations valuable, we are going to eventually need
network analysis systems similar to that provided by Google and others.
First mover providing such analysis will have a substantial first mover advantage, as Google has and still enjoys to this day, but the first mover advantage is likely to be less valuable, since lots of search companies
will simply add analysis of secure links, links rooted in secrets that are
controlled by the owner of the name to their analysis of links rooted in
government authority, rooted in certificate authority secrets answerable to registrars. On the other hand, being the source of the wallet software is
likely to be a substantial and lasting advantage in being source of the
