Harder to set up. With centralized systems, all you need is the URL and you can get the magic social-stuffy box on any device you have.
(TBH a centralized service actually feels better, too, because you know it's the service and not some random collection of pieces held together by agreement and duct tape. Partitioning problems are pain enough with centralized services at scale, but they're worse with decentralized ones.)
I've never understood why P2P always goes for the end users.. in most cases it doesn't work for exactly the reasons you mention -- harder to set up, etc. (For some reason bittorrent became the exception that proves the rule.)
However, I think there must be something between true user-to-user P2P and completely centralised systems. Why not something like Twitter or Facebook but where lots of different people can set up servers, and accept users? The servers could exchange information and act like a "single" service with a standard protocol, and users would not need to set up a thing, only choose which server to use, but otherwise the experience would be more or less identical, with access to the same information and profiles, all cached and mirrored. (I call this myself a "federated P2P system", not sure if that's a good term.) Of course such a system would need some crypto support to ensure that data is not easily spoofed and man-in-the-middle modified, but different servers could offer different ways of curating news feeds, etc., and some competition on the front-end where all competitors have access to the same decentralised back-end data would be just fantastic.
I think one example of this was OpenID, which seems to have failed unfortunately. I always thought it was a cool idea. But it seems that people need more than just a common protocol, they really need a common entity to adhere to, they need to be able to say "I'm on X" and for everyone to know what that means and how to find them. And a single company with a single domain seems to provide that.
Unfortunately being open protocol and open source and all that, while well-intentioned, is simply no replacement for a really good marketing department.
About the only two successful federated communication systems I know of are phone network and e-mail. It doesn't matter who you pay your phone bill to, nor where your e-mail address is hosted, you are globally reachable. There might be something insightful in how those two systems started and what keeps them being relevant.
> Unfortunately being open protocol and open source and all that, while well-intentioned, is simply no replacement for a really good marketing department.
Indeed. And you can't fund a good marketing department if you don't resort to m̶o̶n̶e̶y̶ ̶e̶x̶t̶o̶r̶t̶i̶o̶n̶ ̶t̶a̶c̶t̶i̶c̶s̶ vendor lock-in and similar strategies. It's something that, by the way, I see as a direct cause of why so much products are utter shit nowadays - because marketing has much, much better ROI than actually making something useful.
>>About the only two successful federated communication systems I know of are phone network and e-mail.
And they were both developed by governments/universities with no profit motive. That should tell us everything we need to know regarding how to go about creating the next ubiquitous federated/distributed system.
IRC, usenet? Even email is usually implemented that way: few end users run their own SMTP servers in the basement.
They have one thing in common: nobody is polishing the brand, nobody is A/B-optimizing addictive properties, there is no startup success story in which users can feel included, rooting for their network of choice.
Oh, and changing a federated system not only requires unanimous decision, it requires unanimous investment. Did the protocols i mentioned feel a bit dated? Might be because of that.
I purposefully didn't mention IRC in a parallel comment because I don't see how it is federated. You always connect to a particular server and stay within its bounds; you don't get the shared space handled by multiple servers that are abstracted away. Or simpler, you say "I'm hanging out on channel #x on freenode", or "on QuakeNet", not "on IRC".
The isolation level you speak of is between networks, not between servers. This distinction might seem a little arbitrary since no centralized system of relevance is running on a single server either, but the key difference is still there: in the larger irc networks, the different nodes that form it are run by different organizations.
Splits are a possibility in any federated system and in systems with nonhierarchical, unique naming, any merge requires some amount of namespace violence proportional to the duration of the split.
Also, the promise that it's safe because you can check the source is really lost when, you know, you can't actually check the source for lack of time, skill or trust in the chain of trust.
(TBH a centralized service actually feels better, too, because you know it's the service and not some random collection of pieces held together by agreement and duct tape. Partitioning problems are pain enough with centralized services at scale, but they're worse with decentralized ones.)