This F-Droid blog post advocates for UnifiedPush, a decentralized, open-source alternative to Google's proprietary Firebase Cloud Messaging push notification system. The content explicitly frames centralized, proprietary notification services as privacy threats and presents UnifiedPush as enabling user control, independence, and privacy protection through architectural decentralization and multiple implementation options. The post demonstrates strong positive alignment with UDHR Article 12 (privacy), and moderate positive alignment with articles supporting digital liberty (Article 3), free expression (Article 19), education access (Article 26), collaborative scientific progress (Article 27), and rights-protective social order (Article 28).
With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP.
UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, that anyone can self-host or any OS can provide without compatibility issues. It does require small adjustments server-side and client-side for applications assuming Google services.
>However, if each app actively maintains a server connection, the OS cannot suspend them.
This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.) This works on Linux if you don't have the extra Android crap getting in the way.
It's kind of a bummer to see bad OS architecture feed into over-complicated protocol/application design.
EDIT: I guess I wasn't clear here. In my experiments I had the background wake up service wake the device up once and applications had just that singular window for all of them to service their connections. The problem with Android is instead applications either keep the phone from suspending entirely or (apparently) have some API allowing them to register their own periodic wake up that isn't shared.
EDIT2: I also want to be clear that this isn't a criticism of NTFY. The developers behind it deserve congratulations for solving a serious problem with FOSS Android apps. My complaint is that the poor architecture and unescisary inflexibility of Android made this such a complex problem in the first place.
Why use a new custom-built protocol instead of adding support for the Web Push protocol already supported by Firefox, Chrome, Safari and others? https://web.dev/push-notifications-web-push-protocol/. Now backend developers have Yet Another Push Notifications Protocol to build support for, instead of being able to just easily plug into their existing code. As a benefit, since all notifications through the Web Push protocol are end-to-end encrypted, there's no concern about "trusting" the distributing server like there seems to be in this protocol (based on https://unifiedpush.org/spec/server/)
The headline got my attention. I'm looking for a standard for subscribeable notifications / callbacks to update users of data changes in an API. Bonus point for federated. But server to server, not server to client. Double bonus points for connecting to consumer services like Zapier or IFTTT.
I'm planning to use WebSub and/or RSS, but on the look out for others. Any pointers?
Off-topic: Sometimes I work on ships that have Wi-Fi for talking to local services, but due to strict metering, Internet access is usually disabled. So most of the time there's no way to get notifications from monitoring systems and your fellow crew, let alone shoreside team members.
It would be nice to have a solution for delivering pushes internally, and also hold open a best-effort connection to a remote server that allows some notifications through.
The last solution I considered was running a Matrix homeserver on the ship with some local channels, and another instance on shore, and using federation to connect them when the uplink is available. Monitoring systems could send their alerts as DMs or to a shared channel.
Then for the notifications, Apple has its Local Push Connectivity API you might be able to use to send notifications within the ship network. I'm not sure if this UnifiedPush would solve the problem on Android. Either way, though, it seems like a lot of engineering effort just for a chatroom.
AFAIK Modern Android (>= 8.0) reserves the right to kill your app when running in the background unless there's a foreground toast bound (even then, can still be killed in low memory situations). How does this solution work around that? Is there a need to opt into the legacy "battery saver disabled" mode for the app which more closely mirrors <= 7.0 execution model?
Apps draining your battery to check for notifications is the worst thing about degoogled Android. With notifications enabled my telegram client can drain my battery in a very low number of hours (got suggestions here? any client supporting UnifiedPush?)
So this is welcome, but it requires application support. And if apps on your phone use both GCM and UnifiedPush you still end up with multiple providers. But at least I think I can trust UnifiedPush to be light on my battery.
I'm using Google Firebase Cloud Messaging [0] which allows pushing notifications to devices even if they're asleep, unlike local notification services where the device must be awake and the app must be active.
Will this service allow the same thing FCM does, including waking up the device? I'm looking at both iOS and Android devices, I see there's Flutter available but not iOS necessarily in the docs [1]. Related question, will the Flutter version also work for iOS devices? I know FCM (and its Flutter SDK) works for both, as well as web.
Interesting. This could have interest from China, since they have to use Android without the Google push service, causing battery drain issues. They are trying to come up with their own push notification service.
Please don’t get me wrong but I wonder what is the use case for this. First of all this tries to solve a problem that has already been solved by the mobile device OS layer within IOS and Android and furthermore is only working for Android. Why should anyone use this?
Thanks for your great work creating this protocol. Hope more app developers add support for it, especially for privacy focused apps like Signal which by relying on Google servers are leaking metadata.
You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections open.
I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level.
Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.
I would think that in order to not have an obvious negative impact on battery life, it would be necessary for the OS to coalesce app notification service keepalives, performing them in scheduled batches instead of the moment an app requests one. That should be roughly equal to the current situation with APNS/GCN, where the OS can schedule network maintenance during periods where the device and antenna(s) are likely to be awake already.
> you can periodically wake up for a short period and allow apps to service their connections
For this to work, you need apps to somehow conform to a standard timing and respond to a signal that says "hey, the OS is awake for you to do network things". Now each developer needs to implement some special code that understands the situation. After a while, all the devs start using libSleepyNetwork because getting those details right is hard. The libSleepyNetwork people realize that they can use a system daemon to further coalesce work for greater efficiency (one event loop is better than N event loops), so now all the consumer program C APIs are now backed by IPCs to the daemon.
This is exactly what's already happened on Android, except libSleepyNetwork is implemented by either Google, or these people. I don't think it's bad OS design at all. It's chasing efficiency via abstraction that encapsulates some complex coordination.
> This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.)
The protocol does not specify how the distributor and push server communicate or keep a connection going. It's up to them to define an energy efficient way to do that. For ntfy [1], a single WebSocket or JSON stream connection is used to deliver messages to the device. This is very energy efficient and consumes <1% of battery on most phones.
As for regular wakeups (for polling), Android does not allow periodic work to be done more frequently than every 15 minutes, which is obviously not frequent enough to be useful.
> It's kind of a bummer to see bad OS architecture feed into over-complicated protocol/application design.
This is somewhat true. The restrictive Android eco-system is what led to the creation of UnifiedPush, but it's far from complicated IMHO
Disclaimer: I am the maintainer of ntfy [1], one of the UnifiedPush distributors.
Congrats! It's always surprised me that Amazon or one of the other Android vendors didn't do this themselves to make porting to FireOS or other services-included Android distributions easier, but I hope you get funding from them for doing their job for them.
UnifiedPush is compatible with WebPush: both just involve an HTTP POST to a specific URL. If your application server supports WebPush, it can send encrypted notifications to UnifiedPush servers (that is how we're planning to support Telegram, for example). You can then decrypt these notifications in the app [1]. However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix respectively. There, encryption is unnecessary complexity.
However, we don't use the WebPush API between the push server and distributor since there is a lot of scope for innovation in that space (for example Google's FCM uses a custom XMPP based protocol).
this is NOT a limitation of Android. Android has supported wakelock based notification managers for a long time. And FCM works pretty much the same as was mentioned in the OP. The FCM manager maintains one long polled connection to Google notification servers and every other app subscribes to wakelocks from that manager.
Your app is only woken up by the OS if FCM receives a notification for you. For e.g. Xiaomi will not wake you up even if you get a notification, unless you're on a white list (the much glorified Xiaomi whitelist).
When Android is put in power saving mode, the FCM manager optimized this even further.
Doesn’t Apple and Google on the OS level only allow push notifications to come from its own services? Like, they look for the signature to be compatible with https certificate etc. Otherwise the phone could have a ton of push notifications incoming from anywhere on the Internet. The APN service for instance would only route notifications to a phone if it came from a registered website. How do you get around this?
As far as I know, even for VOIP permissions, iOS only wakes your code up if ITS APNS SERVICE sends the notification. How are you able to install a long-lived application in the background on iOS?
Similarly, the phone radio is listening for calls from the nearby cell towers in the network, not from absolutely any tower. I guess a Stingray can impersonate one, but they would probably need to fake the attestation, right?
One of the first uses of UnifiedPush was to self-host the whole Matrix messaging stack. In fact, we have already had someone in the UnifiedPush chat set this up on their ship [1]. Matrix + UnifiedPush would be perfect for a disconnected situation on ships (or Mars colonies :)
ntfy [1] would work for you entirely in the LAN, if you self-host the server and the phones are connected to the same Wifi. It'll only work for Android phones though, since iOS forces APNS for push notifications.
ntfy is also a distributor for UnifiedPush, so you're not entirely off topic here. Hehe.
WebSub + RSS/Atom is a good option for relatively slowly changing data. (Maybe at most a couple of times an hour). It is nice because it is opt-in and an enhancement on the regular polling API.
Using WebSub or UnifiedPush would technically very similar but you need a way for the client to pass you the subscription information. WebSub has a standard discovery process to manage this.
Most distributors both show a foreground notification at all times and require exempting them from battery optimization. Because of its efficient design, something like ntfy only uses a few percent of battery per day [1].
System-level integration into Android ROMs would eliminate the need for those things.
You can self host a Gotify server (single file executable, web interface), install the app, set it to connect to the server on the local network. Sending a message is as easy as a curl to the server. It will show up in the apps.
> It would be nice to have a solution for delivering pushes internally, and also hold open a best-effort connection to a remote server that allows some notifications through.
Yes, this is an FCM replacement on Android (and it can easily fall back to FCM if the user doesn't have UnifiedPush). There is no native UnifiedPush on iOS because Apple doesn't allow background services. The server side to support both is simple, but on the client you would need code for both FCM (for iOS) and UP (for Android). It would be interesting to build an FCM wrapper for iOS into the UP Flutter library.
I have been working and running ntfy [1] on my phone for a year now (ntfy is a UnifiedPush distributor), and it is true that Android does kill the app every now and then. But it is instantly restarted. Usually ntfy delivers notifications much much much faster than Google's FCM, especially in doze mode. FCM seems to try and conserve battery much more.
In addition to what the others wrote (a local Matrix server and UnifiedPush provider such as ntfy would work fine), I suggest you look into p2p messaging systems such as Briar. I think Tox is also p2p?
Lastly, Secure Scuttlebutt was actually designed on a boat for sporadic internet connection and local connections, as well as sneakernet, so that would work too, but I don't think it's designed for IM. Perfect for blogs or facebook-like stuff though.
Have a member of the crew go onshore up to a Wi-Fi AP, it will act as an async data transfer for everyone. You can also exhange data with other travellers, including passing boats.
Interestingly, there are a few Matrix p2p experiments. I wish apple opened their Airdrop feature as that would make proximity networking easier, though that should be achievable with Wi-Fi NAN+P2P.
the main issue isn't with the foss apps though. Those usually support polling. The actual problem is with other proprietary spyware apps that you're forced to use but they are locking you in with google's FCM. Until there's an easy way to patch those apps we can't really solve this problem
It looks like this aims to be a replacement for people want to use an Android-based OS but don't want to rely on Google services, normally for reasons of philosophical objection to big tech's de facto surveillance capabilities. So presumably users of GrapheneOS, CalyxOS, LineageOS, etc.
Also since Google is blocked in China, Firebase Cloud Messaging doesn't work there. Android has something like a 75% market share in that market. Some vendors have their own offerings (e.g. Xiaomi MiPush, Huawei PushKit) etc, I could buy that a popular centralised solution would be more attractive than doing N integrations.
That's an interesting thought, but currently the Server-Server specification is quite trivial, the more complicated part is the Android (and Linux) API, which I don't think the W3C would cover.
There's definitely room for adoption within the freedesktop.org umbrella for the Linux part, once this part is a bit more mature.
Editorial Channel
What the content says
+0.80
Article 12Privacy
High Advocacy Framing
Editorial
+0.80
SETL
+0.69
Privacy is explicit and central throughout. Content explicitly identifies privacy concerns with Google's proprietary Firebase Cloud Messaging and advocates UnifiedPush as privacy-respecting alternative. Architecture designed to enable user control and prevent corporate surveillance.
Observable Facts
Post explicitly states: 'Relying on Google-provided push notifications is a concern for both privacy and independence.'
Post explains proprietary Firebase 'relies on having Google services' and cannot be included in F-Droid apps, presenting privacy incompatibility.
UnifiedPush enables users to 'self-host the server part' or 'create your own' distributor, enabling individual control over notification infrastructure and data.
Inferences
Detailed discussion of privacy concerns with centralized services and promotion of privacy-preserving alternatives demonstrates strong commitment to Article 12 protections.
Architectural design enabling user control and choice reflects intent to prevent corporate surveillance and unauthorized data interference.
+0.30
Article 27Cultural Participation
Medium Advocacy Practice
Editorial
+0.30
SETL
+0.17
Content advocates for open-source development and community participation in technological progress, presenting UnifiedPush as a collaborative specification that enables distributed implementation.
Observable Facts
Post invites developers: 'If you need help with implementing UnifiedPush in your app, we are happy to answer any questions you have on our Matrix chat.'
Post describes UnifiedPush as 'a specification' that can be implemented by multiple parties, enabling community participation.
Post references 'client libraries' and 'reference proxies' as tools for developers to contribute to and extend technological development.
Inferences
Open specification model and invitation for community implementation demonstrates commitment to collaborative scientific and technological progress.
+0.20
PreamblePreamble
Medium Framing
Editorial
+0.20
SETL
ND
Content emphasizes values of freedom, dignity, and independence from corporate control. Frames user autonomy and choice as foundational values.
Observable Facts
Post emphasizes 'freedom from being tied to a single company' as key motivation for UnifiedPush development.
Content consistently frames user autonomy and choice as fundamental values underlying the project.
Inferences
Emphasis on independence and freedom from corporate lock-in aligns with preamble values of human dignity and liberty.
+0.20
Article 3Life, Liberty, Security
Medium Advocacy
Editorial
+0.20
SETL
ND
Content advocates for user liberty and autonomy by identifying centralized service dependence as constraint on independence and presenting user choice as enabling exercise of liberty.
Observable Facts
Post states that relying on Google services raises 'concern for both privacy and independence.'
Post emphasizes users can 'choose which distributor you want to use, self-host the server part, or even create your own.'
Inferences
Repeated emphasis on user choice and freedom from lock-in positions personal autonomy and digital liberty as protected interests.
+0.20
Article 19Freedom of Expression
Medium Framing
Editorial
+0.20
SETL
ND
Content frames decentralized infrastructure as enabling free expression by preventing any single entity from controlling or filtering communication channels.
Observable Facts
Post proposes decentralized infrastructure that is 'not tied to a single company.'
Multiple compatible distributors prevent any single entity from controlling the communication channel.
Inferences
Decentralized design prevents centralized control of communication infrastructure, which could otherwise enable censorship or suppression of expression.
+0.20
Article 26Education
Medium Practice
Editorial
+0.20
SETL
0.00
Content provides comprehensive educational material for both users and developers, enabling understanding and adoption of privacy-respecting technology. Step-by-step instructions and development guidance support informed participation.
Observable Facts
Post contains detailed user installation instructions: 'Install the ntfy Android application; this is your distributor. Open it, and disable battery optimization for it.'
Post provides 'How to add UnifiedPush support to my app, as a developer?' section with technical implementation guidance.
Post references 'detailed instructions on our documentation website' and community support via Matrix chat for assistance.
Inferences
Comprehensive educational approach enables users and developers to understand and adopt privacy-respecting technology through multiple learning resources.
+0.20
Article 28Social & International Order
Medium Advocacy Framing
Editorial
+0.20
SETL
+0.14
Content advocates for decentralized infrastructure as a better social and technological order, proposing that rights are better protected through distributed systems that prevent corporate monopoly.
Observable Facts
Post proposes UnifiedPush as 'a new alternative that allows you to get push notifications without being tied to a single company.'
Post describes decentralized system with multiple compatible implementation options, preventing any single entity from controlling infrastructure.
Inferences
Emphasis on decentralized infrastructure as solution to corporate monopoly suggests vision of technological order built around user rights and independence.
+0.10
Article 17Property
Low Framing
Editorial
+0.10
SETL
ND
Content enables users to own and control notification infrastructure through self-hosting, relating to property rights and control of digital resources.
Observable Facts
Users can 'self-host the server part' of UnifiedPush infrastructure according to the post.
Post describes ability for users to have control over 'their own' distributor.
Inferences
Self-hosting capabilities enable users to maintain ownership and control over their notification infrastructure and data.
+0.10
Article 20Assembly & Association
Low Framing
Editorial
+0.10
SETL
ND
Content frames open specification and compatibility standards as preventing gatekeeping of participation in notification systems, enabling free association.
Observable Facts
Post emphasizes that 'any' app or distributor can implement UnifiedPush, preventing gatekeeping by a single entity.
Inferences
Open specification prevents a single entity from controlling who can participate in the notification system.
+0.10
Article 24Rest & Leisure
Low Framing
Editorial
+0.10
SETL
ND
Content discusses battery efficiency and resource conservation, relating to device usability and quality of life beyond constant technological demands.
Observable Facts
Post explains that multiple direct connections 'can drain the device's battery faster' and that UnifiedPush reduces this resource consumption.
Inferences
Improving battery life and reducing device strain relates to quality of life and freedom from continuous technological demands.
ND
Article 1Freedom, Equality, Brotherhood
ND
Article 2Non-Discrimination
ND
Article 4No Slavery
ND
Article 5No Torture
ND
Article 6Legal Personhood
ND
Article 7Equality Before Law
ND
Article 8Right to Remedy
ND
Article 9No Arbitrary Detention
ND
Article 10Fair Hearing
ND
Article 11Presumption of Innocence
ND
Article 13Freedom of Movement
ND
Article 14Asylum
ND
Article 15Nationality
ND
Article 16Marriage & Family
ND
Article 18Freedom of Thought
ND
Article 21Political Participation
ND
Article 22Social Security
ND
Article 23Work & Equal Pay
ND
Article 25Standard of Living
ND
Article 29Duties to Community
ND
Article 30No Destruction of Rights
Structural Channel
What the site does
+0.20
Article 12Privacy
High Advocacy Framing
Structural
+0.20
Context Modifier
ND
SETL
+0.69
Page is publicly accessible without login or tracking mechanisms; privacy-respecting content presented transparently with links to documentation and community support enabling informed participation.
+0.20
Article 26Education
Medium Practice
Structural
+0.20
Context Modifier
ND
SETL
0.00
Page structure designed to educate through clear explanations, step-by-step instructions, and links to comprehensive documentation and community support channels.
+0.20
Article 27Cultural Participation
Medium Advocacy Practice
Structural
+0.20
Context Modifier
ND
SETL
+0.17
Page structure enables participation through linked documentation, code libraries, and active community discussion channels, supporting collaborative development ecosystem.
+0.10
Article 28Social & International Order
Medium Advocacy Framing
Structural
+0.10
Context Modifier
ND
SETL
+0.14
Page structure enables participation in decentralized systems by linking to multiple distributor options and providing implementation guidance.
ND
PreamblePreamble
Medium Framing
Content emphasizes values of freedom, dignity, and independence from corporate control. Frames user autonomy and choice as foundational values.
ND
Article 1Freedom, Equality, Brotherhood
ND
Article 2Non-Discrimination
ND
Article 3Life, Liberty, Security
Medium Advocacy
Content advocates for user liberty and autonomy by identifying centralized service dependence as constraint on independence and presenting user choice as enabling exercise of liberty.
ND
Article 4No Slavery
ND
Article 5No Torture
ND
Article 6Legal Personhood
ND
Article 7Equality Before Law
ND
Article 8Right to Remedy
ND
Article 9No Arbitrary Detention
ND
Article 10Fair Hearing
ND
Article 11Presumption of Innocence
ND
Article 13Freedom of Movement
ND
Article 14Asylum
ND
Article 15Nationality
ND
Article 16Marriage & Family
ND
Article 17Property
Low Framing
Content enables users to own and control notification infrastructure through self-hosting, relating to property rights and control of digital resources.
ND
Article 18Freedom of Thought
ND
Article 19Freedom of Expression
Medium Framing
Content frames decentralized infrastructure as enabling free expression by preventing any single entity from controlling or filtering communication channels.
ND
Article 20Assembly & Association
Low Framing
Content frames open specification and compatibility standards as preventing gatekeeping of participation in notification systems, enabling free association.
ND
Article 21Political Participation
ND
Article 22Social Security
ND
Article 23Work & Equal Pay
ND
Article 24Rest & Leisure
Low Framing
Content discusses battery efficiency and resource conservation, relating to device usability and quality of life beyond constant technological demands.
ND
Article 25Standard of Living
ND
Article 29Duties to Community
ND
Article 30No Destruction of Rights
Supplementary Signals
Epistemic Quality
0.64
Propaganda Flags
0techniques detected
Solution Orientation
No data
Emotional Tone
No data
Stakeholder Voice
No data
Temporal Framing
No data
Geographic Scope
No data
Complexity
No data
Transparency
No data
Event Timeline
4 events
2026-02-26 12:20
dlq
Dead-lettered after 1 attempts: UnifiedPush: A decentralized, open-source push notification protocol