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.)
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.
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.
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 have no idea if that's in the guidelines but that's how it works.
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.
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.
I am not surprised to hear the protocol is an abomination.
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?
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.
(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)
Who needs APIs when a computer can exploit the analog hole and use the same affordances as a human?
That was a problem back then and it's a problem right now
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.
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.
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.
> 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.
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.
(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.
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.
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.
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'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).
I use Overland[0] and a custom server implementation that lets people I care about see where my phone is(and presumably me).
Prosody works well with Conversations or Blabber on android
https://www.esafety.gov.au/sites/default/files/2022-12/BOSE%...
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.
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.
ColinWright•15h ago
https://mathstodon.xyz/@neil@mastodon.neilzone.co.uk/1149374...
Usage continues two years later ...
riedel•15h ago
digianarchist•13h ago
Wish there were more library implementations that clients could leverage.
DoctorOW•2h ago
xmpp-enjoyer•1h ago
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/
devrandoom•34m ago