|
# UnifiedPush as OS Service
|
|
# UnifiedPush in the OS
|
|
|
|
|
|
- [[home]]
|
|
- [[home]]
|
|
- [[NGI-Proposal]]
|
|
- [[Minotif]]
|
|
|
|
- [[Nextcloud-Instant-Updates]]
|
|
|
|
- [[Nextcloud-NGI-Proposal]]
|
|
|
|
- [[ReviewKeyApps]]
|
|
|
|
|
|
|
|
|
|
|
|
## 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 problem: Messaging apps in our libre mobile ecosystem are currently tied to Google FCM for their push messaging needs.
|
|
|
|
|
|
The solution: [UnifiedPush][UP]. I want to build around UnifiedPush. Then our apps can work efficiently without tying this function to a particular service provider.
|
|
The solution: [UnifiedPush][UP]. 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][u-DIST] and [supported apps][u-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][j-UPGO] and a sketch of the [wider scope of work needed][j-UPWI] around it. The next steps that will contribute most effectively to its wider adoption include:
|
|
UnifiedPush (UP) is by now well proven, with multiple [implementations][u-DIST] and [supported apps][u-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][j-UPGO] and a sketch of the [wider scope of work needed][j-UPWI] around it. To support its wider adoption requires work in these areas:
|
|
|
|
|
|
- integrating UP in key apps (some have willing devs, others need contributions)
|
|
- 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)
|
|
- providing UP as a service provider (server/service side, and mobile OS integration)
|
|
- documenting (best practices for implementors, client-server protocol and options...), sharing, promoting
|
|
- documenting, sharing, promoting
|
|
|
|
|
|
Proposed work:
|
|
I am consulting stakeholders (UP devs, /e/OS...) on where to focus.
|
|
|
|
|
|
1. list "key" apps (default and strategically important apps), evaluate them for status and effort needed, publish findings (building on my [initial sketch][j-UPWI]);
|
|
|
|
2. implement or improve UP in one key app (TBD);
|
|
|
|
3. create stripped-down UP server and client pair derived from 'ntfy', removing its non-UP functions, more suitable for embedding;
|
|
|
|
4. document and publish the (stripped-down) ntfy UP client-server protocol, so others can re-implement it;
|
|
|
|
5. implement Nextcloud notifications over WebPush (and so UP) (as [advised by S1m](https://codeberg.org/NextPush/uppush/pulls/17) after 2 people tried other approaches);
|
|
|
|
|
|
|
|
I will consult stakeholders (UP devs, /e/OS, Nextcloud, NLNet...) for their input on where to focus.
|
|
## Project Proposals
|
|
|
|
|
|
Outcomes: docs and implementation as stated, published; blog posts; outreach to potentially interested Freedom Phone organisations.
|
|
- [[Nextcloud-Instant-Updates]] -- implement push messaging in this key app
|
|
|
|
- [[Minotif]] -- a service-provider-focused UP implementation derived from ntfy
|
|
|
|
- [[ReviewKeyApps]] -- a task to evaluate what is needed for key apps to support UP
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
> *Prior involvement*
|
|
## 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.
|
|
|
|
|
|
I spoke in the UP matrix room with Jonathan Klee (working on the /e/OS ntfy integration) in November 2024; he said they don't have clear plans around this. I have spoken with others there including S1m who expressed support for my [UP-for-IMAP proposal][U4IMAP].
|
|
|
|
|
|
|
|
I have contributed the [*ntfy* server deployment component][mdad-ntfy] for the Matrix-Docker-Ansible-Deploy playbook, and some [UnifiedPush troubleshooting docs][u-TRBL].
|
|
## 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.
|
|
|
|
|
|
I have been involved at a low level with projects in this scene including UnifiedPush, ntfy as a UP server, UP for matrix, /e/OS, LineageOS -- building, self-hosting, experimenting, discussions.
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
## References
|
|
|
|
|
|
My writing on UP:
|
|
My writing on UP:
|
|
|
|
|
|
- **`2024-11-27` [UnifiedPush — Wider Developments][j-UPWI] -- what else we need to make this work**
|
|
- **`2024-11-27` [UnifiedPush — Wider Developments][j-UPWI] -- what else we need to make this work**
|
... | @@ -47,7 +65,7 @@ My writing on UP: |
... | @@ -47,7 +65,7 @@ My writing on UP: |
|
|
|
|
|
My related projects:
|
|
My related projects:
|
|
|
|
|
|
* my NLNet NGI proposal 2024-10-535 [UP-for-IMAP][U4IMAP]
|
|
* my NLNet NGI proposal 2024-10-535 [UP-for-IMAP][U4IMAP] -- UnifiedPush for email via IMAP WebPush
|
|
|
|
|
|
References (visible only in the Markdown source):
|
|
References (visible only in the Markdown source):
|
|
|
|
|
... | | ... | |