▲ 137 points
back
96 comments
We were living in the future. Around ~2010 we could use Jabber/XMPP to chat with people on various community services, Google Talk, LiveJournal talk, etc. Besides great Linux clients, macOS had iChat which supported XMPP, etc.
Yep it was great. I had one client per device. Could talk to everybody. I had a consistent UX. Sure sharing pictures and videos wasn't easy then. But also the pay to use features and dark patterns weren't an issue either.
This was the high point of megaupload and bittorrent, sharing photos, videos, and other large files was very easy!
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 :)
I miss the days when our best minds developed protocols instead of products. The last 15 years has been just the commodification and destruction of everything the previous generation has built.
I'm frankly surprised email has stood up as well as it has, even if it is nearly impossible to run your own email server these days.
In the mid-to-late teens IRC was making something of a comeback and then Slack EEE'd it.
I had optimism for Slack when they launched IRC and XMPP gateways natively. Sadly, this is now long dead.
> The last 15 years has been just the commodification
Just a lexical correction to your message: the establishment of standard protocols is a process of comodification. The main goal of making a product "unique" and not interoperable is to avoid being comoditized.
I briefly worked on an XMPP client around that time. It cemented my opinion that the protocol was an absolute abomination.
That's quite unspecific and unhelpful.
Personally I find XMPP much makes sense. Sure it's this weird streaming XML thing, but there's a request/response pattern (IQ) inside that seems fine. I love how nicely it composes: accounts have a tree of nodes they can define for whatever content they want, which is a sensible & flexible base. Then there's pubsub, and ACL capability specs on top of that. Everything stacks relatively sensibly. The past decade has seen some good XMPP Enhancement Protocols (XEP) to create best practices & recommended feature sets.
It was such a small jump to create a full "everything app" atop XMPP baseline capabilities:
> Libervia [ed: nee Salut-a-Too] is a all-in-one tool to manage all your communications needs: instant messaging, (micro)blogging, file sharing, photo albums, events, forums, tasks, etc.
It's unfortunate that the top rated comment is uncontestable blanket desparagement. Can we raise this from a low criticism to something respect-worthy?
Company I worked at back then used XMPP. There was something that you could paste into the chat that would make all of the Mac clients crash, and to fix it, someone with a different client would have to join the chat and type a lot of comments to flood the history.
I am not surprised to hear the protocol is an abomination.
Pro tip: when a protocol's name contains the words "extensible", "flexible", "universal", "interoperable", they tend to be utter abominations designed by a committee of stakeholders often with conflicting, if not completely unreasonable, requirements.
XMPP fans are continuously baffled by why XMPP isn't used for _everything_. STILL! When will the world wake up and realize its simplicity and beauty?
You could even use an XMPP client with HipChat for your business chat. Though, I'd argue XMPP was one of the factors that contributed to HipChat's demise (it wasn't the sole reason, but trying to scale presence via XMPP proved to be a nightmare).
Presence is the key problem. It scales badly - in terms of compute, bandwidth, and battery. And it's not actually useful. Lose lose. Solution: don't use XMPP.
Trillian and Gaim... (2000 and 1999)
Now Gajim still exists and is maintained. :P
Matrix Bridges do something similar.
Those services, and more like facebook messenger used the XMPP protocol on both ends. Matrix bridges clumsily translate some of the feature of one protocol and display the chat on the other end.
Those were good times.
> Moving to XMPP - using prosody - worked really well for messaging, but the lack of real-time notifications on Sandra’s iPhone was sub-optimal
Were they using Monal on the iPhone? I use XMPP (Prosody) with some friends. Conversations.im works really well on Android, including push notifications. But the one iPhone user, using Monal, has said notifications don't work, and I don't know how to debug. The Monal website and commit log suggests they should be working. (macOS desktop Monal works fine for me, but it's using a normal live TCP stream to receive notifications, not cell network push notifications.)
AIUI (but actual iOS developers can correct me), for Push Notifications to work on iPhones requires the system to route through the Apple-hosted Apple Push Notification (APN)
https://developer.apple.com/notifications/
This is fairly at odds with the goal of XMPP, where the device listens to the server. But of course that model doesn't really work when the device is sleeping most of the time (and I don't know how IP or TCP connections are handled in an LTE or 5G world, but I'm sure there's a consideration there).
All this to say: iOS is hostile to XMPP.
You're not wrong at all, but despite it all, XMPP has actually supported push notifications for years.
For various reasons it wasn't included "out of the box" in Prosody for a while and was maintained as a community plugin, but that's no longer the case with 13.0.x+ where it's bundled with Prosody and just works.
Monal is probably the most popular XMPP iOS app today.
Apple's implementation of Web Push Protocol is also viciously inconsistent. Battery efficient yes but notifications just go missing or show up days after they were sent. Apple really has a way with keeping their own special native apps and their own services locked in.
Another way to say it would be: XMPP is hostile to power efficiency.
Somewhat fuzzy on the details right now, but:
You need to enable a plugin in prosody for notifications to get routed via Apple’s servers. The plugin is disabled by default, but included in the default installation.
Daily user of XMPP as well since over a decade. I still call it Jabber out of habit. Prosody on server, Profanity on desktop (terminal), Monal on mobile.
Prosody vs. ejabberd?
I have no experience with ejabberd. As for Prosody, it does everything I/we want it to do, is very easy to configure and runs incredibly light - the host is a single-core virtual machine running OpenBSD on 256 MiB of RAM, and we've yet to face resource shortages.
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?
I've been using XMPP since about 5 years for family texting, file/video sharing, and video calling. It works great, and I would highly recommend it.
What works for us (all android) is Prosody + Conversations app (or Blabber is a free version). There are a few guides online for how to install & configure the prosody server. It's fairly non-technical.
Honestly, it works just as well as whatsapp - except there's actual privacy between users. Family messaging is a great use-case as everyone can be on the same server.
Conversations is free if you get it via fdroid. Don't let that stop you from donating for development though.
I've been doing the same thing for my family for the last four years and it's been working really well. We're all on Android and using Conversations as well.
> Moving to XMPP - using prosody - worked really well for messaging, but the lack of real-time notifications on Sandra’s iPhone was sub-optimal, and the lack of any notifications for incoming XMPP calls on her phone was really undesirable.
A note to android users: prosody real time notifications & calls work great combined with the "conversations" app as a client. You see "user is typing", you can transfer files/photo, video. And best of all, you can do audio video calls with adaptive quality (adjusts to your bandwidth) & auto reconnects.
Seen here:
https://mathstodon.xyz/@neil@mastodon.neilzone.co.uk/1149374...
Usage continues two years later ...
What are the actual security concerns when using OMEMO mentioned in the post? Most criticism I find is on implementations.
Saw this linked elsewhere: https://soatok.blog/2024/08/04/against-xmppomemo/
https://omemo.top/
Wish there were more library implementations that clients could leverage.
That post, describing why we shouldn't be using a OMEMO, is almost incoherent. It doesn't outline any problem with the implementation at all. Every criticism is a metacriticism of some sort. Very strange.
I've been a big XMPP fan, having deployed it at customer sites more than a decade ago, running my own self-hosted service for friends and family, and so forth.
I'm disappointed that the experience is still not at feature parity with proprietary solutions. For example, Conversations.im is a great Android client for XMPP, but it still does not support live location.
There's so much potential to be better than the proprietary solutions, too, for example with OsmAnd integration (https://codeberg.org/iNPUTmice/Conversations/issues/11).
Interesting. I would have never thought of using XMPP to share location info like that.
I use Overland[0] and a custom server implementation that lets people I care about see where my phone is(and presumably me).
I maintained my XMPP account for around 5 years. Talked only to one guy there. In the end I just dumped it. The potential is great, but in reality it's a very niche thing.
Am I understanding right that they (two people) only talk with each other? Or at least they only talk with
each other through XMPP?
Can’t help reading that as “Skynet” every time.
I am making notes of this for if/when Chat Control gets the green light from the EU parliament.
AFAIK services such as GMail, Facebook/Instagram Messenger, Skype, Snapchat, iCloud email and X-Box already apply chat control voluntarily:
https://www.esafety.gov.au/sites/default/files/2022-12/BOSE%...
I am aware. I am talking of Chat Control V2, which aims to introduce client side scanning to WhatsApp, Signal and IMessage.