UnifiedPush — Wider Developments
An article about Building the Self-Agency Mobile Ecosystem: Push Messaging
Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently. But Who Cares Who Delivers Our Notifications? Our answer is: we care, and we do not like being locked in to depending on one mega-corp's system.
Therefore, in our libre mobile computing devices, we require a push-messaging infrastructure built from open standard technology that gives us freedom to choose our service providers and authority over them.
Read more in Going Google-Free with UnifiedPush in /e/OS and my other articles about UnifiedPush .
How We Get There
How can we build this? What is needed to get widespread UnifiedPush support in /e/ and other mobile OS?
The big picture involves several areas of work.
- OS integration of the distributor, including how it's configured, auto-detected, optimised, etc.
- Server Software: Making sure a suitable server-side component is available, supported, optimised for this use case.
- Server hosting: making sure a server component is easily deployable by others, including making generic deployment methods (Debian, Docker, Nix, K8s, ...) and integrating it in some hosting systems.
- Apps: Working with other apps to make sure they connect and work with UP out-of-the-box.
- Sharing this work among other mobile OS projects (microG, CalyxOS, GrapheneOS, PostmarketOS, ...) .
- Consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa.
(Links in this and the following sections lead to relevant issues or discussions, where I could find any.)
OS Integration of the UP Distributor
Including how the UP distributor is configured, auto-detected, optimised, Android permissions, etc.
- I recently analysed how /e/OS 2.5 has started the ball rolling
Server Software
Making sure a suitable server-side component is available, supported, optimised for this use case
- Nextcloud: UnifiedPush Provider — exists
- It could alternatively begin with a fork of ntfy-server for example.
Server Hosting: Technical
Making sure a server component is easily deployable by others, including making generic deployment methods (Debian, Docker, Nix, K8s, ...) and integrating it in some hosting systems, ranging from hobbyist to serious commercial systems.
- Docker ntfy — exists
- K8s ntfy helm-chart — exists
- Nextcloud: UnifiedPush Provider — exists
- Matrix-Docker-Ansible-Deploy: ntfy-server — exists
- Yunohost: ntfy-server — exists
- SelfHostBlocks — not yet
- CoopCloud — not yet
- Fediversity (an upcoming hosting project) — not yet
Server Hosting: Social/Business Aspects
Work out and write up (shareable) policies about who hosts, terms and conditions, privacy, rate limiting and other special measures, etc.?
Apps
Working with other apps to make sure they connect and work with UP out-of-the-box.
Category 1: default apps in /e/OS etc., like...
- Mail: K9/Thunderbird-andriod #5165 and UnifiedPush for IMAP (NGI proposal
2024-10-535) - Nextcloud -uppush #17 -notifications #1225 -android #8684
- Accounts/Calendar/Contacts (DAVx5 #36 + DAV-push)
Category 2: other popular apps like...
- HomeAssistant #446344
- Fluffychat — exists
- Element — exists
- Signal forks
- Telegram-FOSS #577
- Conversations.im — exists
- Pixelfed #86
See also the UnifiedPush wish list.
Sharing with other mobile OS projects
Sharing this work among other mobile OS projects.
- /e/OS — exists
- microG #486
- CalyxOS #1395
- GrapheneOS #10455
- PostmarketOS — UnifiedPush, Push notifications
- SailfishOS — mentioned in 2023-01-12 meeting minutes as blocked by much work needed to enable background services
And even desktop OS:
- KUnifiedPush — exists — note also KDE runs their own (ntfy) UP server
Standardising UP client-server protocol?
Should we consider standardising the UP client-server protocol? At present, by design, one must choose a UP distributor and UP server together as a pair. If we standardised the protocol between them, so any distributor would work with any server, this would certainly have some benefits, but also down-sides, and is not necessarily the right thing to do. UP was designed this way on purpose and achieves its goals without needing to standardise there. No ordinary person needs to be able to change their UP implementation. Only techies and service providers might like to do that.
Therefore this is an exploration rather than a development. I discuss this further in a separate article.
#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree
Follow/Feedback/Contact: RSS feed · Fedi follow this blog: @julian@wrily.foad.me.uk · use the Cactus Comments box above · matrix me · Fedi follow me · email me · julian.foad.me.uk Donate: via Liberapay All posts © Julian Foad and licensed CC-BY-ND except quotes, translations, or where stated otherwise