Comment by dmw_ng
2 years ago
Not least for the sake of power management, the central push provider needs to authenticate (and e.g. rate limit) notifications to a particular device. The identities of apps communicating with a particular device therefore seem to need to be known
This still seems like something that could be fixed with smarter design without losing functionality.. e.g. decoupling device registrations from push channels, and treating the push channel ID a particular device is using as toxic for sharing and intermingling as other kinds of personal identifiers like phone numbers, including with the OS provider itself, or creating a unique push channel ID for every app registration, etc.
This is actually a bummer.
P2P mobile applications cannot wake themselves up to sync with peers (short of relying on exploits).
The same is true of browser service workers.
The architectures I’ve explored for mobile and web based P2P apps, they’ve all needed a central trusted push notification server fallback to wake up the process so it can check for messages.
Even then the APIs will fight you.
Unless the fallback server syncs for you, it can only wake you up on an interval. It can’t know if there is a notification worthy event for you to sync.
If you wake up the process and there are no messages from its peers that generate a notification, you “consume” some of your background notification budget.
Consume too much and the system stops waking your app on push events, so you stop syncing in the background.
There are apps, like WhatsApp on iOS, that receive silent notifications and are started upon receiving them, allowing them to process these notifications locally (as explained in my other comment in this thread).
This method enables them to bypass the need for sending clear text content through Apple's servers, upholding their end-to-end encryption.
However, this practice can slightly impact battery consumption, which is probably why this specific entitlement is not freely available to all apps. It's a balance between enhanced security and a marginal increase in battery usage.
I see power management mentioned often, but I'm not convinced. How does centralizing the push service reduce power? Why can't a developer just implement the service in the same way? (if Apple/Google let them)
I self-host Gotify, which just uses a websocket for the push part, and battery consumption is only 2%/day even with the app white listed from "optimization"