There are some niceties here, but I think this is a little thin on the security aspects of the scheme: it's not clear how users establish the authenticity of transitively received petnames, for example.
More fundamentally, there's a factor outside of Zooko's triangle: trust isn't really transitive[1]. I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling.
With that being said, I think there's a pretty rich research space here, and I think the edge/local aspects of this design are pretty interesting! I just hope we don't end up with a reinvention of historically insufficient web-of-trust architectures :-)
There's an associated paper that goes through implementing a petname system in a simple chat application. Petnames compose well with object capability security.
That's great, but I don't think it addresses the basic point: sharing edge names requires a way to share those names, and that's a trusted third party (one with a degree of centralization, to boot).
There are ways to (dis)intermediate that trust (like a PKI), but the shape of that PKI or other technique is itself a question of decentralization, security, etc. I think that's a very hard underlying problem that the petname design needs to at least offer some opinions on in order to make claims about security.
Jessica Tallon's implementation of petnames and edge names was extremely simple within the paper davexunit linked, but used in-band mechanisms to communicate edge names that didn't require any sort of large trusted authority. You could retrieve them directly from fellow peers, who could publish their current set of edge names. This even works in a p2p context over ocapn, etc. The implementation was naive but it did work and used a publish-subscribe mechanism directly from other peers.
That said, edge names are only one way to share contacts. In fact "share contact" on peoples' phones is a great way to have contextual sharing: "Oh, let me introduce you to my friend Dave. Here's Dave's contact info!"
At any rate, petnames aren't a particular technology, they're a design space of "Secure UI/UX". However I do agree more research needs to be done in that space; we've only barely begun to scratch the surface.
> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling.
Isn’t that because that’s a different type of trust? For example, you trust your doctor to give you decent medical advice, and they trust their sibling for emotional support. That doesn’t mean their sibling will be supportive of you, or give you good medical advice.
> trust isn’t really transitive
Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.
I would also trust a mutual friend over a complete stranger. But that's not the point of the observation: the observation is that "trust" isn't a boolean, but an umbrella term for a wide range of policies that we apply to different principals.
Or in other words: transitive trust is a thing, but it's of a different color than "trust." Attempts to gloss over this in web-of-trust designs have historically not gone well.
100% agree about the difference in meaning between the two uses of “trust”. To be frank I responded after only skimming over your comment, and should have read a bit more closely. FWIW, I think there’s a way to unify those two realms: if you model boolean trust in terms of a random variable and sum over the transitive web à la binomial distribution.
I'd argue "friend of a friend" is strong transitivly because it's explicitly chosen by all parties involved.
Trust in a professional relation - a doctor, especially - is actually very strong, because of the professional requirements to be trustworthy, and the protections built into that (being held accountable by an organization and/or lawsuits).
"Family of friend" or "family of professional" isn't necessarily a strong relation for exactly the opposite reason, unless maybe the first-degree contract is vouching for the person.
There’s also a compounding effect. If multiple friends vouch for the same stranger that means something too.
Contact lists do work and are okay for friends, but businesses also need to publish contact information. What do you put on a sign, on a business card, or in an advertisement? You'd need to print the underlying id number, which makes it part of the UI.
Inevitably, people are going to want something like a 1-800 number, perhaps with a mapping to letters that are easy to remember. Either you can pick the number you want, or people are going to end up re-rolling until they get a "nice" number, and then there's competition for nice numbers just like in other namespaces.
I have long been a fan of petnames, and graph naming systems in general.
I like to use the term “nickname” for what they call “edge names” in the article: a nickname is not as personal as a petname, it’s a name you share with others.
An interesting thing that the article sort of hints at is that these kinds of systems have a fairly smooth range of operating points between globally unique and centralized vs decentralized petnames. The article’s example of the bizdir local business directory is somewhere in between these extremes. It sort of turns Zooko’s triangle into more like a fan, where the “human friendly” point is fixed and there’s an arc describing the tradeoffs, from personal through local to global.
How can a petname system function at the global+centralized point, so it could replace the DNS? It needs to pass the “billboard test”: I type in a name I saw on a billboard and I get to the right place. (It might be a multipart name like a postal address or DNS name, with an extra “edge name” or two to provide enough disambiguating context.) I imagine that an operating system supplier might provide a few preconfigured petnames (well, it probably includes its own petname so the software can update itself securely), a lot like its preconfigured PKIX CA certificates. These petnames would refer to orgs like the “bizdir”, or Verisign, or Nominet, that act as nickname registries. Your collection of petnames is in effect your personal root zone, and the preconfigured petnames are in effect the default TLDs. There would inevitably be something like the CA/Browser forum to mediate between OS suppliers and nickname registries: a petname ICANN.
I wrote an older iteration of these ideas over a decade ago (https://dotat.at/@/2012-02-28-path-names-in-a-rootless-dns.h...). Those notes have a bit too much DNS braindamage, but I included some curious anti-DNS discussion: How you might make use of reaching names by multiple paths? What might it look like to have a shared context for names that is not global but is national or regional or local?
While watching some non-technical people use a web browser, I noticed that they tended to type the name of their intended destination - not the domain name - into the navigation bar. In effect, they had delegated the resolution of names to destinations to their default search engine - Google.
How do we solve the "billboard test"? Delegating to mostly central, mostly trusted authorities gets us roughly on par with the current reality. More interesting is if we could then diffuse this authority by having multiple resolvers and combining them. The details - how to combine results, how to resolve divergences, and results changing over time - could be tricky for UX.
Check out Backchannel[0] if you're interested in an implementation of a petname system for globally-unique symmetric cryptographic keys.
> Even though Ben is trusting that caller ID is correct, he can't imagine any reason why someone would be trying to phish him to authorize a topping change
[deleted]
So, a malicious entity can poison the petnames that others see, but only if prefixed by their own first? So people will learn not to trust them, I guess… but as usual with trust, they can be 99% correct and poison a specific one (eg claim a certain number is a well-known rich guy, and impersonate them)
The bigger issue is that people will need to be careful not to give embarrassing or compromising nicknames to people in their addressbooks.
I had considered using these personal contact list display names as default names for when people accept invites, but the problem is that they’ll know the inviting user had them as “that crazy pooky bob”
I think perhaps the PoW/PoS solution to byzantine generals (as used by Ethereum, for example) can and does solve the Zooko's triangle problem via things like ENS.
I don't anticipate that end users will be able to ingest or cope with the mental model involved with the correct usage of the system described in TFA.
ENS is still used for personal identities, and afaik still doesn't care about immutable paths. A wasted opportunity.
I have crazy idea to produce mnemonic rules for every DID, maybe fancy-AI tech would help
I propose an implementation of these petnames by sharing directory access through mutually trusted brokers, whose identity is proven by certificates and whose location is discovered through a standardized directory service protocol. I think we can make huge strides by working with the ITU here — if we can convince them IP is the next big thing, then we might not end up being chained to the OSI netstack for the first release.
Sarcastic replies can be fine. Sarcastic replies when you clearly didn't read the article are just annoying.
It’s proposing a decentralized naming scheme, with nearly zero implementation details, with the idea that it works like split-horizon dns plus some undefined form of list sharing. Adding a bunch of cryptographic stuff to it doesn’t really change the hard bits of discovery.
There are some niceties here, but I think this is a little thin on the security aspects of the scheme: it's not clear how users establish the authenticity of transitively received petnames, for example.
More fundamentally, there's a factor outside of Zooko's triangle: trust isn't really transitive[1]. I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling.
With that being said, I think there's a pretty rich research space here, and I think the edge/local aspects of this design are pretty interesting! I just hope we don't end up with a reinvention of historically insufficient web-of-trust architectures :-)
[1]: https://uhra.herts.ac.uk/bitstream/handle/2299/4349/904849.p...
There's an associated paper that goes through implementing a petname system in a simple chat application. Petnames compose well with object capability security.
https://files.spritely.institute/papers/implementation-of-pe...
That's great, but I don't think it addresses the basic point: sharing edge names requires a way to share those names, and that's a trusted third party (one with a degree of centralization, to boot).
There are ways to (dis)intermediate that trust (like a PKI), but the shape of that PKI or other technique is itself a question of decentralization, security, etc. I think that's a very hard underlying problem that the petname design needs to at least offer some opinions on in order to make claims about security.
Jessica Tallon's implementation of petnames and edge names was extremely simple within the paper davexunit linked, but used in-band mechanisms to communicate edge names that didn't require any sort of large trusted authority. You could retrieve them directly from fellow peers, who could publish their current set of edge names. This even works in a p2p context over ocapn, etc. The implementation was naive but it did work and used a publish-subscribe mechanism directly from other peers.
That said, edge names are only one way to share contacts. In fact "share contact" on peoples' phones is a great way to have contextual sharing: "Oh, let me introduce you to my friend Dave. Here's Dave's contact info!"
At any rate, petnames aren't a particular technology, they're a design space of "Secure UI/UX". However I do agree more research needs to be done in that space; we've only barely begun to scratch the surface.
> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling.
Isn’t that because that’s a different type of trust? For example, you trust your doctor to give you decent medical advice, and they trust their sibling for emotional support. That doesn’t mean their sibling will be supportive of you, or give you good medical advice.
> trust isn’t really transitive
Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.
I would also trust a mutual friend over a complete stranger. But that's not the point of the observation: the observation is that "trust" isn't a boolean, but an umbrella term for a wide range of policies that we apply to different principals.
Or in other words: transitive trust is a thing, but it's of a different color than "trust." Attempts to gloss over this in web-of-trust designs have historically not gone well.
So you can trust friend of a friend only after awaiting him (with apologies to https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...)?
100% agree about the difference in meaning between the two uses of “trust”. To be frank I responded after only skimming over your comment, and should have read a bit more closely. FWIW, I think there’s a way to unify those two realms: if you model boolean trust in terms of a random variable and sum over the transitive web à la binomial distribution.
I'd argue "friend of a friend" is strong transitivly because it's explicitly chosen by all parties involved.
Trust in a professional relation - a doctor, especially - is actually very strong, because of the professional requirements to be trustworthy, and the protections built into that (being held accountable by an organization and/or lawsuits).
"Family of friend" or "family of professional" isn't necessarily a strong relation for exactly the opposite reason, unless maybe the first-degree contract is vouching for the person.
There’s also a compounding effect. If multiple friends vouch for the same stranger that means something too.
Contact lists do work and are okay for friends, but businesses also need to publish contact information. What do you put on a sign, on a business card, or in an advertisement? You'd need to print the underlying id number, which makes it part of the UI.
Inevitably, people are going to want something like a 1-800 number, perhaps with a mapping to letters that are easy to remember. Either you can pick the number you want, or people are going to end up re-rolling until they get a "nice" number, and then there's competition for nice numbers just like in other namespaces.
I have long been a fan of petnames, and graph naming systems in general.
I like to use the term “nickname” for what they call “edge names” in the article: a nickname is not as personal as a petname, it’s a name you share with others.
An interesting thing that the article sort of hints at is that these kinds of systems have a fairly smooth range of operating points between globally unique and centralized vs decentralized petnames. The article’s example of the bizdir local business directory is somewhere in between these extremes. It sort of turns Zooko’s triangle into more like a fan, where the “human friendly” point is fixed and there’s an arc describing the tradeoffs, from personal through local to global.
How can a petname system function at the global+centralized point, so it could replace the DNS? It needs to pass the “billboard test”: I type in a name I saw on a billboard and I get to the right place. (It might be a multipart name like a postal address or DNS name, with an extra “edge name” or two to provide enough disambiguating context.) I imagine that an operating system supplier might provide a few preconfigured petnames (well, it probably includes its own petname so the software can update itself securely), a lot like its preconfigured PKIX CA certificates. These petnames would refer to orgs like the “bizdir”, or Verisign, or Nominet, that act as nickname registries. Your collection of petnames is in effect your personal root zone, and the preconfigured petnames are in effect the default TLDs. There would inevitably be something like the CA/Browser forum to mediate between OS suppliers and nickname registries: a petname ICANN.
I wrote an older iteration of these ideas over a decade ago (https://dotat.at/@/2012-02-28-path-names-in-a-rootless-dns.h...). Those notes have a bit too much DNS braindamage, but I included some curious anti-DNS discussion: How you might make use of reaching names by multiple paths? What might it look like to have a shared context for names that is not global but is national or regional or local?
While watching some non-technical people use a web browser, I noticed that they tended to type the name of their intended destination - not the domain name - into the navigation bar. In effect, they had delegated the resolution of names to destinations to their default search engine - Google.
How do we solve the "billboard test"? Delegating to mostly central, mostly trusted authorities gets us roughly on par with the current reality. More interesting is if we could then diffuse this authority by having multiple resolvers and combining them. The details - how to combine results, how to resolve divergences, and results changing over time - could be tricky for UX.
Check out Backchannel[0] if you're interested in an implementation of a petname system for globally-unique symmetric cryptographic keys.
[0]: https://www.inkandswitch.com/backchannel/
Seems like a typo here that affects the meaning:
> Even though Ben is trusting that caller ID is correct, he can't imagine any reason why someone would be trying to phish him to authorize a topping change
So, a malicious entity can poison the petnames that others see, but only if prefixed by their own first? So people will learn not to trust them, I guess… but as usual with trust, they can be 99% correct and poison a specific one (eg claim a certain number is a well-known rich guy, and impersonate them)
The bigger issue is that people will need to be careful not to give embarrassing or compromising nicknames to people in their addressbooks.
I had considered using these personal contact list display names as default names for when people accept invites, but the problem is that they’ll know the inviting user had them as “that crazy pooky bob”
I think perhaps the PoW/PoS solution to byzantine generals (as used by Ethereum, for example) can and does solve the Zooko's triangle problem via things like ENS.
I don't anticipate that end users will be able to ingest or cope with the mental model involved with the correct usage of the system described in TFA.
Funnily enough Nikolai (original creator of ENS, now passed) worked on this idea https://github.com/nmushegian/namepet
ENS is still used for personal identities, and afaik still doesn't care about immutable paths. A wasted opportunity.
I have crazy idea to produce mnemonic rules for every DID, maybe fancy-AI tech would help
I propose an implementation of these petnames by sharing directory access through mutually trusted brokers, whose identity is proven by certificates and whose location is discovered through a standardized directory service protocol. I think we can make huge strides by working with the ITU here — if we can convince them IP is the next big thing, then we might not end up being chained to the OSI netstack for the first release.
Sarcastic replies can be fine. Sarcastic replies when you clearly didn't read the article are just annoying.
It’s proposing a decentralized naming scheme, with nearly zero implementation details, with the idea that it works like split-horizon dns plus some undefined form of list sharing. Adding a bunch of cryptographic stuff to it doesn’t really change the hard bits of discovery.