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...
https://files.spritely.institute/papers/implementation-of-pe...
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.
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.
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.
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.
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.
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 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?
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.
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.
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”
> 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