Skip to content

GitLab

Last edited by Julian Foad
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Home

UnifiedPush in the OS

Overview

Overview and References: https://lab.trax.im/up/up-in-os

The problem: Messaging apps in our libre mobile ecosystem are currently tied to Google FCM for their push messaging needs.

The solution: UnifiedPush. I want to build around UnifiedPush. Then our apps can work efficiently without tying this function to a particular service provider.

UnifiedPush (UP) is by now well proven, with multiple implementations and supported apps. It is actively being refined, some of that work funded by NLNet/NGI. Murena's /e/OS recently made the first step in integrating support in the OS. I published an analysis of that step and a sketch of the wider scope of work needed around it. To support its wider adoption requires work in these areas:

  • integrating UP in key apps (some have willing devs, others need contributions)
  • providing UP as a service provider (server/service side, and mobile OS integration)
  • documenting, sharing, promoting

I am consulting stakeholders (UP devs, /e/OS...) on where to focus.

Project Proposals

Integrating UP Distributor in OS: Comparison with Big Tech

The two main UP-compatible implementations today, ntfy and NextPush, each provide a server and a client-side distributor app. Ntfy and NextPush each implement a lot of the expected functionality that would be required for an integrated service. In each case the distributor, supplied as a regular user-installed app, demands up-front effort to grant permissions for its system-level functions, primarily to do with remaining active in the background.

The comparison with the Big Tech duopoly is illuminating. They more or less require a single sign-in to their authoritative service when setting up their devices, and in order to continue using them. No additional action is required of their user in advance to activate the device finding functions. On the converse, the user has no choice, no option to use an alternative, no control over any tracking or blocking of their service.

Ecosystem of UnifiedPush

UnifiedPush is steadily improving and growing in the freedom-phones ecosystem. Its key developers create standards, implementations, and contributions to related projects. A recent update brings full compatibility with WebPush.

The main ecosystem for usage is android-compatibles (LineageOS, Murena-/e/OS, CalyxOS, GrapheneOS...). We will reach out, show integrations they could adopt and solicit their involvement.

Other freedom-phone ecosystems include GNU-Linux-compatibles (PostmarketOS, Purism-Librem...) and SailfishOS (Jolla). Not sure if they have any push messaging functionality of their own yet. We will let them known about it and see if there is interest from their side, as the technology should be cross-platform.

The "WebPush" system is another side of the push notifications ecosystem. Currently, each web browser vendor runs their own push server. If the browser were modified, these web pushes could alternatively use a UP connection, reducing two connections to one. S1m plans to submit patches for Firefox-android to use UP.

Some android-compatibles use MicroG which implements an interface to Google's FCM, for apps that insist on using it within an otherwise free-software handset. MicroG might be interested in offering UP as well.

References

My writing on UP:

My related projects:

  • my NLNet NGI proposal 2024-10-535 UP-for-IMAP -- UnifiedPush for email via IMAP WebPush

References (visible only in the Markdown source):