Mastodawn

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?)
easy API for establishing the push connection specifically over mobile data if available (since only modem supports wakeup well rn)
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

#postmarketOS #linuxmobile #freedesktop

Show thread

Adrian Vovk 1d ago

@valpackett part of the issue is trusting apps to keep their power usage low. Like sure, we could have dedicated low power backgroud services for apps. But how do we ensure that the app isn't going to be doing large amounts of work in the background for no reason (i.e. due to a bug)? CPU usage limits?

What we could do is allow apps to hand over a copy of the file descriptors to their open network connections. Then we can keep track of activity in the OS and wake the app when needed.

(1/2)

Show thread

Adrian Vovk

@valpackett Alternatively, we're already exploring OS-level p2p infrastructure over in @modal. We could have traditional style push notifications from the perspective of apps, but the backend could be a peer to peer service running outside the app sandbox.

The OS service would be responsible for transporting messages between apps (across devices!), so p2p-native apps will natively be going through the OS and we can make every p2p message optionally become a push notification

(2/2)

Show thread

Val Packett 🧉1d ago

@AdrianVovk yes, everything from @modal is the reason I kinda ranted against focusing on server-based services :) Sure, actually having that handled in the session-level service would be nice.

I think background services are very necessary either way, for music playback, VPNs, whatever else. And yes the service manager can enforce limits, and do usage accounting that would be reported in gnome-control-center.

I have thought about the "pass file descriptor" thing, that's one of the first things that comes to mind but— what happens when the socket becomes readable? Just "wake the app" that still has the same socket open— well, this is just regular background activity with extra steps, just to be careful about apps' CPU time, which sounds kinda "meh" to me

Show thread

Adrian Vovk 1d ago

@valpackett oh we totally need background services for other things. But those other usecases is kinda the reason I'd be hesitant to just let apps roam wild. We've found it helpful to stick to concrete purpose-built APIs than trying to address things with a general solution. An escape to systemd --user services might be in the cards but IMO that's only as a highly privileged sandbox escape. Not even because we can't sandbox these services, but because we don't know what it's being used for (1/2)

Show thread

Adrian Vovk 23h ago

@valpackett As for FDs, it seems easier to set a one shot CPU limit than trying to keep track of usage over time. In other words, "the push notification adds N seconds to your app's execution time budget and once you're out you're out" is easier (both conceptually and in terms of implementation) than trying to tune some complex resource restriction that applies continuously. It also seems to fit better with a "Doze" like model where we wake apps periodically to let them do background work (2/2)