3 ms·

Jabber/XMPP started to suck at the moment we've started using smartphones that keep reconnecting between wifi and mobile networks as i move around. relying on t

by harvie 20d ago

Jabber/XMPP started to suck at the moment we've started using smartphones that keep reconnecting between wifi and mobile networks as i move around. relying on that single persistent TCP connection does not make sense anymore. This is huge pain with IRC as well... And no, i will not run server-side proxy irc client that is supposed to keep me reachable while im reconnecting. Also sending media (or even rich text) never really worked as each client implemented it differently. While whatsapp just works...

jszymborski 20d ago
So, my understanding is that while XMPP has historically sucked on mobile, it's gotten better? Does anyone know about the current experience? I don't know if it's due to new XEPs or if it's just better client implementation...
- jkxyz 20d ago
  If you're talking about the push notifications experience, then XEP-0357 solves this, but app developers have to host the infrastructure which the XMPP server calls back to and dispatches the notifications to Apple or Google. Last time I used Monal on iOS this was solved and worked well. On Android I think most apps still prefer to keep their own background connection open. https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html
  - Leonard_of_Q 20d ago
    > On Android I think most apps still prefer to keep their own background connection open Many Android apps give the option of using either FCM (Firebase Cloud Messaging, Google's push service), UnifiedPush or polling.
    - ezst 20d ago
      Of note, Conversations and some other XMPP clients can act as UnifiedPush Distributors (i.e. they use their own reliable persistent connection to proxy notifications for other apps). Some mastodon (tusky, fedilab, …), matrix (fluffy chat, element x, …) clients use it¹ ¹: https://unifiedpush.org/users/apps/ https://unifiedpush.org/users/apps/
- Leonard_of_Q 20d ago
  I've been using it for years, so has my family and recently a group of some 60 friends with whom we communicated about a large party ont of my friend and me organised. I made an invitation site with an instance of converse.js at the bottom of the page, pointed at an anonymous group on my (Prosody) server. We just mostly Conversations or one of its forks on Android - no fruit phones among us - and Converse.js on web, higher on the same server which hosts all our other services (mail, "cloud", media, etc.). Once installed and configured it is maintenance-free, lightweight and reliable. That is how you gain traction: by having people use it, realise the user experience is comparable or in some cases superior to that of other messaging systems - the party chat thing I mentioned above being a good example - and then realise they dont need to hand over their data to an ad broker (Google, Metafacebook, the fruit factory) or the government (all of them through some "chat control" type law).
toast0 20d ago
This should be solvable, although maybe a little meh. Client developers on platforms without unrestricted background connections need to run a server for push notifications. And server developers need to accept and use a push url from the clients. If I understand correctly, Google and Apple have a way for clients to request push tokens, but in order to use the token, you have to authenticate as the app owner, so a client unaffiliated with the server can't simply send a push token to a server and have that be used ... Instead you'd need that push proxy server. That proxy server comes with concerns about reliability and privacy and etc, but if you do pushes without cleartext content (and you should!), the footprint is minimal and you gotta do what you gotta do. I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. It's a pretty apparent need for the last I dunno 15 years and it has a clear solution. With the right agitation, maybe you could get sharable platform push tokens and skip the intermediary app developer pusg server, but that seems unlikely. You probably also want something in the push system to help trace push problems. For small chat servers and smallish client push proxy servers, I expect minimal operations staffing, but when messages are being delayed because of push problems, you want to be able to let affected clients know that they need to be more agressive with periodic/background connections until push works again. You may also want to let users or the administrators of the proxy push servers know as well. Pushes might be initiated late on the origin, delayed between the origin and the proxy, queued for a long time at the proxy, delayed between the proxy and platform push, or delayed within platform push (including on device delays from Doze, etc). You've got to be able to detect that so you can make adjustments and reduce delay. Messaging delay reduces user satisfaction.
- seba_dos1 20d ago
  > This should be solvable Yes, and it has been solved long time ago already and is now widely supported by both servers and clients. > I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. See XEP-0198 from 2004 and XEP-0357 from 2015.
  - toast0 20d ago
    > XEP-0357 from 2015 Taking a quick look, this one is marked deferred; I don't know what that means, but it sounds like it's not an accepted standard?. It requires the application push server to be an XMPP server (which I suspect is challenging for client developers, compared to having a https url that takes a POST or similar) and doesn't include a method for a client to request a test push to validate the setup or discuss feedback to the client for push failure. This doesn't feel solved to me. I didn't review XEP-0198 closely, based on perhipheral ecosystem interaction, I do think that one is solved.
zajio1am 20d ago
I have no problem with that with XMPP. Conversations automatically reconnects after each switch within few seconds, so it is transparent for users. On IRC that is huge pain, true.
- wahern 20d ago
  Conversations also supports Android's/Google's push notifications.
ValdikSS 20d ago
XMPP has brilliant session management, it reconnects more seamlessly than many other protocols on mobile. It literally reconnects (rejoins the same session within different TCP connection, not replaces it with a new session). >Also sending media (or even rich text) never really worked as each client implemented it differently. Everyone use HTTP upload nowadays, it works all the time.
- aboardRat4 20d ago
  >Everyone use HTTP upload nowadays, it works all the time No it doesn't. Firstly, an out-of-band upload is ridiculous. Secondly, it doesn't support upload resumption in case the network is bad.
  - ValdikSS 20d ago
    >Firstly, an out-of-band upload is ridiculous It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day. >it doesn't support upload resumption in case the network is bad. There's a draft for HTTP for it: https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html https://httpwg.org/http-extensions/draft-ietf-httpbis-resuma...
    - ezst 20d ago
      Re: P2P, it's kind of making an impromptu comeback. If you want some trivia, IIRC, the developer of Conversations was on some trans-continental flight few months ago and realized that XMPP works just fine on the free onboard internet plan (being considered by the firewall as legitimate "social-usage"), except for HTTP upload. So now, when your HTTP upload fails, Conversations asks if you want to try again with P2P, so you can send your images for free from the plane :-)
    - aboardRat4 20d ago
      >but the alternatives are worse It's not that "alternatives are worse, it's that xmpp is a broken protocol, which doesn't include support for anything, even such a basic thing" >There's a draft LOOOOOOOOL
aidenn0 20d ago
XMPP is more reliable than Signal on iOS. My wife regularly doesn't get Signal notifications for messages that I sent when she was in a marginal service until hours later when she opens the Signal app to send me something. On Android, I've never had any connection issues with either Signal or XMPP, so I would say that this problem is solved.
- mahboi 20d ago
  Does XMPP reliably get push notifications on iOS?
  - aidenn0 20d ago
    My impression is that it does, but I daily-drive an Android phone, so maybe someone else here can comment?
  - yosamino 20d ago
    Bit of a Radio Yerevan Situation. Not even the various emergency broadcast app reliably get timely push notifications. The thing about these notifications seem to be that apps that regularily get notifications from the the app get them reliably. This is based on the observation that xmpp-contacts I'm in regular contact with seem to get notifications quickly and contacts I talk to less regularily not so much. Sadly this dependent on apples whims
    - mahboi 20d ago
      I don't think Apple is the weak link here. Somewhere there must be a gateway between an XMPP server and the APNS. Maybe the server isn't handling it well. I do know APNS was super annoying to deal with before they added the HTTP API. Also huh, I've been to Yerevan but never heard of Radio Yerevan jokes until now, that's pretty funny.
ezst 20d ago
XMPP is so bad on mobile that this persistent connection thingy and the whole XMPP protocol itself are effectively what prop up every single push notification on Android and Nintendo switch. True, Android vendors made a habit of killing background apps for misguided battery optimization reasons (less the case nowadays), which XMPP taught itself to work around in 2014/2015. Same for media, it just works, you should try it? And funny you mention WhatsApp, it's effectively a dialect of XMPP running on a fork of ejabberd.

by harvie 20d ago

jszymborski 20d ago

So, my understanding is that while XMPP has historically sucked on mobile, it's gotten better? Does anyone know about the current experience? I don't know if it's due to new XEPs or if it's just better client implementation...

jkxyz 20d ago
If you're talking about the push notifications experience, then XEP-0357 solves this, but app developers have to host the infrastructure which the XMPP server calls back to and dispatches the notifications to Apple or Google. Last time I used Monal on iOS this was solved and worked well. On Android I think most apps still prefer to keep their own background connection open. https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html
- Leonard_of_Q 20d ago
  > On Android I think most apps still prefer to keep their own background connection open Many Android apps give the option of using either FCM (Firebase Cloud Messaging, Google's push service), UnifiedPush or polling.
  - ezst 20d ago
    Of note, Conversations and some other XMPP clients can act as UnifiedPush Distributors (i.e. they use their own reliable persistent connection to proxy notifications for other apps). Some mastodon (tusky, fedilab, …), matrix (fluffy chat, element x, …) clients use it¹ ¹: https://unifiedpush.org/users/apps/ https://unifiedpush.org/users/apps/
Leonard_of_Q 20d ago
I've been using it for years, so has my family and recently a group of some 60 friends with whom we communicated about a large party ont of my friend and me organised. I made an invitation site with an instance of converse.js at the bottom of the page, pointed at an anonymous group on my (Prosody) server. We just mostly Conversations or one of its forks on Android - no fruit phones among us - and Converse.js on web, higher on the same server which hosts all our other services (mail, "cloud", media, etc.). Once installed and configured it is maintenance-free, lightweight and reliable. That is how you gain traction: by having people use it, realise the user experience is comparable or in some cases superior to that of other messaging systems - the party chat thing I mentioned above being a good example - and then realise they dont need to hand over their data to an ad broker (Google, Metafacebook, the fruit factory) or the government (all of them through some "chat control" type law).

toast0 20d ago

This should be solvable, although maybe a little meh. Client developers on platforms without unrestricted background connections need to run a server for push notifications. And server developers need to accept and use a push url from the clients. If I understand correctly, Google and Apple have a way for clients to request push tokens, but in order to use the token, you have to authenticate as the app owner, so a client unaffiliated with the server can't simply send a push token to a server and have that be used ... Instead you'd need that push proxy server. That proxy server comes with concerns about reliability and privacy and etc, but if you do pushes without cleartext content (and you should!), the footprint is minimal and you gotta do what you gotta do. I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. It's a pretty apparent need for the last I dunno 15 years and it has a clear solution. With the right agitation, maybe you could get sharable platform push tokens and skip the intermediary app developer pusg server, but that seems unlikely. You probably also want something in the push system to help trace push problems. For small chat servers and smallish client push proxy servers, I expect minimal operations staffing, but when messages are being delayed because of push problems, you want to be able to let affected clients know that they need to be more agressive with periodic/background connections until push works again. You may also want to let users or the administrators of the proxy push servers know as well. Pushes might be initiated late on the origin, delayed between the origin and the proxy, queued for a long time at the proxy, delayed between the proxy and platform push, or delayed within platform push (including on device delays from Doze, etc). You've got to be able to detect that so you can make adjustments and reduce delay. Messaging delay reduces user satisfaction.

seba_dos1 20d ago
> This should be solvable Yes, and it has been solved long time ago already and is now widely supported by both servers and clients. > I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. See XEP-0198 from 2004 and XEP-0357 from 2015.
- toast0 20d ago
  > XEP-0357 from 2015 Taking a quick look, this one is marked deferred; I don't know what that means, but it sounds like it's not an accepted standard?. It requires the application push server to be an XMPP server (which I suspect is challenging for client developers, compared to having a https url that takes a POST or similar) and doesn't include a method for a client to request a test push to validate the setup or discuss feedback to the client for push failure. This doesn't feel solved to me. I didn't review XEP-0198 closely, based on perhipheral ecosystem interaction, I do think that one is solved.

zajio1am 20d ago

I have no problem with that with XMPP. Conversations automatically reconnects after each switch within few seconds, so it is transparent for users. On IRC that is huge pain, true.

wahern 20d ago
Conversations also supports Android's/Google's push notifications.

ValdikSS 20d ago

XMPP has brilliant session management, it reconnects more seamlessly than many other protocols on mobile. It literally reconnects (rejoins the same session within different TCP connection, not replaces it with a new session). >Also sending media (or even rich text) never really worked as each client implemented it differently. Everyone use HTTP upload nowadays, it works all the time.

aboardRat4 20d ago
>Everyone use HTTP upload nowadays, it works all the time No it doesn't. Firstly, an out-of-band upload is ridiculous. Secondly, it doesn't support upload resumption in case the network is bad.
- ValdikSS 20d ago
  >Firstly, an out-of-band upload is ridiculous It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day. >it doesn't support upload resumption in case the network is bad. There's a draft for HTTP for it: https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload.html https://httpwg.org/http-extensions/draft-ietf-httpbis-resuma...
  - ezst 20d ago
    Re: P2P, it's kind of making an impromptu comeback. If you want some trivia, IIRC, the developer of Conversations was on some trans-continental flight few months ago and realized that XMPP works just fine on the free onboard internet plan (being considered by the firewall as legitimate "social-usage"), except for HTTP upload. So now, when your HTTP upload fails, Conversations asks if you want to try again with P2P, so you can send your images for free from the plane :-)
  - aboardRat4 20d ago
    >but the alternatives are worse It's not that "alternatives are worse, it's that xmpp is a broken protocol, which doesn't include support for anything, even such a basic thing" >There's a draft LOOOOOOOOL

aidenn0 20d ago

XMPP is more reliable than Signal on iOS. My wife regularly doesn't get Signal notifications for messages that I sent when she was in a marginal service until hours later when she opens the Signal app to send me something. On Android, I've never had any connection issues with either Signal or XMPP, so I would say that this problem is solved.

mahboi 20d ago
Does XMPP reliably get push notifications on iOS?
- aidenn0 20d ago
  My impression is that it does, but I daily-drive an Android phone, so maybe someone else here can comment?
- yosamino 20d ago
  Bit of a Radio Yerevan Situation. Not even the various emergency broadcast app reliably get timely push notifications. The thing about these notifications seem to be that apps that regularily get notifications from the the app get them reliably. This is based on the observation that xmpp-contacts I'm in regular contact with seem to get notifications quickly and contacts I talk to less regularily not so much. Sadly this dependent on apples whims
  - mahboi 20d ago
    I don't think Apple is the weak link here. Somewhere there must be a gateway between an XMPP server and the APNS. Maybe the server isn't handling it well. I do know APNS was super annoying to deal with before they added the HTTP API. Also huh, I've been to Yerevan but never heard of Radio Yerevan jokes until now, that's pretty funny.

ezst 20d ago

XMPP is so bad on mobile that this persistent connection thingy and the whole XMPP protocol itself are effectively what prop up every single push notification on Android and Nintendo switch. True, Android vendors made a habit of killing background apps for misguided battery optimization reasons (less the case nowadays), which XMPP taught itself to work around in 2014/2015. Same for media, it just works, you should try it? And funny you mention WhatsApp, it's effectively a dialect of XMPP running on a fork of ejabberd.