[hollow-moe]

This is the goal, in the same way Google does for FCM: the Play Services maintain a connection with their servers to get the notifications and then send them to the different apps. Here's it's the same with a server you control and know it won't read whatever is in that notification, without draining the battery because there's only the Unified Push app maintaining the connection.

[GranPC]

> know it won't read whatever is in that notification,

Aren't notification contents E2E? The website is rather light on details.

[goku12]

Notifications don't appear to be E2EEed. They are encrypted in flight. But they do change formats while on the servers. For example, the application server contacts the push server using Web Push (like a webhook), but the communication from push server to the distributor app on the end device is using some other protocol like XMPP, Server send events or WebSockets. This obviously requires decryption.

But the encryption shouldn't be a big issue as @morith pointed out. The application server can send a notification to the end user application simply asking it to refresh. The second image on their home page (https://unifiedpush.org/) illustrates this.

[MattJ100]

Yeah, existing proprietary (e.g. Apple/Google) push notifications are not E2EE, so apps that need to convey sensitive information (secure messaging apps, etc.) tend to take this approach already regardless of push provider.

[moritzruth]

IIUC notification contents are application-defined. So if you're building a weather app and don't care about encryption, your content can literally be "It's going to be sunny." Signal, on the other hand, would only send "please refresh" and then it's the app's responsibility to act on it.