I wish that the author had spent more time really thinking about _why_ communication has moved away from email, or why XMPP/IRC never really caught on despite being vastly older than these app competitors (hint: it is because they are federated, and so making sweeping changes to the protocol/client in the name of UX becomes intractable.)
It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time, but why can Matrix solve this problem if XMPP cannot? Signal just works.
Has it, though? I don't think we are any step closer now to dropping email than we were 25 years ago.
> or why XMPP/IRC never really caught on despite being vastly older than these app competitors
Could be the lack of marketing (because there isn't a corporation or venture capital money behind benefiting from exponential user base growth) and critical mass/peer-pressure as a result
> making sweeping changes to the protocol/client in the name of UX becomes intractable.
This starts to be dated, but is a counter-example: https://gultsch.de/objection.html
XMPP keeps evolving, and probably faster, and with better adoption than something centralized like Skype for instance.
Moreover, we've arguably less feature-packed messengers now than we had two decades ago.
> It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time, but why can Matrix solve this problem if XMPP cannot? Signal just works.
The irony. Signal contributes to fragmentation. We seem to pretend that it's a protocol/technical issue, but did you know that WhatsApp runs on XMPP, so did Google Talk, and Facebook Messenger early on? All those silos could open federation and let messages be exchanged across services, but chose not to do so (including Signal), because they have more to gain in keeping you hostage.
> Has it, though? I don't think we are any step closer now to dropping email than we were 25 years ago.
Email feels more like a tool for reaching out than for communicating to me. I.e. it serves like an RSS feed and serves like a way for unknowns (or long lost friends/acquaintances) to reach out to you.
Sure some people still use newsgroups and communicate daily over email, but for most people it's just a method to sign up for accounts in walled gardens.
Well, I don't know in which world you live, but in mine Outlook is alive and kicking, that's where purchase orders are confirmed, meetings with suppliers are organized, business decisions are made … and in the few instances where it's not going over Outlook, it's because it's on a GApps tenant, in which case it's GMail instead.
The biggest threat to outlook and email today is probably MSTeams, and ironically enough, it federates just fine so that two employees from two distinct companies can chat as if they were on the same tenant.
> Well, I don't know in which world you live, but in mine Outlook is alive and kicking, that's where purchase orders are confirmed, meetings with suppliers are organized, business decisions are made
Stuff like that was what I meant. I wouldn't call receipts, calendar invitations and verification emails "communication" (as in person to person). I agree though that email is a prime medium for B2B communication, but within a company you'd usually use another medium (like Slack).
The email protocol is being used for instant messaging — check out DeltaChat. It works much better than I expected, and it is possibly the most desentralized solution there is.
> Has it, though? I don't think we are any step closer now to dropping email than we were 25 years ago.
I think OP meant that there's been a significant decrease in usage. In my case I can definitely relate to this for personal communications, I no longer send emails to personal acquaintances, I mostly use email for professional purposes, so I think OP's point stands.
> Could be the lack of marketing (because there isn't a corporation or venture capital money behind benefiting from exponential user base growth) and critical mass/peer-pressure as a result
Maybe marketing would work, but a killer feature is way more efficient, especially in the long run. WA offered users a way to text using the same phone numbers for free in countries where you had to pay. Decentralization, like being-open source, does not provide short-term benefits to a user, so you still need distinguishing features.
> did you know that WhatsApp runs on XMPP [...] All those silos could open federation and let messages be exchanged across services but chose not to do so (including Signal), because they have more to gain in keeping you hostage.
WA also uses the Signal Protocol, which I assume is not directly compatible with OMEMO (or this name wouldn't exist). From the little information I found, it uses a customized version of XMPP, which is also probably not directly compatible with XMPP.
My point is that it's not as simple as setting COMPATIBLE=TRUE to make every network compatible with each other. I doubt Facebook deviated from the base protocol just for the sake of it (and there are simpler ways to prevent 3rd party clients), they wanted to implement something which was missing. They wanted to customize XMPP to add features (pretty much Moxie's argument against federation).
> Decentralization, like being-open source, does not provide short-term benefits to a user, so you still need distinguishing features.
XMPP's killer feature is, for me, its pubsub capability (https://xmpp.org/extensions/xep-0060.html). From a technical point of view it's just an ordered key-value store with notification, but from a user point of view it allows way more uses than "simply" messaging: microblogging (https://xmpp.org/extensions/xep-0277.html, can replace twitter), generic status updating (https://xmpp.org/extensions/xep-0163.html), good-old key-value store (keys for OMEMO), standard blogging (to replace Facebook)
XMPP also has message types and threadings, so you can build stuff like forums (to replace Reddit), diffusion lists (like Telegram channels)...
It has everything, and it is there to be used. Some clients have done it for some time now, it's not a technical problem anymore; it's a marketing problem. None of what Whatsapp or Facebook Messenger or Telegram or Signal do cannot be done by XMPP.
> In my case I can definitely relate to this for personal communications, I no longer send emails to personal acquaintances
I think we can agree that they have different strengths, I haven't seen much change in my usage of email for chatting with personal acquaintances because email has never been going strong there, unlike Instant Messaging…
> but a killer feature is way more efficient, especially in the long run
…if one thing, popular IM of today pack less features, not more, than those they replaced. Remember the golden age of MSN messenger? You had whiteboards, tictactoe/chess/… games with friends, screen sharing, fancy fonts & colors, "now listening to:" , wizz, … Ironically, XMPP inherited all those features out of necessity to be compatible with all those protocols (and I don't think it matters the slightest).
XMPP does have quite nice and unique features of its own, if check-out the other response :)
> WA offered users a way to text using the same phone numbers for free in countries where you had to pay
just like every other messenger then and now… (I'm not downplaying their coming ahead of this fierce competition, they must have done something right indeed, but "IM as a cheap alternatives to SMS" was popular a decade before WA)
> WA also uses the Signal Protocol, which I assume is not directly compatible with OMEMO
"Signal Protocol" is a mashup of encryption algorithms, signaling and session negotiation, at its very core there is the double-ratchet algorithm (for forward secrecy) and prekeys (for offline delivery), OMEMO is just that, implemented over XMPP primitives (with prekeys served over PubSub/PEP).
> My point is that it's not as simple as setting COMPATIBLE=TRUE to make every network compatible with each other.
Indeed, it would take some careful considerations, but eh, same can be said about TLS. At a first glance, I don't see anything radically difficult about it, the main point would probably be to offer a generic endpoint to serve prekeys and there's nothing revolutionary or difficult about that.
> I doubt Facebook deviated from the base protocol just for the sake of it
They did what every big business does: they optimized for their specific needs. When they decided that compatibility wasn't something they could monetize, they shut the gateway down and stopped caring about it. That tells nothing about the protocol, its capabilities, or of a presumed inability to extend it. For that matter, the X in XMPP stands for "eXtensible" protocol, and it's been quite good at keeping up for about 22 years, now :)
"It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time"
If you ignore IRC...
"Signal just works."
It also contributes to the fragmentation you complained about, because it is closed -- no federation, no third party clients, not even a web client. If you are on a platform the Signal team does not have time to deal with then there is no option for you. If you have a specific need that the Signal team cannot take the time to support, too bad. More problematic than lacking federation is lacking any third party client software.
Whenever I confront developers about this the conversation usually results in someone demanding a specific example of a user need they are not meeting; if I give one, they say, "Oh, we are planning that, but we first need to do $XYZ!" and if I say "there are needs we may not be aware of" they say "Well we are trying to do $this or $that, we can't solve everyone's problems!" As if users who have unusual or overlooked needs deserve to be cut off from everyone else...
Signal is still an improvement over other non-federated messengers in that it's open-source, so you actually can try to improve the situation, although it's notoriously difficult. As an example of more platform support: https://github.com/signalapp/ringrtc/pull/12
The main problem right now is that they don't have enough developers to take care of everything, but it's not specific to centralized services (no developer == no code). If you care about it, you can develop your own client using their library (à la signal-cli).
Regarding your last paragraph: I could probably list 20 features I'd like to see in Signal. That doesn't mean I want somebody implementing them with no guarantee about how securely they are implemented. One of the main goals of Signal is to provide guarantees against dragnet surveillance, and that constraint takes precedence.
Open Source but not actively accepting contributions is not a great place to be. Especially when you can't federate, so you are stuck using the central server which basically doesn't accept code contributions. Take a look at https://merge-chance.info/target?repo=https://github.com/sig...
Also it is somewhat interesting that this Open Source centralised Signal server, where centralisation means you can move quicker, hasn't seen a commit in 10 months.
I have an alternative view to offer here, because this to me sounds like you are leaving out a significant part of mobile messenger evolution.
Back when Smartphones weren't a thing most phones had JavaME, and the most popular networks for chatting were MSN, ICQ, AOL and others. I'll focus on ICQ specifically here because it's what's been popular where I live. It had been a messenger for people with computers, but then suddenly everyone started using it with an unofficial JavaME client Jimm. Literally every person with a phone, even though it was a complicated thing to do - you had to register on the ICQ website using a computer, build or download a pre-built Jimm for your phone (you had to cater it to the hardware, because phones had been very different back then from model to model) and log into ICQ from your phone. Most cellphone stores offered "Jimm setup" as a service for people who couldn't do it themselves. The reason for such popularity? SMS limitations made it very expensive to have long chats on the go, and ICQ demanded so little traffic that you could use it for a fraction of SMS costs. And of course, as most multi-clients at the time, Jimm had full XMPP support, after all ICQ, AOL and MSN were little more than slightly customized XMPP at the time. So switching to any other XMPP server was pretty trivial.
Anyway, this lasted for a long time, and then, sadly, a smartphone "revolution" happened. People started getting smartphones left and right, and unlike JavaME phones they were much, much worse for ICQ, XMPP or any other similar network. See, a JavaME phone was perfectly capable of maintaining connection to ICQ servers in the background, without draining your battery life too much. It was seamless, most phones at the time allowed for at least one app to run in the background at all times. But once Android and iOS came along - suddenly a phone had to either be sleeping all the time or had empty batteries in a few hours, and that was awful news for protocols that relied on continuous connection, like ICQ did.
The only smartphone that played nice with these protocols that I know of is N900.
Sadly this, and this thing only killed XMPP, ICQ and others for an average person. If it wasn't for these protocols not playing well with smartphones, I have 0 doubts XMPP would be king right now.
Isn't the fact neither XMPP nor IRC are e2e-encrypted a factor in them catching on?
Nobody wants to use a messenger that's public, or that with a single centralised compromise/hack could make all their messages become so.
To me that disqualifies them as even being potential solutions to the problem.
Matrix has significant usability issues in its currently-available form(s) - but it at least meets the most basic of requirements that user messages are private, and does so fundamentally.
XMPP has omemo for encryption which is support by default by both major severs and every client i've tried -- especially the ones that aim for user-freindlyness likes conversations
Remember OTR messaging? The benefit of an open system like XMPP is that you can add end-to-end encryption if you want to do so.
Really though, why is end-to-end encryption the one thing that should disqualify a system? What about a10y, i18n, etc.? For a vision-impaired user a10y matters a whole lot more than encryption. That is the real point of openness and federation -- allowing users' needs to be met by any developers who have the time and inclination to do so, rather than leaving users at the mercy of a single team (or even a single person).
Empathy, the Gnome messaging software, has yet to implement end-to-end encryption because of this mode of thinking. Rather than implement OTR they said they felt it was better to implement a protocol with E2E built in since it would be supported by native clients (what does that even mean for XMPP?). As a result, their users never had end-to-end encrypted messaging at all.
That is what being religious about these things gets you. Signal is completely closed and its users are at the mercy of the developers. XMPP+OTR was a kludge but it worked and the only reason the outstanding problems were not resolved is that the cryptographers behind OTR decided to focus on Signal. Matrix is basically irrelevant right now and whatever security benefits it might have are equally irrelevant because very few people are using it.
Users do not understand that E2EE means no easy device syncing and no serverside search, they just want to feel 'safe', but are not ready to perform such necessary things as fingerprint verification. And without verifying the identity of the remote party, E2EE is totally meaningless.
Telegram's far better UX than Whatsapp is possible because they do not have e2ee on anything but Secret Chats (and I've never seen anyone on Telegram using them). See, for most users the promise of security is better than actual security and all attached UX problems.
It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time, but why can Matrix solve this problem if XMPP cannot? Signal just works.