Hacker News Reader

Comment by zanny | Hacker News Reader

Jabber needed reinventing. XMPP grew and thrived in the early 2000s and died as every participant fragmented off to spin up a proprietary walled garden replacement. You then need something better than XMPP to fight back against that partitioning of the messaging space because XMPP implementations became too fragmented in feature compatibility to reliably compete.

View on HN

XMPP is anything but dead yet. There were a lot of XEPs added and updated in recent years and it turned into a modern protocol being able to provide all features you could expect from a modern messaging service.

It's just that you need a client and server that supports those features. Daniel Gultsch has written an Android client[1], that's as good as it can be. He also offers a maintained XMPP server [2] providing the full-featured counterpart. But if you want to self-host, ejabberd supports all the features as does Prosody. For iOS users, there's Monal which is slowly getting there.

[1] https://conversations.im

[2] https://account.conversations.im

Needing a client that supports those features seems like a big ask, though. You're right that Conversations is about as good as an XMPP client can be, and it's a joy to use... but it's one of very few.

Among other things, my server has message archiving configured for MUCs, but Conversations is the only client I've ever been able to get to sync that history locally. That's something I just don't ever have to worry about with Matrix. (Not that I don't have other complaints with Matrix.)

How many different full-featured Matrix clients do you know? And what about lean ones that don’t come in a huge Electron package?

Also, Gajim has support for MAM and can sync everything locally. I believe Monal has it, too.

Also not many, but they all get history syncing down. They have to, it's at the core of the protocol. (And that aside, at least Element is available on just about every platform.)

Yes, I've heard that Gajim and Monal support it. I'm running both of them right now; Gajim doesn't appear to be fetching history from the server for the MUC I'm looking at in either the chat or history windows, Monal seems to attempt to but shows a progress spinner indefinitely. Conversations successfully loads history from the server; I can scroll back to well before I got this phone so I know it's not just local.

I spent a long time trying to get the following to all work:

1. Store and forward 2. e2e encryption 3. Messages received on multiple clients at the same time, with clients being able to reconnect and pick up the complete conversation history.

In theory, all possible.

In reality, none of the clients I tried supported the same combo of XMPP plugins and encryption methods.

Oh, and I need clients that work on MacOS, Windows, and Android.

I am using conversations legacy on Android right now because that works with how ejabberd is setup on my machine, and how ejabberd is setup works with the clients other people I want to talk to are using.

I gave up using XMPP on a laptop since I'd get encrypted messages with the wrong key sent to other devices except whichever one I'd used most recently to send a message with.

I never did manage to set sending images working at faster than ~2KB/s.

It is like I am back in 1996 and using AOL IM, but worse.

I’m using ejabberd 20.07 on a Raspberry Pi 4, Conversations (paid) on Android, Monal on iOS and macOS and Gajim on Windows and Linux (sometimes macOS, too). OMEMO works fine between those. So do attachments/file transfers (not slow at all). Also MAM/history.

To have OMEMO working between multiple clients but the same user, make sure they’re all running and send a message from each client to your OMEMO contacts so they learn all your different keys and send answers encrypted for all of them.

In regards to Matrix. There’s only one reference client at the moment. But once other clients emerge and the protocol gets extended, they’ll probably have the same fate in that many 3rd party clients won’t support all features.

Just for the sake of accuracy, Matrix really does have a lot of impressively feature complete clients these days - Element, FluffyChat, Weechat, Mirage etc (and technically Element is 3 entirely non-overlapping codebases on web/desktop, iOS & Android). And the protocol is busy evolving; with MSCs landing on some clients before others (e.g. FluffyChat implements BlurHash based image thumbnails but Element doesn't yet). So far we haven't had massive fragmentation though, because the spec itself is monolithic - it's completely unambiguous on what the official recommended featureset is at any point in time. Anything beyond that is experimental, and there's no guarantee that it will work compatibly at all. So when something like blurhashes turns up as a random community spec change proposal (https://github.com/matrix-org/matrix-doc/blob/anoa/blurhash/...), some clients go and implement it, and once proven it gets baked into the official spec.

xmpp works, but barely. Some people will insist on you talking to them using otr, and other will insist on omemo. Multi-device kinda sorta works sometimes. If you have program 1, the other person has program 2 on phone and program 3 on computer, and the issue is also potentially with the configuration of server program 4 or 5, then it starts to get complicated when issues inevitably crop up. Some of which lead to messages just silently going missing, and you mistakenly think that your friend is ghosting you unless you have an out-of-band way to communicate.

Conversations doesn't display when your friends are online or not, which is fine if they are almost always online but if they are offline a lot, then depending on the server configuration and the phase of the moon, messages sent while offline go missing (silently of course).

EDIT: I think the only setup I could whole-heartedly recommend non-technical friends is Conversations talking to Conversations with Prosody default-settings server(s).

Part of me wonders if this is a fatal flaw in the very concept of distributed systems. It seems to me that as soon as a protocol or technology loses its single authority (multiple companies write implementations) it becomes feature frozen since it would be impossible for multiple companies to come to an agreement on what the new features should be or getting them all to implement them.

If matrix actually does succeed and continue to change I think it will result in having only 1-2 server implementations and 1 client per platform. A hobby dev can't possibly keep up with all the features being implemented by a whole team working on the main client.

it doesn’t have to be a fatal flaw. you “just” have to layer the protocol to give decent abstractions to allow diversity on top of each layer, so as each layer matures you just keep innovating upwards - like the ethernet/ip/tcp/http stack for instance.

The problem I see is every time you drop an extra layer of innovation, you fragment the final product.

For example, Apple adds person to person payments in imessage and it suddenly just works for every single imessage user. If someone did that as a feature on top of matrix you now have a situation where some clients support it and some don't so the feature never really gets used as its too unreliable. Maybe over time the feature rolls out to more clients but there will always be some devs who think "No I don't like this feature, I won't ever add it"

I guess things are a little simpler here since it might be possible to implement new features without server changes as they may just work on top of the standard matrix spec.

This is a great example. Matrix has the concept of widgets which let you embed little webapps, which can be used as a compatibility layer for stuff like payments. For instance video conferencing is done in Matrix as a widget (Jitsi) for clients who just support widgets... but clients with native jitsi support (Element iOS and Android) integrate it natively rather than using a widget.

Reply on news.ycombinator.com