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.
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 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?
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.
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.
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.
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.
> 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.
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/
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?
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.
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.
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.