In preparation for daily driving #MobileLinux I've been thinking a lot about what must be done for reliable and power-efficient push notifications.
Spoiler alert: while UnifiedPush may be a relevant service for some apps, it's not where platform dev focus should be. We want a future full of p2p apps that reject permanently-addressable "servers" entirely, after all! And centralization is not where the bulk of the power-saving magic is anyway. The "magic" is in the fact that the SoC can be in deep sleep and the modem will still wake it up with an interrupt when data arrives on an open connection. It should be fine to have apps' own service processes listen for notifications!
My rough sketch of a to-do list would be:
making sure wakeups don't turn the display on xD
research into what's needed to set up filtering on the modem for which sockets can wake the SoC up (but initially, fine to just rely on "nothing else has open sockets anyway, only the background services waiting for pushes" maybe?)
support for robust background services: unlike what the Background portal offers now, let #Flatpak apps install systemd-user services, which would have metadata connecting them to the .desktop entry, making them introspectable and accountable via settings GUIs (not via control center popups! they shouldn't show up as "annoying left-over in-process thing possibly eating battery"! they're a different thing, expected to run permanently!)
actually getting apps to separate push notification listeners into background services
@valpackett > making sure wakeups don't turn the display on xD
That'll get us, like, 90% there usability-wise already 😜 AFAIR gnome-settings-daemon simply turns it on unconditionally on resume from system suspend.
