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.
> 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.
Yeah, this is one of the big issues with digital peer trust networks. Trust in human interactions is fuzzy and very conditional, which is hard to collect, represent, and update in a user friendly and low effort way. Hence we tend to collapse it to a single, often-binary, trust score.
> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling.
Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice?
What's important here is that the subject of trust is explicit to whoever attests that trust. If your doctor intentionally publishes a list of known contacts, then it can be reasonably presumed that they know those contacts. This, along with the ability to attest falsehood, should be enough to replace traditional authority and moderation.
> Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice?
Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam.
The problem of trust is that trust isn't a boolean; it's a set of policies that vary by principal and action. It's very hard to encode that in a truly general way, which is why modern cryptographic application design orthodoxy dictates that applications should try to solve exactly one kind of trust at a time.
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.
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.
Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers. Also it might turn out your new friend J. is superficially pleasant, but actually a horrible human being once you get to know them - congratulations, J. has access to all your shared contacts. If I was friends with Alice, I'd be very annoyed that J. is now harassing me.
Or suppose you created a list of all doctor's phone numbers in your area. You can then look up if any of your contacts (friends, family, loose aquintance) share any of them (e.g. because they recommended a specialist to a friend).
This needs a tremendous work to setup access rights, and it's easy for an individual to screw this up and put themselves in a bad spot.
Sharing contacts on a need-to-know basis (using e.g. Threema or WhatsApp) is the established standard in my peer group; be it the number of a Pizza place or my SO's new number, so a common friend can invite her to a party. And while it's less cool and adds some effort, it requires an explicit action to share a contact. This is more safe.
In my humble opinion, and I might have a bad hunch there: The overall mistake with that example is lies in how it associates identities with phone numbers. In reality, it's the other way around. We want to share identities (be it the Pizza Place, Mum, or a doctor), and should have control who can access the information (not just phone numbers) associated with them.
But that's essentially re-inventing social networks with a narrow focus.
From a academical perspective the technical issue can be interesting of course, and valuable insights might be gained from this research.
There might be use cases beyond the basic contacts example; in fact, I think in a company phone directory this can be incredibly useful as part of the CRM.
To reinforce the real-world value of contact secrecy, let me share an example of how WhatsApp's contact broadcasting is creating massive opportunities for scammers where I live (Mexico).
In WhatsApp, when you join a "community" (sort of like a giant, moderated group), all members of the community are visible to all other members. You can see their phone numbers and their self-chosen nickname. Note that very frequently people will have their names or a shortened version of their name as their nickname.
In emerging markets, people use WhatsApp for everything and many people will naturally join a few communities. Things like:
- A community for your kid's school
- A community for your neighborhood's safety alerts.
- A community for a club or hobby.
So a scammer's workflow is as follows:
1. Infiltrate a community or a group.
2. Check all of the members and find those whose names are publicly shared or you can deduce.
3. Use their name, phone and--crucially--information about the community itself to craft a targeted phishing phone call.
Example:
Sandra is a part of a community for neighborhood safety news. The community is called "Hillsborough safety." Her whatsapp nickname is "Sandy Williams."
A scammer will join the community and see her contact. They will then call her with a message like "Hi, is this Sandra Williams? Yes, I'm calling from the Hillsborough police department. Unfortunately there's been an accident with your husband...".
You can imagine how the simple fact of knowing someoen's name and some sort of "proprietary knowledge" (they know I live at Hillside!) can be enought to for a victim to lower their defenses.
An additional layer to this is that often the scammer will social-engineer their way into gaining access to the victim's Whatsapp account itself. They can then access all of the groups that victim was a member of, including "tight" friend groups, etc.
IMHO contact broadcasting is an inexcusable design decision by WhatsApp.
A contacts list is a superset of the publicly available connections that would make up a web of trust. Out of all my contacts, there are a few people that I would be willing to vouch for. As in: declare publicly that I know who they are, and reveal the name that I refer to them as.
That pet name may be different from person to person, but that's fine. Alice might call a public key "Bobby's Public Key", and Charlie might call it "Robert's Public Key". I can make sense of those attestations when I'm trying to verify that I have Bob's key, and assign it my own pet name. If Alice or Charlie weren't willing to publicly attest to the Bob-ness of the same public key then I wouldn't be looking at their attestations.
> Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers.
That's a critical implementation detail, but I think it can be done. All we need to do is make contact-sharing an explicit feature.
> But that's essentially re-inventing social networks with a narrow focus.
Yes it is. That's the utility of decentralized networks: by removing the hierarchy from the network, we have removed the explicitly drawn context. Instead, the context is implicit and flexible. There are pros and cons to this feature. Instead of segmenting "twitterverse", "facebookverse", etc.; we simply have "the universe". The same boundaries can be replicated, but the lines are drawn by the users instead of by the platform, all while preserving compatibility across those lines.
As far as privacy in curated networks goes, I think we could find some interesting strategies to accomplish it. One could be anonymous pseudonyms: publish the attestations you don't want traced back to you as an explicitly not-you user. Another could be attestation laundering: provide a publicly available user (that anyone can use) that publishes a collection of attestations as if it was the original publisher, and let collaborators vote on that user's overall validity via attestation.
Essentially, we must contend with the inverted hierarchy that decentralized networks are made of. It's definitely a change, but I think can provide a lot more utility than centralized networks provide today.
Yes, I think this was a really bad example, and something without humans would have been better, so for example naming of cloud server resources.
With real world names there's also the messy issue of name changes and dead-naming. If Alice changes her (his) name to Bob, but Eve keeps Alice in as Alice, you'd have mutual contacts seeing still referring to Bob as Alice.
There are also of course the privacy concerns you mentioned, despite any optionality of sharing contacts.
Here's a problem that this does potentially solve:
"Two different cloud orchestrators need to be able to create servers which may get referenced by servers they each create. Coordinating unique names would be difficult".
Although that's an odd problem, and it's already solved in a similar way by other hierarchical naming structures with authorities such as domains, which is essentially what this pattern is describing in a roundabout way.
"com" names everything under it. "example.com" names everything under that, etc. Multiple different paths can point to the same resource.
This complaint and thinking of other simple but sliiiightly more advanced permission/privacy systems reminds me of G+ circles - kinda wish it'd have taken off. I thought it was a pretty neat system.
A contact list actually seems to me like an abnormally bad example for other reasons, or I'm way more atypical than I think I am and everyone else curates their contacts far more carefully. For me, the proliferation of spam means I'm never going to answer an unrecognized phone number, and thus enter everyone I ever expect to receive a phone call from into the list. The vast majority of the time, these are things like contractors coming to my house, a hand surgeon I visit for one injury and hopefully only one injury, a shop I take my car to hopefully once and only once. Numbers I received a call from a few times, possibly more than a decade ago. The fact they're still in my contacts list says nothing whatsoever about my level of trust in them and doesn't mean other contacts, especially my actual friends, should assume anything about their presence except that I received at least one phone call from them at some point and I was expecting that call.
That's aside from the fact that contact lists are not reciprocal. Adding a number to your list and giving it a name doesn't mean the owner of that number has added you to their list. There is no guarantee whoever is on the other end of that number has any idea who you even are.
This is also aside from the fact that phone numbers can be reassigned. That's an argument that I and anyone else as cavalier about their lists as me should be removing numbers more often, but outside of a fairly short time horizon, there is no guarantee that the person who owns a number you have listed as "Bob" is still Bob.
These issues aren't unique to digital contact lists, either. My wife pulled a book off the shelf a few months ago I hadn't opened in a very long time and found an old sheet of paper I'd written some phone number on, possibly 25 years ago? One was a very good friend from high school, a name I still knew and a number I still recognized as her parent's home number from the late 90s. The other, I have absolutely no idea. Probably some designated driver for a group of friends I was going to a party with who were going separate from me in case I needed someone to call if something came up. I may have never even called that number or received a call from it.
Hell, how many contacts of people in their early 20s are someone you met in a club who gave you a fake phone number that happens to be some other person's real phone number?
This bugs me to no end with all the apps out there for smart phones that want access to your contacts. Why? What significance do you think this list has? It's just a semi-random assortment of some sub-sample of all the people and organizations I have had some kind of fleeting and possibly one-time interaction with in the past quarter century. It doesn't imply I remember who they are, know them, or that I vouch for them in any way.
It frustrates me that domain names were designed to be a rival good, and that this has attracted so much attention from speculators, and the negative externalities that come out of that. I'm not sure what would be a good solution here.
The existing design of domain names does have one important property, though. When someone successfully registers a name, they're guaranteed that they can pay a renewal fee - small, all things considered - and keep the name as long as they want - perhaps modulo legal and ToS concerns. This gives them assurances that they can invest into the branding of the name and keep the benefits.
Compare that with search engine results. I mentioned elsewhere in this thread that I watched numerous non-technical users treat their browser nav bar as a name resolution mechanism - effectively delegating name resolution to their default search engine. Search engine results should change over time. If someone starts a FooBar Inc. in one industry, and someone else starts a bigger FooBar Corp. in another, who gets the "foobar" name?
A sort of "pin on first use" would save existing users of FooBar Inc. New users trying to find FooBar Inc. might get confused though. FooBar Inc. would understandably be hesitant to print the "foobar" petname on their business cards and billboards.
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.
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.
QR codes for canonical addressing could solve the publishing problem, with customization of how the QR code appears being a feature for advertising and marketing. Once the canonical address has been accessed once, it could be pet named by the accessing user.
Good answer. But I’m wondering how well this works when a QR code resolves to a meaningless string of digits?
I suppose most people don’t check URL’s anyway, and for some URL’s the domain name is fairly meaningless. Still, it seems like something is lost, at least for techies, when you can’t see and recognize usernames and domain names?
Consider how programming languages work. Who wants meaningless numbers in their import statements or package.json file? Package names seem decentralized enough? Not sure it’s worth throwing out to achieve True Decentralization.
This sort of reminds me of certificate authorities. A certificate authority is just a list of edges in this sense, and you inherently trust what the CA says are valid edges. (with some cryptography magic to verify it's really on the CA's list)
You could make everyone their own "naming authority", so you could trust anyone's list if you choose to, but I would also bet we'd end up with a similar situation, where someone compiles the most names, and becomes a great default to use, so people don't spend much time cleaning up their own data, and things sort of naturally centralize.
Readit News
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.
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.
Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice?
What's important here is that the subject of trust is explicit to whoever attests that trust. If your doctor intentionally publishes a list of known contacts, then it can be reasonably presumed that they know those contacts. This, along with the ability to attest falsehood, should be enough to replace traditional authority and moderation.
I get into this more in my comment here: https://news.ycombinator.com/item?id=42238201
Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam.
The problem of trust is that trust isn't a boolean; it's a set of policies that vary by principal and action. It's very hard to encode that in a truly general way, which is why modern cryptographic application design orthodoxy dictates that applications should try to solve exactly one kind of trust at a time.
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.
Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers. Also it might turn out your new friend J. is superficially pleasant, but actually a horrible human being once you get to know them - congratulations, J. has access to all your shared contacts. If I was friends with Alice, I'd be very annoyed that J. is now harassing me.
Or suppose you created a list of all doctor's phone numbers in your area. You can then look up if any of your contacts (friends, family, loose aquintance) share any of them (e.g. because they recommended a specialist to a friend).
This needs a tremendous work to setup access rights, and it's easy for an individual to screw this up and put themselves in a bad spot.
Sharing contacts on a need-to-know basis (using e.g. Threema or WhatsApp) is the established standard in my peer group; be it the number of a Pizza place or my SO's new number, so a common friend can invite her to a party. And while it's less cool and adds some effort, it requires an explicit action to share a contact. This is more safe.
In my humble opinion, and I might have a bad hunch there: The overall mistake with that example is lies in how it associates identities with phone numbers. In reality, it's the other way around. We want to share identities (be it the Pizza Place, Mum, or a doctor), and should have control who can access the information (not just phone numbers) associated with them. But that's essentially re-inventing social networks with a narrow focus.
From a academical perspective the technical issue can be interesting of course, and valuable insights might be gained from this research. There might be use cases beyond the basic contacts example; in fact, I think in a company phone directory this can be incredibly useful as part of the CRM.
In WhatsApp, when you join a "community" (sort of like a giant, moderated group), all members of the community are visible to all other members. You can see their phone numbers and their self-chosen nickname. Note that very frequently people will have their names or a shortened version of their name as their nickname.
In emerging markets, people use WhatsApp for everything and many people will naturally join a few communities. Things like:
- A community for your kid's school
- A community for your neighborhood's safety alerts.
- A community for a club or hobby.
So a scammer's workflow is as follows:
1. Infiltrate a community or a group.
2. Check all of the members and find those whose names are publicly shared or you can deduce.
3. Use their name, phone and--crucially--information about the community itself to craft a targeted phishing phone call.
Example:
Sandra is a part of a community for neighborhood safety news. The community is called "Hillsborough safety." Her whatsapp nickname is "Sandy Williams."
A scammer will join the community and see her contact. They will then call her with a message like "Hi, is this Sandra Williams? Yes, I'm calling from the Hillsborough police department. Unfortunately there's been an accident with your husband...".
You can imagine how the simple fact of knowing someoen's name and some sort of "proprietary knowledge" (they know I live at Hillside!) can be enought to for a victim to lower their defenses.
An additional layer to this is that often the scammer will social-engineer their way into gaining access to the victim's Whatsapp account itself. They can then access all of the groups that victim was a member of, including "tight" friend groups, etc.
IMHO contact broadcasting is an inexcusable design decision by WhatsApp.
That pet name may be different from person to person, but that's fine. Alice might call a public key "Bobby's Public Key", and Charlie might call it "Robert's Public Key". I can make sense of those attestations when I'm trying to verify that I have Bob's key, and assign it my own pet name. If Alice or Charlie weren't willing to publicly attest to the Bob-ness of the same public key then I wouldn't be looking at their attestations.
That's a critical implementation detail, but I think it can be done. All we need to do is make contact-sharing an explicit feature.
> But that's essentially re-inventing social networks with a narrow focus.
Yes it is. That's the utility of decentralized networks: by removing the hierarchy from the network, we have removed the explicitly drawn context. Instead, the context is implicit and flexible. There are pros and cons to this feature. Instead of segmenting "twitterverse", "facebookverse", etc.; we simply have "the universe". The same boundaries can be replicated, but the lines are drawn by the users instead of by the platform, all while preserving compatibility across those lines.
My answer to this change is to replace moderation with curation. I get into this distinction more in my comment here: https://news.ycombinator.com/item?id=42238201
As far as privacy in curated networks goes, I think we could find some interesting strategies to accomplish it. One could be anonymous pseudonyms: publish the attestations you don't want traced back to you as an explicitly not-you user. Another could be attestation laundering: provide a publicly available user (that anyone can use) that publishes a collection of attestations as if it was the original publisher, and let collaborators vote on that user's overall validity via attestation.
Essentially, we must contend with the inverted hierarchy that decentralized networks are made of. It's definitely a change, but I think can provide a lot more utility than centralized networks provide today.
With real world names there's also the messy issue of name changes and dead-naming. If Alice changes her (his) name to Bob, but Eve keeps Alice in as Alice, you'd have mutual contacts seeing still referring to Bob as Alice.
There are also of course the privacy concerns you mentioned, despite any optionality of sharing contacts.
Here's a problem that this does potentially solve:
"Two different cloud orchestrators need to be able to create servers which may get referenced by servers they each create. Coordinating unique names would be difficult".
Although that's an odd problem, and it's already solved in a similar way by other hierarchical naming structures with authorities such as domains, which is essentially what this pattern is describing in a roundabout way.
"com" names everything under it. "example.com" names everything under that, etc. Multiple different paths can point to the same resource.
That's aside from the fact that contact lists are not reciprocal. Adding a number to your list and giving it a name doesn't mean the owner of that number has added you to their list. There is no guarantee whoever is on the other end of that number has any idea who you even are.
This is also aside from the fact that phone numbers can be reassigned. That's an argument that I and anyone else as cavalier about their lists as me should be removing numbers more often, but outside of a fairly short time horizon, there is no guarantee that the person who owns a number you have listed as "Bob" is still Bob.
These issues aren't unique to digital contact lists, either. My wife pulled a book off the shelf a few months ago I hadn't opened in a very long time and found an old sheet of paper I'd written some phone number on, possibly 25 years ago? One was a very good friend from high school, a name I still knew and a number I still recognized as her parent's home number from the late 90s. The other, I have absolutely no idea. Probably some designated driver for a group of friends I was going to a party with who were going separate from me in case I needed someone to call if something came up. I may have never even called that number or received a call from it.
Hell, how many contacts of people in their early 20s are someone you met in a club who gave you a fake phone number that happens to be some other person's real phone number?
This bugs me to no end with all the apps out there for smart phones that want access to your contacts. Why? What significance do you think this list has? It's just a semi-random assortment of some sub-sample of all the people and organizations I have had some kind of fleeting and possibly one-time interaction with in the past quarter century. It doesn't imply I remember who they are, know them, or that I vouch for them in any way.
The existing design of domain names does have one important property, though. When someone successfully registers a name, they're guaranteed that they can pay a renewal fee - small, all things considered - and keep the name as long as they want - perhaps modulo legal and ToS concerns. This gives them assurances that they can invest into the branding of the name and keep the benefits.
Compare that with search engine results. I mentioned elsewhere in this thread that I watched numerous non-technical users treat their browser nav bar as a name resolution mechanism - effectively delegating name resolution to their default search engine. Search engine results should change over time. If someone starts a FooBar Inc. in one industry, and someone else starts a bigger FooBar Corp. in another, who gets the "foobar" name?
A sort of "pin on first use" would save existing users of FooBar Inc. New users trying to find FooBar Inc. might get confused though. FooBar Inc. would understandably be hesitant to print the "foobar" petname on their business cards and billboards.
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.
What always stands out to me with any project attempting decentralized social media, though, is how complex it becomes compared to RSS feeds.
The one requirement of content being push based rather than pull based has so many downstream effects, and its often goes overlooked or unspoken.
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 suppose most people don’t check URL’s anyway, and for some URL’s the domain name is fairly meaningless. Still, it seems like something is lost, at least for techies, when you can’t see and recognize usernames and domain names?
Consider how programming languages work. Who wants meaningless numbers in their import statements or package.json file? Package names seem decentralized enough? Not sure it’s worth throwing out to achieve True Decentralization.
[0]: https://www.inkandswitch.com/backchannel/
You could make everyone their own "naming authority", so you could trust anyone's list if you choose to, but I would also bet we'd end up with a similar situation, where someone compiles the most names, and becomes a great default to use, so people don't spend much time cleaning up their own data, and things sort of naturally centralize.