Here is a blog post to use the play services, without the proprietary lib and API: https://unifiedpush.org/news/20250131_push_for_decentralized...

And there is this gist for the app side, if you need something to share: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0a...

This is also what UnifiedPush lib to use FCM does (https://codeberg.org/UnifiedPush/android-embedded_fcm_distri...)

Which is documented in this gist: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0a...

That's already how it works, the 3rd app is usually the Google services. The setup described on the blog post allows user to use the Google services OR another service

If you are interested, you can read the specifications: https://unifiedpush.org/developers/spec/android/. The same question actually exists for firebase-messaging (Google) too (answer here: https://github.com/firebase/firebase-android-sdk/blob/cf5fe2...)

I'm not familiar with this stuff and don't have time to fully read the specs plus the required background reading. Here is my guess based on skimming the spec:

The application may embed the VAPID public key while the VAPID private key is kept secret by the app developer. That way only the app developer can send valid push notifications. This approach doesn't work when the app running on an untrusted device sends push notifications directly though?

I guess the trick is for the app to treat the push notification purely as a hint to go fetch the latest state from the app server. Do not trust anything in the push notification message. Then it doesn't matter whether the messages are spoofed.

You linked to some Android Intents code in the firebase-message code. I guess that is related to preventing Intent spoofing, but I'm not sure?

> But I think UnifiedPush or ntfy instructions should make these steps more clear (or I failed to find it), even if just to say "it's actually that easy" to save our time looking.

We are working on the documentation: https://codeberg.org/UnifiedPush/documentation/pulls/16

How mobile push notifications currently bring centralization to decentralized services, and how we can avoid it, even for mainstream configurations.

(As I said in a previous discussion about Firefox) I really wish it was possible to enable DRM for a single container.

For your information, your suggestion has been the solution https://github.com/deckerst/aves/pull/519

That's nice. I didn't expect my suggestion to be considered!

I'd love to be able to enable DRM for a single container. Until then, I have to continue with profiles.

From the blog post:

> One key feature of UnifiedPush is that the communication between the push server and the distributor is not specified. This means that a variety of technologies can be employed, such as WebSockets, Server-Sent Events, *XMPP*, raw TCP, or even SMS, whatever works best for the user.

Sigh. What you miss is that this protocol introduces nothing that already isn't done by XMPP push notifications. It is decentralized, it can deliver to different endpoints, etc. You only need to create a dispatcher app that will relay the notifications to third party apps. Again, this too was done years ago.

> You only need to create a dispatcher app that will relay the notifications to third party apps.

That part is what specify UnifiedPush. It does not specify the communication between the push server and the distributor.

So what! Few use that. I host a prosody server with lots of plugins and it never occurred to me to use it, let alone use cases outside if the XMPP ecosystem. Can the XMPP implementation fall back to google's push system. Does it have a blog entry, lovely diagrams, comprehensive docs, a nice on-boarding experience for developers? Ideas aren't worth much, implementation--getting things done is what matters.