By Christopher Lemmer Webber, based on conversations with Mark S. Miller.
Zooko's Triangle tells us that naming systems can have two out of three properties: decentralized, globally unique, human meaningful. DIDs are decentralized and globally unique, but are intentionally not built to be human readable, and yet are meant to be used by humans. Consider the following example DID:
did:example:fbc0f54d1a084b469490ff78d55632ea
Identifiers like this look like gobbledygook to you and me, so how can we use them?
Petnames offers a way forward by mapping local names to global identifiers and vice versa. By adding petnames as an additional layer to a globally unique and decentralized system, we are able to have names with all three properties.
At its simplest, petnames are not unlike smartphone contact lists
which map human readable names to less human readable telephone
numbers and vice versa.
A user can look up a user's phone number by a name they know and
are familiar with, and even an incoming call from a telephone number
can be displayed as coming from a familiar name.
Such a contact list is useful even if one has an external "Yellow
Pages" style telephone directory; there may be hundreds of Bob Smiths
in your city's telephone book, but only one of them is your next door
neighbor Bob Smith.
(Even if you know multiple Bob Smiths, you could always record them
separately and unambiguously as Bob Smith (neighbor) and
Bob Smith (accountant).)
But Petnames go further: participants may introduce other participants to each other or ask about one another (including asking semi-centralized "oracles" or directories of information). These names may be recognized and recorded, but Petnames systems remember history about how names come to be known. Critically, petname-using systems do (and even must) display names differently depending on how the name is known. This turns out to be important for security purposes and requires some coordination with programs' user interfaces, as we shall see.
Alyssa checks her inbox and sees an interesting message from
did:example:74cbe1a1774445ee8c18660033b06723 announcing a special
lecture on mathematics that the sender is presenting and asking if
Alyssa has any friends who may be interested in attending it.
The message is from Dr. Nym, who is both a professor at Alyssa's
university and also, as it turns out, her mother.
But the program that Alyssa is reading her messages from does not
display did:example:74cbe1a1774445ee8c18660033b06723, it says
Mom.
"Mom" is distinctly rendered in a way that helps Alyssa remember that
she set the name Mom... perhaps the whole name is rendered in a
box with a star next to it.
(Alyssa has only one Mom in her address book.
Were her family situation different, she may have multiple Moms, but
they would have distinct names in her Petnames database like
Mom (Alice) and Mom (Beatrice).)
While Alyssa calls her own mother "Mom" when she's talking to her, she sometimes introduces her mother to other people and would like to suggest a name that they refer to her by. It wouldn't make sense for others to refer to Alyssa's mother as "Mom" since they probably have their own mothers. Instead, Alyssa has set her Petnames database so that when she introduces her mother to others, she suggests the name "Dr. Nym".
Alyssa thinks her friends Ben and Eva may like to
attend the lecture and forwards the message to them.
Ben has known Alyssa's mother for a long time and already has a local
Petname for her which says Susan (which is Dr. Nym's first name, and
Ben's longstanding friendship with Alyssa means he knows Alyssa's
mother on a first-name basis), also rendering as a locally set name
with a star.
However, Eva has never met Alyssa's mother before.
The incoming message suggests the name "Dr. Nym" (email similarly
allows senders to suggest names for participants) and is
added to Eva's Petnames database.
However, Eva's petname database does a couple of things: it marks that
this name was given "by introduction" and adds a small amount of
random identifier information alongside it.
When it renders in Eva's mail reader, she sees
Dr. Nym::from Alyssa with an icon that shows two people
with an arrow drawn between them.
This is important because Eva can tell that this name was given to her
by introduction (hovering over it might even tell her additional
context).
The :: is special syntax in this petnames implementation and is
only used as a separator, and from Alyssa is a "path" generated by
the application to convey context about the introduction.
(If an introduction was made without enough context, a name such as
Dr. Nym::1 might be given.)
Eva is grateful for this because, while this is the first Dr. Nym she
has been introduced to, she previously was introduced to several Bob
Smiths and was glad that the world did not have to agree on only one
Bob Smith in order for those Bob Smiths to exist (the Bob Smiths were
grateful that they did not have to settle on one Bob Smith either).
Eva decides to attend the lecture and trusts that a name that Alyssa
would have suggested would be a correct name for this person, and
decides to reify the name Dr. Nym as her own manually set
local petname for the professor, and the display of the name updates
accordingly with a friendly star.
When she receives communication from or about Dr. Nym in the
future, she will be aware that it is this particular Dr. Nym
within the network of people she knows, and not some other
Dr. Nym.
Eva also sets this name to be the same external name by which she
introduces Dr. Nym to others.
Meanwhile Carlos encounters a note about the upcoming lecture on a
local bulletin board.
Carlos isn't particularly close friends with Alyssa, though he does
know Eva, and for whatever reason whoever posted this message to the
board merely left a QR code for Dr. Nym's DID without any additional
context.
Carlos wonders who this lecturer may be, so he asks his local web of
trust (or one may say "Carlos's social network") for suggestions.
Eva's computer responds by suggesting that the name "Dr. Nym"
may be appropriate and so Carlos's petname database adds this, also
recording that this was a suggestion through the web of trust and
adding a bit of random identifier information.
This renders as Dr. Nym::from Eva with an icon of a web, reminding
Carlos that this came from his web of trust.
Carlos also queries the campus directory (an oracle, and many oracles
could be queried or added to one's web of trust) to find out whether
Dr. Nym is a member of the faculty (she is) and reads more about
her local biography there.
Since the directory responds with information about Dr. Nym,
Carlos's petname database could add a record by introduction from the
directory, or depending on how it is configured, Carlos's petname
database may decide that since it already has a suggested name for
this DID that it doesn't need to keep accruing names.
It's important that Petnames-using applications render different kinds of Petnames in different ways. If Mallet sends a message to Alyssa asking her to pay for a birthday gift for a relative and suggests the name "Mom" or "Dr. Nym", this suggested name will render differently than if Alyssa had set this name herself or if one of her friends suggested it.
Petnames are an old but powerful concept and date back to the 1980s as part of the pioneering Electric Communities distributed social game. Unfortunately, until now Petnames have mostly lived in obscurity. The time has come for that to change: with the introduction of DIDs and the re-growth of peer to peer networks, Petnames bring human readable names back to decentralized systems while remaining truly "self sovereign".