Having each app run in the background and manage its own notifications can work, but also causes battery life issues with more apps.

I mean, if you just have a select() command blocking, I don't see why having a 100 sockets open would be any different than 1 socket.

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.

> 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.

> 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.

Re: jabber

https://xmpp.org/extensions/xep-0352.html

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.

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”.

You need to keep the connection alive, which means regular traffic, which means regularly sending data, which needs energy. More connections mean a) more traffic and b) unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself.

> unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself.

You just need to coalesce timer wakeups, which Linux supports already at the kernel level AFAICT.

I see, we need some coordination mechanism, and at that point, why not just use a central server to manage notifications :)

The radio is a massive battery draw, so you want it to be off as much as possible. The built-in push notification service will batch low priority packets and send them all alongside the next high priority one it receives.