A month using XMPP (using Snikket) for every call and chat (2023)

By easy I was thinking of when I merely need a long press on a button to record, compress and upload along side my message those days :)

XMPP missed the boat largely because it couldn't handle multiple clients correctly for years - the default is to deliver messages to one of your clients, you need an extension to do the sensible thing, and that extension spent years in bikeshed limbo right as smartphones were taking off and people started wanting to use the same messenger on their phone and computer at the same time. (I've heard that performance/battery issues from XML validation didn't help either)

Personal speculation but I blame the "everything is an extension" model - it was meant to reduce fragmentation and allow clients with different featuresets to interoperate, but in practice adding a new XEP seems to have all the downsides of making a change to a non-extension-based standard (you still have to get all the clients to agree) and none of the upsides.

I wasn't trying to be specific, just an opinion on what I experienced 10+ years ago. Others are welcome to work with the protocol and develop their own opinions.

In today's world of containerization and AI powered UI automation, perhaps a single user-facing client could be viable again, powered by hidden per-service clients under the hood. Where each services' UI state is continually monitored and interacted with by an AI directed by user interactions in the visible interface. That would be against the services' ToS probably, but it could work I think.

Who needs APIs when a computer can exploit the analog hole and use the same affordances as a human?

Here's a specific complaint about XMPP, and possible explanation why nobody uses it any more. (I worked on a large-scale XMPP implementation back in the day.)

Presence. That's the colored dots indicating "is somebody online or not". The traffic needed to maintain presence scales by N^2, and in any large-scale implementation, the traffic to maintain presence data completely dominates anything useful.

Not to mention that for the past 15 years or so (ever since everybody has a connected cell-phone all the time) the whole idea of presence (am I online or not?) is either meaningless or just badly modeled.

So the result is a protocol which spends tons of bandwidth and battery maintaining metadata that is functionally useless. That's why the real world has run away from it as fast as possible.

Seems like a problem with the client rather than the protocol.

Matrix had similar problems and most servers just disable presence. Can XMPP not do this?

Who GAF about presence. If the person answers, they're there.

Gajim is unrelated to Gaim. Gaim was renamed to Pidgin though, which still exists.

Sounds neat. I may self-host it then on my OpenBSD server with 512 MB RAM. I assume it supports OMEMO and all the modern extensions of XMPP, right?

Oh, I got another question and I cannot edit my comment. How many concurrently online people are there on the server that you can tell?

Conversations is one of the most battery efficient IM clients out there despite maintaining it's own TCP connection. This is possible because Conversations can tell the server to shut up unless it's important, which reduces radio usage a lot. This extension (CSI) is quite mature and found on most servers by now.

It's not that XMPP is hostile to power efficiency, its that Apple (and Google) gateway power-efficient edge triggering behind vendor-restricted cryptographic feature locks.

They have arguably correct reasons for doing this, but it's a false comparison to say that the software is inefficient when its just as efficient that anything else at that privilege level on the phone can do.

Wrong. Apple (or Google) also use the same TCP based approach to maintain connectivity to allow notifications. No way is an extra connection responsible for bad power efficiency, with that small payloads. This is propaganda.

Nope. You can do push with XMPP just like everything else. The problem is that Apple demands open source client maintainers also personally maintain infrastructure with high availability to handle the push notifications rather than allowing them to delegate that to service operators where it belongs.

Apple is aggressively hostile to open source is the problem. IMO their behavior is why we don't have any nice open source chat apps like we did before the iPhone became popular.