Back in 2020, “OpenPush - A Free, Decentralized Push Messaging Framework for Android” has been announced on F-Droid at its beginning, and in 2022 the UnifiedPush team posted on F-Droid their guide entitled “UnifiedPush: a decentralized, open-source push notification protocol” that inspired a lot of developers. But did you know how UP came to be? Now you can. This is a repost from the author blog.It has already been 5 years since UnifiedPush started! It also means I don’t have any Play Services, the official or microG reimplementation, for 5 years now. It is a good moment to do a recap, and think about what can be UnifiedPush in 5 years.It turns out I don’t remember in details how all started, I need to readsome historical pull requests and chats.Why do I need push notifications?I think I’ve installed my first alternative ROM,LineageOS, around 2013, and never went back tostock ROMs since then. At this time, I didn’t really care about the apps Iwas installing, it was mainly to take control of my devices and get rid ofthe bloatwares.I understood that I needed the Play Services, or a reimplementation, forsome applications to properly work, and I was vaguely knowing why. So, everytime I updated my phone, I had to boot into the custom recovery (TWRP), toflash a zip, to get microG. It was, well .. not the best user experience.Then, I tried to stay without the Play Services, it was even worse, messagesweren’t reliable, the battery drained and there were many foregroundnotifications, which I understood were required to keep a service running.So I decided to go with a fork of LineageOS that includes microG by default,and distributed by microG team: LineageOS formicroG.Even after using this new system, the experience was nearly the same. Why?Because most of my apps were from F-Droid. Push notifications with Google(via microG) require the use of a proprietary library *, which comes withtelemetry, unless explicitly configured to exclude them. F-Droid deny thislibrary, which is fair given that their purpose is to promote free software.* That’s actually possible to use FCM (Google notifs) without Google lib,but I didn’t know that at this moment. Cf. UnifiedPush blog post about pushnotifications for decentralizedapplications,or Molly issue regarding FOSS FCMimplementation.Gotify (2020)So, we’re in 2020, and I finally want to look why I can’t use microG withFedilab and Element from F-Droid, and if we can replace microG with anothernotification app.It turns out among others notification applications, F-Droid distributesGotify. It isn’t able to forward notifications toother apps, but there is an issue opened for thatfeature, and jmattheis,the developer seems open to the idea.I didn’t touch any Android dev at this moment, but I tried to hacksomething. Fortunately, jmattheis review helped a lot to make thingsless hacky. So here came gotify-connector.It looks like from the pull request history that “connector” comes fromjmattheis, for which I added “distributor” later.At this moment, the feature has picked the interest of some persons,including sorunome, karmanyaahm and sparchatus. Sorunome,contributor to FluffyChat, told me that the feature may interest people inOpenPush Matrix room.First UnifiedPush version (2020)Late 2020, looking at some p2p projects, I thought it would be cool having ap2p based solution too. So came the questions about ecosystem lock-in of aGotify only solution, adoption, and fragmentation. If we have multipleapplications able to provide push notifications, we should have a librarythat is compatible with all of them. When a new application providing pushnotifications is published, then all existing applications supporting thething would be directly compatible. Going that way, we needed to specifyhow it should work first.I shared the idea in OpenPush room, and it picked the interest of someone inparticular, sparchatus, who helped me to write the specifications. Wediscussed many edge cases to see how things could be.I published a first version of the specifications, a library, and a fork ofGotify until the support was merged *.Sorunome was interested in implementing the support in Fluffychat. It required a flutter lib, karmanyaahm wrote a lib porting the already published library to the framework. We also needed something to translate Matrix push protocol, and make Gotify server compatible: karmanyaahm wrote common-proxies for this.* Which actually never happened 🤷FluffyChat, Fedilab, and more (2021)Early 2021, FluffyChat was supportingUnifiedPush. And soon came Fedilab too, as the dev,Thomas, was directly interested.Starting with these 2 applications was a chance for the project: we hadsupport for Matrix, and many other chats using Matrix bridges, and for theFediverse. This covered enough applications for some FOSSenthusiasts. Retrospectively, UnifiedPush may never have started withoutthese 2 applications.After that, some applications started to implement the feature, such as aTox application, orFMD, a FOSS solution to find your device.Mid 2021, I implemented UnifiedPush support forElement, which was soonmerged bySchildiChat, afork. I think the experience from SchildiChat helped for it being mergedinto Element mid 2022.UnifiedPush for Linux (mid 2021)At this moment, vurpo came to UnifiedPush Matrix room to talk about pushnotifications for Linux devices. So we had UnifiedPush for Linux bymirroring the specifications for Android to D-Bus IPC.ntfy, NextPush (2021)During 2021, a new project appeared on the Internet:ntfy. A project like Gotify, that can work without anyaccount, with a public server. The app is extremely easy to use, as you havenothing to set up. And the developer, binwiederhier, was directlyinterested in supporting UnifiedPush, to make ntfy a distributor.Merged early 2022, it was an important step for UnifiedPush: we have adistributor to recommend by default.I have also implementedNextPush at the sameperiod, giving an easy opportunity to self-host a push server, if youalready host a Nextcloud serverIn the same time, Gotify developer informed us that they finally prefer notto merge the support, as they don’t use it and prefer to avoid addingmaintenance to their project, which is perfectly understandable. With thisnew position, the official support of UnifiedPush by ntfy, and the newNextPush app, I preferred to discontinued Gotify forks as well.KUnifiedPush (mid 2022)Mid 2022, the KDE team, and particularly vkrause,published KUnifiedPush: adistributor for Linux, compatible with different push server, like ntfy orNextPush. Until then, we only had POC implementations of distributors forLinux. KUnifiedPush also provide libraries for KDE applications.This allowed Linux applications to finally support the protocol.Full-time on UnifiedPush (2024 - 2025)At the end of 2023, we have more than 20 applications supportingUnifiedPush, and another distributor:Conversations. Element beingprobably the one with the larger user base at this moment. Someone advisedme to apply for a grant with NLnet, as it would boostdevelopment of the project.During the application process with NLnet, COVESAreached me because they wanted to support the project, but needed a fewfeatures that weren’t present, to get a more robust authorization mechanismand avoid registration spamming.UnifiedPush has always been compatible with web push (RFC8030 and RFC8291but RFC8292, aka VAPID, wasn’t). Embracing the standard to require web pushwas a potential step to take. The specifications needed to be updated inthat direction, to require encryption (RFC8291) and to handle authorizationswith VAPID (RFC8292). Relying on standard will hopefully help for theadoption, as the server side implementation may be used for web applicationsin the same time.At the end of 2024, I’ve started working full-time on UnifiedPush.Working with COVESA also allowed to getSunup, a distributor using Mozilla’spush server, autopush,and to add a self-hostable backend for autopush. This feature is currentlybeing merged.NLnet gave the opportunity to polish many things that were pending, to add amigration feature to the protocol, which can be used to get a fallbackservice when your self-hosted server is down, to implement the actual webpush specifications on Mastodon, and to add web push/UnifiedPush to someapplications. It includes Fennec/IronFox, forks of Firefox, so we can nowget push notifications with web applications. It also includes SimpleX(being merged), Nextcloud (being merged), DeltaChat (TODO), and flatline(TODO), a self-hostable version of Signal server, hopefully upstreamed toSignal servers.The idea is to increase the network effect: the more applications supportUnifiedPush, the more UnifiedPush can be relevant for users, and the moreusers will use UnifiedPush. If the number of UnifiedPush users increases, itpushes applications’ developers to support the protocol. At the end, we canuse our phone with the push service we want, to get an expected userexperience even without the Play Services.RetrospectiveIt was by chance that I started UnifiedPush and the project would never haveexisted without other projects like F-Droid, Gotify, Matrix, Fluffychat orFedilab, and many more, without the help of many people.I think it shows how the FOSS ecosystem can be beneficial for everyone. Idevelop Sunup, but often contribute to ntfy. The projects could be seen as“concurrent”, but aren’t: the applications answer different needs. We don’thave anything to win or lose if a user chose one app over the other. But weall win if a user chose to use one, no matter which, as it increases thenetwork effect.If UnifiedPush wasn’t started 5 years ago, I’m sure an equivalent projectwould have started since then. This is something that was awaited in themobile FOSS community, and there were already some research work on thesubject.I wasn’t aware how many things were implied with push notifications. It isunderstandable that giving a single entity the capacity to provide such animportant feature give them incredible power. This is concerning when theirsolution doesn’t follow least-privilege policies, come with system rights,has access to the full system, and with “features” we don’t want, such asadvertisement and telemetry.I now understand why push servers may be a tool for mass surveillance andhow an open solution is important for resilience. Some networks existoutside the Internet, some regions in the world suffer from services block,some users may be banned from these services. When a service is controlledby a single entity, nothing can be done when they consider your device tooold to be supported. Offering an open alternative is a response to all theseproblems.The idea is not to move everyone to an open solution, but to give thefreedom to. Supporting these alternatives also reduces risks of power abusefrom Google. If you develop an application, ask yourself how fast could yourecover from being banned by Google?Working full-time on UnifiedPush is incredible. I’m extremely happy afoundation like NLnet exists. I hope my work is beneficial for the projectand for most of the users. When it all started, I didn’t imagine a second Icould work on this, I just wanted my Matrix and Mastodon notificationswithout the Play Services.I would love to continue working daily on UnifiedPush, and there areprobably tons of things to do, specially for Linux devices, and many apps toport the feature to. But NLnet funds aren’t unlimited, our main goals arereached - improving the protocol, improving the existing code anddocumentation, boosting the network effect on Android -, and I don’t want totake the potential place of another project.Among other things, we still need to improve libraries for UnifiedPush onLinux, and it’d be great to have a UI for KUnifiedPush to publish it onFlatpak. There are some important applications, such as Mozilla syncservice, that use an allow-list of authorized push servers, defeating thepurpose of self-hosting: it would be great implementing a better anti-SSRFmechanism. We will probably have to build these blocks and otherstogether. If you want to contribute, do not hesitate to PM onMastodon or join UnifiedPush matrixroom.UnifiedPush in 5 yearsThe best thing that could happen to UnifiedPush on Android in 5 years wouldbe for it to no longer exist.If Android gives us a system API to let the user define their push servicewe wouldn’t need UnifedPush anymore. Passkeys (API to login withoutpasswords), used to be provided by the Play Services only. Today, probablyto increase the adoption, Android has migrated to a system API (CredentialProvider),to allow any password manager to provide the service. With a Push ServiceAPI, UnifiedPush would have kind of been integrated into the OS. Theapplications would receive push endpoints like we do, and they would sendweb push requests, following standards, like web applications does, likeUnifiedPush does. Migration from UnifiedPush would be minimal.If we manage to have such a Push Service API, we can expect many more appssupporting the feature. And we will finally be able to choose the serviceswe want to trust.Hopefully, working on UnifiedPush can push in that direction by increasingthe demand, and highlighting the need.On Linux, I think the adoption depends a lot on how the mobile Linuxecosystem evolves. I personally think and wishes that it goes in the rightdirection. And I think a lot of things can happen in 5 years on the matter.