It has some interesting insights into when federation works and when it doesn’t.
“Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.”
Yeah, but moxie is mostly wrong. He's only seen worst-case scenarios and assumes everything is lile that, so he builds his centralized stuff instead.
You can easily move forward with a federated protocol as well if you've got cooperating people, guarantee only 6 months of support for a protocol version, and have a versioning and feature flag system.
Hell in one project I contribute to we've kept protocol compatibility since 2009, we've got mamy third party clients, everyone hosts their own server — and still we can introduce new features without breakage in a matter of days (at least into beta, QA and translation take a while).
If he's wrong and it's easy, why can no one do it? Why did Slack overrun IRC? XMPP left by the wayside by Google and Facebook? Because it isn't easy, and users will always value the experience over compatibility and principal.
The counterexample here would be Mastodon, which I believe now has more users than IRC and seems to be growing quite healthily. (And, AFAIK, isn't funded by any megacorps; it's actual grassroots FOSS.)
When it comes to social media software, people care about two tightly-coupled things: if the people they need to talk to can be reached with it, and if the UX is good. (People abandoned IRC because its UX, which was never good, degraded to unusability in a multi-device not-always-online embedded-media world.)
But there's nothing about federation that inherently requires bad UX. But federation generally means open-source (because there's no market pressure for interoperability), and open-source means bad UX. Mastodon owes 80% of its success to having been principally developed by somebody who knows how to make a goddamned webpage. The other 20% is that it's pretty easy to host.
I think the really interesting takeaway is that the giants only don't support interoperability because they have a monopoly on good UX. If something highly usable and open-source appeared in the chat space and started gaining serious traction, the enterprise players would have to entertain the notion of playing ball and supporting the protocol – and if one of them did it, the rest would follow.
One thing I think some people got it wrong: Decentralization is not a feature, it's a method.
(Most) Users won't care whether or not they are using something decentralized, they only care what they can achievement with that software/service. Is it doing better than others on the market?
Back to the topic, about why Slack defeated IRC & XMPP: A product -- whether or not it's a online service or a hardware -- needs to keep up with the world. For example: If one day, people started to sharing photos and videos and voices during their online chat session, and your software can't keep up with that, then you will likely loose those people soon enough.
Currently, centralized software made upgrading very easy. You have all the control you need to force users to upgrade to your newer and richer client. While in the decentralized world, you may need to beg somebody to upgrade their server to support the newer version of your client (Due to that, you may not dare to upgrade your product that often).
Also, decentralized software usually hard to develop, while harder to generate enough revenue to be commercialized or be profitable. When clever people needs to survive, they will save the trouble and feed themselves (make money) first.
I'm not saying work on something decentralized is a bad idea though, we need decentralized service in today's very centralized world for sure. But make sure you can deliver the same level of experience (or be better) of your centralized competitors, then maybe people will start to use it.
> Users won't care whether or not they are using something decentralized
This is a good point, and it is demonstrably the case even among cryptocurrency users who have a coinbase wallet. Coinbase is not decentralized, and for a lot of users this is actually a nice feature because you can transfer BTC balance from one coinbase user to another without incurring any miner fee or waiting a long time for confirmations.
If most people who wanted to use bitcoin actually cared about decentralization, coinbase (and other similar services) would have virtually no users.
Marketing, marketing, and amount of money that goes into that development.
Give me a few thousand developers, a multi billion dollar ad budget, and the ability to signup every facebook user on the planet to my messaging service, and I'll also win against XMPP. In fact, with those resources carrier pidgeons would've won against XMPP.
This doesn't explain why IRC can't compete with Slack or the other corporate messaging services.
Slack was a side project by a failing game company. Its growth was largely organic.
I think the original premise is right that user experience is more important than ethics or philosophy or whatever the heck it is we're talking about when federations come up
IRC didn't by even have anyone trying to improve stuff until the IRCv3 WG came along, and now we're seeing massive innovation and adoption in short timeframes.
But the fact that nobody was working on it is also part of the same discussion: non-centralized services haven't had clear ways to incentive the time investment to develop them. The community and respect of working on open source has worked well enough for some developers to create and keep these projects sputtering along, but it never worked for the designers and product vision folks. One of the promises of blockchain-based decentralized projects is that they may be able to incentive their contributors by cutting them in on the potential success of the project. It remains to be seen whether that's workable, but it's an interesting idea.
But the point is: that hasn't worked. We've had plenty of time now to see that that model does not work very well. I'm at least somewhat of a blockchain skeptic, but what I do like about it is that it isn't just trying to solve this problem in a way that we know doesn't work very well; it's trying to find a new answer that might work better.
The worst cases are the only ones that actually matter.
If you can demonstrate your stuff still works in the worst case, then when the worst case does actually happen, your staff is the only thing that will still be working when everything else goes down the tubes.
All of computer science is predicated on worst case analysis for a very, very good reason.
So you're saying that the only reason Facebook messenger with thousands of deva and a multi billion ad budget won against XMPP was that XMPP was federated?
No. The reason federated clients lost was that mega corporations can't make profit with em, and so they spent billions on their own tech.
This isn't david vs goliath, this is david vs a nuclear aircraft carrier
It has some interesting insights into when federation works and when it doesn’t.
“Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.”