Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
164 lines (145 sloc) 7.89 KB

Petnames for Self Sovereign and Human Readable Identifiers

By Christopher Lemmer Webber, based on conversations with Mark S. Miller.

Introduction

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.

An example

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.

Petnames for safe user experiences

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.

Epilogue

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".

You can’t perform that action at this time.