---
title:
    Zooko’s Triangle
...

# Zooko Identity

In a decentralized system with no trust anchors how do you figure out
which name is the right one with any certainty.  If you are texting to “Bob”,
how do you know you have the right “Bob”?  There are a lot of Bobs.

Zooko’s triangle is the solution to this problem. It is explained in several places

- [An Introduction to Petname Systems](petnames.html)

![](zookos_triangle.svg){width="80%" height="auto"}

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
on that link, you go to data about that person.

What actually gets sent, computer to computer, when Ann mentions Bob
in a message to Carol, is not the the local petname that that Ann typed into
her text, but the globally unique identifier, which should be, and usually is,
the public key or information uniquely identifying the public key, and
possibly the nickname, the display name, and information on
how to direct a message to that party.

The display name is long, humanly meaningful, and usually
probabilistically unique to humans, but inconvenient for typing in full in
text, unlikely to be typed correctly, likely to be incorrectly formatted for
reply-to and cc fields, and often likely to disrupt the flow of text were it to
be directly typed as part of a paragraph.

The nickname is a potential petname, or can be mangled into a locally
valid petname without too much mangling.

Display names and nicknames are unique on any one forum  If one public
key, one nickname and display name on any one forum.  Different people
can have the same nickname and display name on different forums on
different forums.  But if they do, if there is one Bob on one forum and a
different Bob on another forum, they are going to nonetheless have
different local petnames on your computer, and if one Bob sends you a
private message, it will appear in a different message thread to that other
Bob’s message thread.

What appears in the address fields, and in references to particular people
in the middle of a paragraph, is always locally unique, one distinct local
petname for each globally unique public key.

In practice, you don’t rely on petnames to distinguish people, though they
are quite adequate for distinguishing people, but on the fact that the
threading software associates messages coming from the same public key,
just as when you see text messages coming from the same phone number
on your phone, you see them displayed with previous text messages and
replies to that phone number, and pay little attention to the phone number.

In most contexts, you don’t actually need to look at, or even remember, the
phone number, and you don’t actually need to look at, or even remember,
the petname.  You click on the “reply to” button, and the software fills in
the appropriate local petnames, which become the appropriate global
identifiers when the message is sent, and when the parties receive the
message, it gets threaded according to global identifiers, and they see their
local petnames for people.  Same as with phone numbers on your text
messaging application on your phone.  No one needs to see phone numbers
these days, and even less do people need to see public keys, and seldom
need to pay attention to local petnames.

# The full and correct implementation of Zooko UI

All existing systems are half incomplete and unsatisfactory:

> Bitmessage will never be popular, period. The common pleb
> doesn't give a shit about privacy or anonymity or security, and just
>  happily uses Fecesbook. The slightly advanced computer user
> uses the "more secure" instant messengers, that offer a proper GUI and
> easy usage. The only people using bitmessage are literally some
> groups of nerds, the unfortunate few, who have coriously stumbled
> here (for a minute, until they realize what the public channels look
> like), or trolls that need an outlet for their mental diahrea.
>
> 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

> remember when @`JohnSmith71` said ...

 then this gets translated on sending to

> remember when @{John_Smith, Dark Lord of attack resistant cryptography} #`BM-NB5cJuoFTkcmNEKDcBwn1RDxYDX3gGbq` said ...

 and when displayed to Carol, gets represented as:

 > remember when @`JohnSmith` said ...

 because the guid is already defined on her computer as the local petname JohnSmith.

If it is not yet defined, then she sees the full set of Zooko names, as sent:

> remember when @{John_Smith, Dark Lord of attack resistant
> cryptography} `#BM-NB5cJuoFTkcmNEKDcBwn1RDxYDX3gGbq` said ...

Petnames preceded by the '@' symbol get translated to the full Zooko
nameset on being sent from the local context where the petname is
defined, and the guid gets translated back into the corresponding locally
defined petname on entering a local context where a petname is defined
for the guid of that nameset.

When receiving a message that references a known guid, the same guid
always translates to the same local name, even if the nickname and
fullname is different.

The same guid can have many nicknames and full names, and the same
nickname and full name might by used by many different entities with
many different guids.  But people should try to avoid that, by choosing full
names likely to be globally unique, and nicknames likely to be locally
unique on the systems of the people they communicate with.

If someone maliciously chooses the same full name as someone else, in
order to deceive the recipient of the message, the computer will see the
guid, and assign him a different petname.  To protect oneself against
against people pretending to be oneself, one should choose a nickname
likely to get a short and distinctive petname assigned on the recipient's
computer.

Everyone's system will record each association between a full name and a
guid that is sees, the time at which it saw that association, and the guid
asserting the association.  If it sees a later guid claiming a nickname that
corresponds to an existing petname, it treats this as strong reason to
suspect the entity who knows the secret key corresponding to the guid
making the assertion of scamming, spamming, and shilling.  If it sees two
different guids with the same full name, also strong reason for suspicion
Two guids with the same nickname, weaker reason for suspicion.

If you send a message to an entity defined by a guid, or add a guid to your
address book, or if you compose a text containing a full Zooko nameset,
perhaps because you are replying to a message that references an entity
that has no petname on your system, you will asked to whether you want to
store that full Zooko nameset under a local petname on your system.

# Moving to a global Zooko system

Zooko’s triangle is, among other things, a user interface concept for
storing, managing, and communicating, cryptographic capabilities.

Zooko’s triangle solves half the problem: provides a trusted path. If
you trust Bob, and Bob trusts Carol, you can trust that Bob’s
introduction to Carol will in fact bring you to the correct Carol.

This, of course, assumes a browser is somehow able to use Zooko style
links, rather than PKI links.

The problem then becomes having large number of trusted introduction – a
map between human phrases, and documents containing information about
globally unique identifiers that are relevant to that phrase: Something
like Wikipedia, but without centralized authority forbidding “original
research”, aka any deviation from official government truth, and
something like a search engine.

To solve the problem of making Zooko style links useful, we have to
solve the problem of providing global data that is not state dominated.

Past experience with cryptographic capabilities is that if users are
expected to consciously and intentionally use them, they screw up, that
even experts screw up, and that end users are not only reluctant to use
them correctly, but find it profoundly difficult to use them at all that
even expert users find them a pain, as for example the regular
unpleasantness of installing a certificate on a web server so that it
can do https.

Zooko’s triangle, correctly implemented, should hide from users that
they are using cryptographic identifiers, or indeed any globally unique
identifier.

Because globally unique identifiers have become almost as ugly as
cryptographic identifiers, we have already implemented interfaces that
hide globally unique identifiers, for example the bookmarks folder, the
buddy list, and the email contacts list. And since those identifiers are
already hidden, they can be cryptographic, giving the user many
benefits, and no extra grief.

We can do this with not one extra click for security, and indeed will
have to do so, for experience has proven that if we ask the user for
extra clicks for security, the user becomes frightened and confused, and
even supposedly expert users do not provide those extra clicks.

In order that references to objects can be securely transmitted across
trust boundaries, they need to be cryptographic capabilities

You don’t want people sending you spam pretending to be your webmaster,
or your email host, or your employer, or your bank. You want to share
files with certain people, but not always with the entire world, you
want to give some people, but not others, the ability to edit particular
files. When someone trusted recommends a bank, or a firm, you don’t want
some scammer connecting you to himself, instead of the bank you are
trying to connect to.

IM buddies, email contacts, and important web pages should be
cryptographic capabilities. When you click on a link, it should take you
to the web page the author you are clicking on intended. When you
receive a message that purports to be from an entity you have a
relationship with, it should be from that entity, and when you receive a
message from an entity you do not have a relationship with, it should be
obvious you do not. All messages should have in the headers “Regarding
.....”, which refers to a particular capability to contact you – which
usually is the particular capability to contact you contained in some
previous outgoing message sent by you.

Further, if we had a way of routinely and easily handling cryptographic
capabilities, lots of things that are now inconvenient and unsafe, such
as web money, could be made considerably easier and safer.

# Monetizing a system of Zooko identity

Information wants to be free, but programmers want to be paid.  The
primary reason for centralized name systems is that people can make
money off other people's internet and corporate reputations.

Names have value, when embedded in a network of names linking to
names, because reputation has value.  We can create secure pseudonymous
payment using cryptography, but cannot create secure delivery of goods
and services using cryptography.  The other side of the transaction needs
reputation.

[sovereign corporations]:../manifesto/social_networking.html#many-sovereign-corporations-on-the-blockchain
{target="_blank"}

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
network analysis.