[mjl-]

If I understand the notifications flow correctly: a device (typically mobile phone) will get a "registration" with a "push url" from its platform/provider (eg android/google or iphone/apple), which it hands to an application server (eg IMAP server), which then uses that to send notifications to the push url, "authenticating" with vapid. And due to vapid, no special account/preregistration is required for the application server to talk to the provider, hence decentralized (good!). The platform/provider behind the push url makes the notification appear at the device. It is quite a complicated way to get a message from server to device...

The post says it is about Android. But I'm online searches turns up documents about VAPID at apple/ios. Will it work there too? What about other platforms (eg non-google android-likes)?

[cyberax]

Android is very simple. All their notifications are internally supported by a TCP connection to a Firebase endpoint. So when you need to send a notification, you ping the central (and Google-controlled) Firebase endpoint with a device ID. Firebase then pushes a message over the TCP connection that is permanently open between the phone and the Firebase.

On the phone, the Play Services are exempted from the battery optimizations, so the socket connection stays up. And once a notification is received, Play Services unmarshall it, and route it to the correct application ("activity"), possibly waking it up.

From the notifier's side, you need to have the credentials for Firebase interaction and the device's token (that Google Play Services make available to the application during the notification setup).

iOS works in an exactly similar fashion, except that the endpoint is controlled by Apple. To send it, you need to set up an "APN".