7674b879eb
many files updated with trivial fixes. modified: docs/design/TCP.md modified: docs/design/peer_socket.md modified: docs/design/proof_of_share.md modified: docs/estimating_frequencies_from_small_samples.md modified: docs/libraries.md modified: docs/libraries/scripting.md modified: docs/manifesto/May_scale_of_monetary_hardness.md modified: docs/manifesto/bitcoin.md modified: docs/manifesto/consensus.md modified: docs/manifesto/lightning.md modified: docs/manifesto/scalability.md modified: docs/manifesto/social_networking.md modified: docs/manifesto/sox_accounting.md modified: docs/manifesto/triple_entry_accounting.md modified: docs/manifesto/white_paper_YarvinAppendix.md modified: docs/names/multisignature.md modified: docs/names/petnames.md modified: docs/names/zookos_triangle.md modified: docs/notes/big_cirle_notation.md modified: docs/number_encoding.md modified: docs/scale_clients_trust.md modified: docs/setup/contributor_code_of_conduct.md modified: docs/setup/core_lightning_in_debian.md modified: docs/setup/set_up_build_environments.md modified: docs/setup/wireguard.md modified: docs/writing_and_editing_documentation.md
365 lines
19 KiB
Markdown
365 lines
19 KiB
Markdown
---
|
||
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)
|
||
|
||
{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.
|