To Home page

Zooko’s Triangle

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.

Zooko’s triangle is explained in several places

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.

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.

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.

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.