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.
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.
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.
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).
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).
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.
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 :)
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-cli is an example of a 3rd party client which is tolerated for now: https://github.com/AsamK/signal-cli
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.
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.
Compare it to Matrix Synapse https://merge-chance.info/target?repo=https://github.com/mat...
The story with the flagship clients in both spaces is very similar.
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.
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).
Because security as an afterthought is known to fail.
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.
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.