3 ms·

Part of the problem is that Linux desktop apps typically aren't designed to conserve on network usage and/or don't have mechanisms to do so without a push serve

Part of the problem is that Linux desktop apps typically aren't designed to conserve on network usage and/or don't have mechanisms to do so without a push server. For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Desktop clients, on the other hand, will stay running and receive every message, even if they're not messages that you necessarily care about/that would notify. The protocol could in theory have an in-band way to tell the server "hey, I really only care about notifications now, could you only send me those?" but currently it doesn't. By contrast, most Android/iOS apps can rely on push notifications and suspend completely when they're not in the foreground - meaning they're not receiving anything but what's important enough to notify about.

aidenn0 6y ago
> For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. If they already added FCM an APNS, they'll have to add something to support a 3rd OS. It could be in-band or out-of-band, but either way sending a message on a TCP connection is really all that is needed. As a side note, Jabber did add an in-band way as you suggest, but then also had to add OOB signalling because Apple disallows open sockets for background apps.
- ryukafalz 6y ago
  > Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. Yep, it does, so you could do this; the problem for the Linux desktop is just that there isn't a standardized out-of-band push notification system yet. (I saw another commenter mention UnifiedPush, which sounds interesting - in any case it's not widely supported yet.) > As a side note, Jabber did add an in-band way as you suggest It's been a while since I looked into this in detail, but IIRC Jabber generally doesn't have a server-side way to determine which messages should notify? As I recall, the protocol was designed with smart clients and dumb servers in mind, though I'm sure some of that has changed over time - but that design decision doesn't lend itself as well to clients on battery-constrained devices. Although with that said, the fact that you aren't required to be in the same set of MUCs on every device helps in battery-constrained devices; for example I only stay joined to the rooms that my friends are in from my phone, unless I need to join another one temporarily.
  - aidenn0 6y ago
    Re: jabber https://xmpp.org/extensions/xep-0352.html https://xmpp.org/extensions/xep-0352.html
    - ryukafalz 6y ago
      Client state indication helps for things like suppressing presence updates, but it doesn't go as far as to e.g. let you only be notified for messages that would highlight you in a large MUC, right? So either you're joined to the MUC and receive all messages in it, or you leave the MUC and don't get notified about any of them. Although now that I read the spec again, it seems general enough that maybe it could be used to implement behavior like that? I don't think I've seen any servers that do, though.
      - aidenn0 6y ago
        Prosody has an option for filtering MUC messages with mod_csi_battery_saver (which is the currently recommended community module for CSI), I don't think ejabberd does though. > groupchat messages must set a subject or have the user’s username or nickname mentioned in the messages (or be encrypted) to count as “important”.

aidenn0 6y ago

> For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. If they already added FCM an APNS, they'll have to add something to support a 3rd OS. It could be in-band or out-of-band, but either way sending a message on a TCP connection is really all that is needed. As a side note, Jabber did add an in-band way as you suggest, but then also had to add OOB signalling because Apple disallows open sockets for background apps.

ryukafalz 6y ago
> Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. Yep, it does, so you could do this; the problem for the Linux desktop is just that there isn't a standardized out-of-band push notification system yet. (I saw another commenter mention UnifiedPush, which sounds interesting - in any case it's not widely supported yet.) > As a side note, Jabber did add an in-band way as you suggest It's been a while since I looked into this in detail, but IIRC Jabber generally doesn't have a server-side way to determine which messages should notify? As I recall, the protocol was designed with smart clients and dumb servers in mind, though I'm sure some of that has changed over time - but that design decision doesn't lend itself as well to clients on battery-constrained devices. Although with that said, the fact that you aren't required to be in the same set of MUCs on every device helps in battery-constrained devices; for example I only stay joined to the rooms that my friends are in from my phone, unless I need to join another one temporarily.
- aidenn0 6y ago
  Re: jabber https://xmpp.org/extensions/xep-0352.html https://xmpp.org/extensions/xep-0352.html
  - ryukafalz 6y ago
    Client state indication helps for things like suppressing presence updates, but it doesn't go as far as to e.g. let you only be notified for messages that would highlight you in a large MUC, right? So either you're joined to the MUC and receive all messages in it, or you leave the MUC and don't get notified about any of them. Although now that I read the spec again, it seems general enough that maybe it could be used to implement behavior like that? I don't think I've seen any servers that do, though.
    - aidenn0 6y ago
      Prosody has an option for filtering MUC messages with mod_csi_battery_saver (which is the currently recommended community module for CSI), I don't think ejabberd does though. > groupchat messages must set a subject or have the user’s username or nickname mentioned in the messages (or be encrypted) to count as “important”.