Naming is a fundamentally opinionated operation. The exact mechanism and intensity of opinion may vary by application, but opinionated it certainly is. Opinions require curation. Curation implies either distributed reputation networks (which frankly, I don't think are Possible) or some degree of centralization. QED, it follows that decentralization (as opposed to distributed) is in fact the best we can do.
We can push that a little farther with a tiny bit of separation: it's the assignment of names that's opinionated, and thus requires curation, and thus confined to being decentralized at best. We can still of course make lookup of names completely distributed. And that's pretty good!
Let's talk about some user-stories that come to my mind right now (spoiler, for almost all of them, decentralized&&!distributed is either acceptable or outright desired):
-
package managers: if you talk to these people for any amount of time, naming curation is actually the number one problem. Your reputation and utility to people as a package management tool system is entirely based on them looking up "bash" or "libfoo" and getting something not actively virusy.
-
chat networks: federated chat networks have huge, huge problems with spam. It's the number one challenge once they get the basic tech done and more than a handful of users. Matrix is having a fun time with it right now. IRC has had this for decades -- you can't just walk up to freenode or any of the other major networks and start hosting a node that federates with them.
-
the backup system I wish I had based on IPFS: literally does not need to publish the snapshot index publicly, and actively should not. I want decentralized, in that I'm going to hold it on my machines, and edit power is based on my local user having the physical ability to edit it; I actively do not want distributed.
-
collaborative document editing: this is one of the few places where we truly want distributed operation. But it's worth noting a whole bunch of other interesting properties about this: in practical user story, something like peerpad is used relatively temporarily! Documents originally drafted and edited in this form usually don't live there forever; they get edited for a while, then snapshotted, and named and distributed through some other mechanisms with more permanent names and more curation.
Naming is really hard to unpack. The only two things I know are:
- It's a space that's broad enough and application-logic-entangled enough that there will be more than one correct answer, and it will be contextual -- so accept that!
- This "curation" concept appears to be fundamental -- so design with it in mind!
Something that's just kind of presumed context at the start of this document is the distinction between the terms "decentralized" vs "distributed".
This is an important distinction, and there's a fair number of good writeups about it and graphics to disambiguate it, and I'm going to continue to assume those exist and can be found out yonder on the internet.
I'm afraid I might have attached too much precise meaning to "distributed", though. In this writeup, I took "distributed" to mean anything that's purely open -- such as, for example, a public DHT. And correspondingly, the main reason I say I tend not to think these things are Possible comes down to Sybil attacks (for which the best possible counters appear to be on the order of "moderately increase the costs to execute" -- and not in a particularly useful asymmetrical way -- rather than actual reliable solutions).
However, "distributed" vs "decentralized" may also be better perceived as a spectrum. There's certainly the possibility of algorithms which trend towards the more distributed end of the spectrum (e.g. k/n mechanics, etc, rather than federation or leader election) while still having closed membership. And having closed membership means the rules of engagement for Sybil attacks are quite different, and become tractable (depending on your definition of "closed" -- again, leaning on the "spectrum" thing here).
(None of this is to say my figuring of the above concrete user-stores has changed, though. Nor am I familiar with any fully worked stories of useful distributed-but-closed-membership systems, except for those where "closed" is taken as literally "this was solved completely out of band and no one may ever join the protocol", which is a heck of an easy-mode special case.)