One of the explicit protocol level trade offs is federation:
> One of the controversial things we did with Signal early on was to build it as an unfederated service. 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.
Thanks, I wasn't aware of this. Though to be honest, I am not exactly convinced. Calling HTML federated seems a real stretch. My browser doesn't have to talk to other browsers, just servers, and those can speak many languages. The network effects are really _very_ fundamentally different.
The reality is that, no matter how much I wanted xmpp (and google wave for that matter) to succeed, Signal (and if you are willing to trust the closed source client WhatsApp) are the only ones that did.
And that's even though XMPP preceded Signal by a decade. The argument that a good federated user experience is possible in principle starts to sound a lot like talk about "sufficiently smart compilers".
Let's grant it is true that we don't have sufficient resources to update a host of different clients to use all the extensions. So then it still seems that in a resource constrained environment federation is not feasible. Open Whisper Systems managed to get encryption on a billion devices with a team of three people. The idea that it only succeeded due to a resources advantage (rather than fundamentally different trade-offs) does not seem very plausible.
> And that's even though XMPP preceded Signal by a decade. The argument that a good federated user experience is possible in principle starts to sound a lot like talk about "sufficiently smart compilers".
For how much of that decade did we even see "a couple of full-time developers" applied to XMPP though? Yet alone an actual UX designer.
Have you tried Conversations? You might want to give it a try. On the whole, the user experience is not significantly worse than Signal. With both sides using OMEMO encryption, privacy should be about the same.
Trade offs:
Onboarding is trivially more complex. You have to enter your JID and a password -- registration of a new JID adds one checkbox to that.
Contact discovery does not piggyback on phone numbers, so you will have to add JIDs to your address book if you want Conversations to pick them up.
Another new XMPP-based app, Zom (https://zom.im/) makes some of this easier by letting you automatically register on their hosted XMPP server, locking you into sane default settings, etc. Android app seems still a little buggy, though.
All due respect it not exactly mind-blowing that to compete with some of the most successful businesses in the world you have to do things they can't. The author often likes to use catchy quotes so let's go with the classic "It is difficult to get a man to understand something, when his salary depends on his not understanding it". They make their money selling licenses and consulting for centralized messaging services. It's not in the interest of either party to have disagreements on this issue.
Signal making choices for ease of evangelizing it doesn't condemn the entire idea any more than poor implementations of secure email means we should totally give up on it
One of the explicit protocol level trade offs is federation:
> One of the controversial things we did with Signal early on was to build it as an unfederated service. 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.