5 ms·

> A lack of good iPhone XMPP clients. As someone whose company used XMPP prior to the iPhone, this is what killed it for us, and I suspect it’s a major contrib

> A lack of good iPhone XMPP clients. As someone whose company used XMPP prior to the iPhone, this is what killed it for us, and I suspect it’s a major contributor to federated XMPP losing any public inertia it had. iPhone push notifications could only be sent with a signing key tied to the same developer account as used to publish the client application. That meant it was impossible to send push notifications from your own XMPP server to a generic XMPP client written by someone else.

lukasb 4y ago
Fascinating. Is this problem solved for Mastodon?
- als0 4y ago
  This restriction that push notifications must only come from the developer’s server is a restriction imposed by Apple and their App Store.
  - mjevans 4y ago
    A solution would be E.G. subscribing to a community (an endpoint URL, or what Discord likes to brainwash consumers by calling a 'server') should trigger background actions that allow that community's chosen point of contact to have push notification capabilities, and to maintain that forward until your subscription is expired.
    - throwaway92394 4y ago
      > should trigger background actions Because of the way iOS works nowadays, you cannot reliably do this for notifications because you can't run apps in the background reliably for this purpose. > allow that community's chosen point of contact to have push notification capabilities This is what push notifications are?
      - mjevans 4y ago
        Not device background. IE submit requests to the iOS mothership and to the endpoint URL to talk to each other and work things out.
        throwaway92394 4y ago
        I apologize I'm not sure what you mean by mothership, I'll assume you mean the core API's the OS presents. I mean that's how requests already work? You ask the system to handle the network for you and it passes the app data? In the context of notifications this isn't an issue for when the app is in the foreground. But when it's in the background the app's event loop isn't ran consistently, so you might not get the notification for hours. To my knowledge the ONLY way to consistently push notifications for apps in the background is through apple's push gateways.
        mjevans 4y ago
        An __off device__ request that is processed server to server. Mobiles aren't "real computers" in the sense of the Internet. They are not intended to be always on; nor always connected from a stable address. They are portable (very smart) terminals, often with poor text input (but usually with reasonable quality camera and microphones), and often a large local cache.
        alrlroipsp 4y ago
        By this definition, doesn't it describe any laptop just as well?
        mjevans 4y ago
        Depends on how it's used. Laptops are more like portable computers and often the end user expects them to take a moment to startup fully even after a resume.
        throwaway92394 4y ago
  - LinAGKar 4y ago
    Presumably you can do like Matrix, and have the developer of the app run a push gateway.
    - MattJ100 4y ago
      Exactly, that's how XMPP does it too. Since authentication to the OS vendor APIs are generally linked to the developer's account, that's basically the only practical way to do it.
- zaik 4y ago
  It is solved for XMPP as well: https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html
solar-ice 4y ago
FWIW, this eventually got solved in XEP-0357, which, while it says it's deferred, is actually implemented by common mobile clients and modules exist for both common server implementations. This is the same design that Matrix eventually borrowed to solve the same problem.
- wahern 4y ago
  I dunno how well that solved things as a practical matter. I recently began running a Prosody server to host a group chat (MUC) among myself and some friends. Some of us use Conversations on Android, and one uses Monal on iPhone. I also use Monal's macOS client. The original setup was confusing. I ended up hacking some modules to debug why notifications didn't seem to be working, but eventually I got everything working. (I also wrote a module to sandbox Prosody using pledge and unveil: https://github.com/wahern/prosody-openbsd https://github.com/wahern/prosody-openbsd) Then OpenBSD 7.1 was released, which upgraded Prosody from 0.11 to 0.12. It's roughly around that time that the iPhone Monal user stopped seeing notifications for the MUC. But the Monal app also updated around that time, so it's difficult to place blame. As far as I can tell notifications seem to be going out to the push server, but it's still a bear to debug and I haven't had the time to properly analyze things, let alone fix them. I also installed macOS Monal on my young son's macbook so he could IM me while at work, but for some reason desktop notifications don't work at all for him, not even 1:1 chats, and neither pre- or post-Prosody upgrade. (They work for me on my mac mini, though.) We can still chat, but he has no idea if I replied unless he's monitoring the Monal chat window. It's most likely a client-side Monal or macOS issue, though, because Monal doesn't even appear in the Systems Preferences -> Notifications & Focus application list, and side-channel push notifications shouldn't even be involved. Years ago I used Adium on macOS and ejabberd server-side and things seemed to work more smoothly, even when chatting with Google Talk users. But now Adium is no longer maintained and has fallen behind in extension support. In some ways the XMPP ecosystem seems to have regressed even for the simple stuff, let alone the more complex mobile and MUC support.
  - solar-ice 4y ago
    MUCs are sadly the absolute worst part of XMPP we see on a day-to-day basis. I don't think mobile notifications in them are actually solveable - while you're not connected, the MUC has absolutely no idea you exist, so why would it send you a push notification. I'm very hopeful that MIX eventually solves the problems we have with it.

lukasb 4y ago

Fascinating. Is this problem solved for Mastodon?

als0 4y ago
This restriction that push notifications must only come from the developer’s server is a restriction imposed by Apple and their App Store.
- mjevans 4y ago
  A solution would be E.G. subscribing to a community (an endpoint URL, or what Discord likes to brainwash consumers by calling a 'server') should trigger background actions that allow that community's chosen point of contact to have push notification capabilities, and to maintain that forward until your subscription is expired.
  - throwaway92394 4y ago
    > should trigger background actions Because of the way iOS works nowadays, you cannot reliably do this for notifications because you can't run apps in the background reliably for this purpose. > allow that community's chosen point of contact to have push notification capabilities This is what push notifications are?
    - mjevans 4y ago
      Not device background. IE submit requests to the iOS mothership and to the endpoint URL to talk to each other and work things out.
      - throwaway92394 4y ago
        I apologize I'm not sure what you mean by mothership, I'll assume you mean the core API's the OS presents. I mean that's how requests already work? You ask the system to handle the network for you and it passes the app data? In the context of notifications this isn't an issue for when the app is in the foreground. But when it's in the background the app's event loop isn't ran consistently, so you might not get the notification for hours. To my knowledge the ONLY way to consistently push notifications for apps in the background is through apple's push gateways.
        mjevans 4y ago
        An __off device__ request that is processed server to server. Mobiles aren't "real computers" in the sense of the Internet. They are not intended to be always on; nor always connected from a stable address. They are portable (very smart) terminals, often with poor text input (but usually with reasonable quality camera and microphones), and often a large local cache.
        alrlroipsp 4y ago
        By this definition, doesn't it describe any laptop just as well?
        mjevans 4y ago
        Depends on how it's used. Laptops are more like portable computers and often the end user expects them to take a moment to startup fully even after a resume.
        throwaway92394 4y ago
- LinAGKar 4y ago
  Presumably you can do like Matrix, and have the developer of the app run a push gateway.
  - MattJ100 4y ago
    Exactly, that's how XMPP does it too. Since authentication to the OS vendor APIs are generally linked to the developer's account, that's basically the only practical way to do it.
zaik 4y ago
It is solved for XMPP as well: https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html

solar-ice 4y ago

FWIW, this eventually got solved in XEP-0357, which, while it says it's deferred, is actually implemented by common mobile clients and modules exist for both common server implementations. This is the same design that Matrix eventually borrowed to solve the same problem.

wahern 4y ago
I dunno how well that solved things as a practical matter. I recently began running a Prosody server to host a group chat (MUC) among myself and some friends. Some of us use Conversations on Android, and one uses Monal on iPhone. I also use Monal's macOS client. The original setup was confusing. I ended up hacking some modules to debug why notifications didn't seem to be working, but eventually I got everything working. (I also wrote a module to sandbox Prosody using pledge and unveil: https://github.com/wahern/prosody-openbsd https://github.com/wahern/prosody-openbsd) Then OpenBSD 7.1 was released, which upgraded Prosody from 0.11 to 0.12. It's roughly around that time that the iPhone Monal user stopped seeing notifications for the MUC. But the Monal app also updated around that time, so it's difficult to place blame. As far as I can tell notifications seem to be going out to the push server, but it's still a bear to debug and I haven't had the time to properly analyze things, let alone fix them. I also installed macOS Monal on my young son's macbook so he could IM me while at work, but for some reason desktop notifications don't work at all for him, not even 1:1 chats, and neither pre- or post-Prosody upgrade. (They work for me on my mac mini, though.) We can still chat, but he has no idea if I replied unless he's monitoring the Monal chat window. It's most likely a client-side Monal or macOS issue, though, because Monal doesn't even appear in the Systems Preferences -> Notifications & Focus application list, and side-channel push notifications shouldn't even be involved. Years ago I used Adium on macOS and ejabberd server-side and things seemed to work more smoothly, even when chatting with Google Talk users. But now Adium is no longer maintained and has fallen behind in extension support. In some ways the XMPP ecosystem seems to have regressed even for the simple stuff, let alone the more complex mobile and MUC support.
- solar-ice 4y ago
  MUCs are sadly the absolute worst part of XMPP we see on a day-to-day basis. I don't think mobile notifications in them are actually solveable - while you're not connected, the MUC has absolutely no idea you exist, so why would it send you a push notification. I'm very hopeful that MIX eventually solves the problems we have with it.