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.
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.
> 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.
Yeah, "commodification" is the wrong word here. I'm not sure what the best word would be, but it would be more along the lines of "extraction" or "exploitation".
As in:
The last 15 years has been just relentless attempts to bend and twist everything the previous generation has built to extract value instead of creating it.
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?
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.
This kind of checks out for me. But also, there have been decent protocols around this for a long time, that many clients & servers have implemented. From Multi-device in the excellent Modern XMPP:*
> XEP-0280: Message Carbons - for "live" synchronization of conversations between online devices.
XEP-0313: Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline
The XEP-0313 spec dates back to 2012 which is less old than I expected, and that's only the 0.1. So, very fair point.
More generally, the above complaint was about the development experience of XMPP. I feel somewhat like complaining about XMPP being failed is well tread from a why consumers didnt adopt it view, that negative sentiment abounds & everyone is more than happy to cast blame as to why. I've seen a lot less complaints about the development experience, and felt like maybe there was some novel fruitful grounds that a more developer-centric view might have been able to open up.
> but I blame the "everything is an extension" model ...
100%. If you're not keen on self-hosting and want to use any one of the many, many public servers this becomes such a pain, and leads to the same "decision deadlock" trying to get friends to join Mastodon or Lemmy ("which one do I want? there are so many, how do I know if it's good"). Because this is a thing:
https://compliance.conversations.im/
"Hmmm, does xyz.com support XEP-1234 for message archiving?" or whatever it is; there's a real uphill social battle unless you make those choices for your friends to get started. While Signal is not perfect, it's easy onboarding without confusing XEP which-server choices for the average human. $0.02 I struggle to get people on Signal as it is.
Edit: found it, it's XEP-0313 and only 92% of public servers support it. Only 86% support Push Notifications, 94% OMEMO. One can argue server operators have disabled them but it points back to decision deadlock.
> 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
I could be wrong, but that reads like you suggest that there is an alternative to the "extension model".
However, any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions.
Think about protocols like SMTP and DNS—each has a foundational core that’s been expanded upon by numerous optional features.
> any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions.
You can call the kind of optionality that those kind of protocols have "extensions" if you want, but it's a lot more lightweight than the kind of extensibility that XMPP was designed around, which is the thing that I'm arguing did more harm than good.
(Seemingly) conflicting extensions are another consequence of the loosely coupling between standardization and implementations. In addition, the emergence of several functionally overlapping extensions is stimulated by the freely accessible standardization process.
Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.
> Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.
With any standard you can experiment what you want, nobody* even can prevent you from doing it no matter how inaccessible the standardization process is.
The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem.
What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components?
Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)
*okay technically not correct. Law can e.g. decide making e2ee illegal technology and criminalize even playing around with it.
> The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem.
Na, the standardization process starts much earlier. Using the example of the IETF process, after which XMPP standardization process is largely modeled: standardization starts when you submit an I-D to IETF and/or approach an IETF WG.
> What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components? Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)
Well put and I totally agree (I think no one would have a reason to disagree with that statement).
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.
If your opinion is based on concrete experience, you could help people understand your position by sharing the specific aspects of XMPP that you dislike. An opinion without evidence or reasoning is not a valuable contribution to the conversation.
It's been well over 10 years since I worked with, almost 15. I remember issues with keeping multiple devices in sync, syncing them back up when a user comes back online, especially with multiuser chats. I understand that is probably better now, with carbons and archiving XEPs.
In general, it felt like, XMPP has too many "optional" features. The core protocol is tiny, but everything you need and want to make it useful is optional.
My opinion:
XMPP is too little like Matrix (e.g. decentralized rooms, people as verification targets, messages (incl. e2ee ones) easily synced to all sessions) while Matrix is in a sub optimal state due to the Element/Element X client split
Don't worry, every single one of these discussion is a dozen fanboys trying to convince us that our problems back then weren't real :/
(JFTR, was a relatively happy user amongst fellow nerds & family until everyone just stopped using it, and also usage on mobile was terrible on early smart phones and fixed much too late)
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.
>The traffic needed to maintain presence scales by N^2
Only true if we assume the average number of contacts scales linearly with the total number of users, right? But then, we could also assume that the average number of messages that a given user sends scales linearly with the total number of users, in which case the amount of traffic needed to transmit messages also scales by N^2.
A couple of easy fixes: cap the number of contacts at some large constant (as many services do), or just disable presence information altogether in your implementation. I'm skeptical that this played a major role in XMPP's lack of popularity, especially because e.g. WhatsApp and Facebook Messenger have presence information, and are still popular.
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?
I don't think having a single user-facing client has ever really been held back by the technology. It's always the services being intentionally proprietary, intentionally breaking 3rd party clients, and ToSs making it risky to do.
I mean, different platforms exist just the same as back then. Windows, Linux, Android, iOS (and let's say some nerds will make it work on osx and the BSDs from the linux version).
That was a problem back then and it's a problem right now
There have always been approaches to multi platform apps, the limitations attempts at this (both in the past and currently) have repeatedly been a great UI with hostile 3rd party services.
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.
Yeah, there was a similar bug in HexChat and other (pango?) stuff some years back. I remember even though I was using irssi, it could crash my Termite window.
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.
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.
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.
> 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)
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).
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.
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.
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.
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.
They require push notifications to be signed with your certificate. You must maintain the infrastructure to do this yourself because you can't share the certificate with third parties (obviously) and downtime will mean no push notification delivery.
I have no idea if that's in the guidelines but that's how it works.
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.
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.
OMEMO is not a server feature, it's a client feature, but yes OMEMO works with Prosody in the picture. It's mature, modern and actively developed, the full list of extensions supported by Prosody is here: https://prosody.im/doc/xeplist
Additionally, as per your link, it says "Supported, XEP-0222" for OMEMO encryption, not that "Applicable to clients only, so will work with Prosody", like it does for some others.
For OMEMO to function smoothly it wants permanent storage for Publish/Subscribe functionality (XEP-0222) on the server. The feature predates OMEMO and was designed for various other purposes, such as storing a contact roster or profile picture on your account. OMEMO works without XEP-0222, but then the clients are forced to "meet for the first time" every time they connect and want to exchange encrypted messages. OMEMO in itself happens entirely on the clients.
Perhaps 20-25 at peak, some of which are in MUC ("group chat"). XMPP itself is very lean, on the server side it's mainly a message relay, and Prosody can handle a ton of concurrent traffic on practically nothing worth of server specs.
> 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.
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.
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.
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 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.
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.
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.
Yeah, "commodification" is the wrong word here. I'm not sure what the best word would be, but it would be more along the lines of "extraction" or "exploitation".
As in: The last 15 years has been just relentless attempts to bend and twist everything the previous generation has built to extract value instead of creating it.
Something like that.
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.
https://libervia.org/
It's unfortunate that the top rated comment is uncontestable blanket desparagement. Can we raise this from a low criticism to something respect-worthy?
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.
This kind of checks out for me. But also, there have been decent protocols around this for a long time, that many clients & servers have implemented. From Multi-device in the excellent Modern XMPP:*
> XEP-0280: Message Carbons - for "live" synchronization of conversations between online devices. XEP-0313: Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline
https://docs.modernxmpp.org/client/protocol/
The XEP-0313 spec dates back to 2012 which is less old than I expected, and that's only the 0.1. So, very fair point.
More generally, the above complaint was about the development experience of XMPP. I feel somewhat like complaining about XMPP being failed is well tread from a why consumers didnt adopt it view, that negative sentiment abounds & everyone is more than happy to cast blame as to why. I've seen a lot less complaints about the development experience, and felt like maybe there was some novel fruitful grounds that a more developer-centric view might have been able to open up.
> but I blame the "everything is an extension" model ...
100%. If you're not keen on self-hosting and want to use any one of the many, many public servers this becomes such a pain, and leads to the same "decision deadlock" trying to get friends to join Mastodon or Lemmy ("which one do I want? there are so many, how do I know if it's good"). Because this is a thing:
"Hmmm, does xyz.com support XEP-1234 for message archiving?" or whatever it is; there's a real uphill social battle unless you make those choices for your friends to get started. While Signal is not perfect, it's easy onboarding without confusing XEP which-server choices for the average human. $0.02 I struggle to get people on Signal as it is.Edit: found it, it's XEP-0313 and only 92% of public servers support it. Only 86% support Push Notifications, 94% OMEMO. One can argue server operators have disabled them but it points back to decision deadlock.
> 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
I could be wrong, but that reads like you suggest that there is an alternative to the "extension model".
However, any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions.
Think about protocols like SMTP and DNS—each has a foundational core that’s been expanded upon by numerous optional features.
> any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions.
You can call the kind of optionality that those kind of protocols have "extensions" if you want, but it's a lot more lightweight than the kind of extensibility that XMPP was designed around, which is the thing that I'm arguing did more harm than good.
Optional features is something different than uncoordinated extensions which might conflict with each other.
I am not sure if I would phrase it that way.
(Seemingly) conflicting extensions are another consequence of the loosely coupling between standardization and implementations. In addition, the emergence of several functionally overlapping extensions is stimulated by the freely accessible standardization process.
Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.
> Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.
With any standard you can experiment what you want, nobody* even can prevent you from doing it no matter how inaccessible the standardization process is.
The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem.
What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components?
Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)
*okay technically not correct. Law can e.g. decide making e2ee illegal technology and criminalize even playing around with it.
> The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem.
Na, the standardization process starts much earlier. Using the example of the IETF process, after which XMPP standardization process is largely modeled: standardization starts when you submit an I-D to IETF and/or approach an IETF WG.
> What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components? Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)
Well put and I totally agree (I think no one would have a reason to disagree with that statement).
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.
If your opinion is based on concrete experience, you could help people understand your position by sharing the specific aspects of XMPP that you dislike. An opinion without evidence or reasoning is not a valuable contribution to the conversation.
It's been well over 10 years since I worked with, almost 15. I remember issues with keeping multiple devices in sync, syncing them back up when a user comes back online, especially with multiuser chats. I understand that is probably better now, with carbons and archiving XEPs.
In general, it felt like, XMPP has too many "optional" features. The core protocol is tiny, but everything you need and want to make it useful is optional.
My opinion: XMPP is too little like Matrix (e.g. decentralized rooms, people as verification targets, messages (incl. e2ee ones) easily synced to all sessions) while Matrix is in a sub optimal state due to the Element/Element X client split
Don't worry, every single one of these discussion is a dozen fanboys trying to convince us that our problems back then weren't real :/
(JFTR, was a relatively happy user amongst fellow nerds & family until everyone just stopped using it, and also usage on mobile was terrible on early smart phones and fixed much too late)
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.
>The traffic needed to maintain presence scales by N^2
Only true if we assume the average number of contacts scales linearly with the total number of users, right? But then, we could also assume that the average number of messages that a given user sends scales linearly with the total number of users, in which case the amount of traffic needed to transmit messages also scales by N^2.
A couple of easy fixes: cap the number of contacts at some large constant (as many services do), or just disable presence information altogether in your implementation. I'm skeptical that this played a major role in XMPP's lack of popularity, especially because e.g. WhatsApp and Facebook Messenger have presence information, and are still popular.
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?
I don't think having a single user-facing client has ever really been held back by the technology. It's always the services being intentionally proprietary, intentionally breaking 3rd party clients, and ToSs making it risky to do.
I mean, different platforms exist just the same as back then. Windows, Linux, Android, iOS (and let's say some nerds will make it work on osx and the BSDs from the linux version).
That was a problem back then and it's a problem right now
There have always been approaches to multi platform apps, the limitations attempts at this (both in the past and currently) have repeatedly been a great UI with hostile 3rd party services.
A "User-Agent" if you will.
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.
Seems like a problem with the client rather than the protocol.
Kinda, but if there is only a limited subset of clients and everyone is basically on the one default per platform, it simply doesn't help.
Yeah, there was a similar bug in HexChat and other (pango?) stuff some years back. I remember even though I was using irssi, it could crash my Termite window.
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.
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.
Trillian and Gaim... (2000 and 1999)
Now Gajim still exists and is maintained. :P
Gajim is unrelated to Gaim. Gaim was renamed to Pidgin though, which still exists.
Oh, yeah I knew Gaim became Pidgin, but I thought Gajim is a fork of Gaim as well, Gaim revived. Oops.
Being in any way associated with AIM/AOL was a bad thing, which they probably realized way too late.
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.
> 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.
Thanks Matt! (prodigy creator of Prosody)
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.
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.
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.
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.
I can find no such requirement in the App Store Guidelines. Or is there anecdotal evidence somewhere?
They require push notifications to be signed with your certificate. You must maintain the infrastructure to do this yourself because you can't share the certificate with third parties (obviously) and downtime will mean no push notification delivery.
I have no idea if that's in the guidelines but that's how it works.
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?
OMEMO is not a server feature, it's a client feature, but yes OMEMO works with Prosody in the picture. It's mature, modern and actively developed, the full list of extensions supported by Prosody is here: https://prosody.im/doc/xeplist
> OMEMO is not a server feature, it's a client feature
Are you sure?
https://xmpp.org/extensions/xep-0384.html#server-side
Additionally, as per your link, it says "Supported, XEP-0222" for OMEMO encryption, not that "Applicable to clients only, so will work with Prosody", like it does for some others.
What gives?
For OMEMO to function smoothly it wants permanent storage for Publish/Subscribe functionality (XEP-0222) on the server. The feature predates OMEMO and was designed for various other purposes, such as storing a contact roster or profile picture on your account. OMEMO works without XEP-0222, but then the clients are forced to "meet for the first time" every time they connect and want to exchange encrypted messages. OMEMO in itself happens entirely on the clients.
yes, prosody supports OMEMO.
Prosody works well with Conversations or Blabber on android
Thanks. I use Conversations on Android. Gajim on desktop. :)
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?
Perhaps 20-25 at peak, some of which are in MUC ("group chat"). XMPP itself is very lean, on the server side it's mainly a message relay, and Prosody can handle a ton of concurrent traffic on practically nothing worth of server specs.
> 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.
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.
Seen here:
https://mathstodon.xyz/@neil@mastodon.neilzone.co.uk/1149374...
Usage continues two years later ...
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.
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/
For balance, see OMEMO Author Tim Henkes' response [1] to the blog, which was moderated.
This is linked from this blog post [2] where the author explains that they prefer XMPP, because it is not a silo.
[1] https://www.moparisthebest.com/tim-henkes-omemo-response.txt
[2] https://www.moparisthebest.com/against-silos-signal/
That was a good read. The furry blog post read like a smear campaign. Extraordinary unprofessional.
https://omemo.top/
Wish there were more library implementations that clients could leverage.
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.
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).
0: https://overland.p3k.app
Can’t help reading that as “Skynet” every time.
Am I understanding right that they (two people) only talk with each other? Or at least they only talk with each other through XMPP?
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.