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.
Should we consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa?
Not necessarily, and I will attempt to explain why.
Android or iPhone — either Google or Apple delivers our messages — surely? You don't accept that?
Time I Learned: there are freedom-respecting phones.
People who do not want to depend on Google or have them control our devices are using android-compatible but not google-controlled phones, a.k.a. “degoogled phones”. We have been asking (ourselves) for several years if we can have google-free push notifications. Thanks to the developers of the UnifiedPush standard, the answer is now, “yes!”
UnifiedPush open-standard push messaging complements degoogled android-compatible phone OS's such as LineageOS.
People who do not want to depend on Google or have them control our devices are using android-compatible but not google-controlled phones, a.k.a. “degoogled phones”. We have been asking (ourselves) for several years if we can have google-free push notifications. Thanks to the developers of the UnifiedPush standard, the answer is now, “yes!”
The open standard UnifiedPush.org has now been created. While not a large number yet, a useful handful of apps already support UnifiedPush, including several matrix and fediverse apps. For its servers and the associated client-side “distributor” component, there are multiple successful implementations deployed.
Announced by @davx5app@fosstodon.org, the good folks at DAVx5.com who make the libre/open sync for CalDAV/CardDav/WebDAV, that connects Android/Outlook/Thunderbird to standard calendars, address books and file shares: they are now looking at designing a “push notification” standard for the DAV family of libre (open) standards.
Yay! Fantastic!
With push support, my family would get instant, efficient updates to our shared calendar and address book whenever any of us add an entry, for example.
The most interesting thing about this, for those of us who care about liberty and choice, is that the push delivery system should not be locked in to google/apple but should be able to use the UnifiedPush.org open standard that lets each end-user choose their preferred push provider. (See my other posts on UnifiedPush.)
I would love to work for or with Murena on their /e/-OS phone. UnifiedPush support is one of the first things I would propose to do.
UnifiedPush is in my humble opinion one of the most important recent developments for freedom phones. It grants us freedom from Google’s near monopoly push notification system FCM. I have followed the development of UnifiedPush it from its OpenPush origins.
What have I done so far?
I have deployed ‘ntfy’, a UnifiedPush compatible server implementation, on my home network. I documented and published my installation script (which uses Ansible and Docker), and successfully submitted it for inclusion in the popular Matrix installer matrix-docker-ansible-deploy, so matrix self-hosters can deploy it easily.
My self-hosted push service now serves notifications to several of the apps I use.
If given the chance to advance UnifiedPush support, I would propose a plan something like this:
deploying a UP server for /e/ users (one for the Murena central server, and one in each self-hosted deployment), initially choosing one of the existing kinds of UP server (probably NextPush because obviously it's built to fit into nextcloud);
creating a UP distributor as an /e/-OS system app, by adapting an existing one (NextPush, to match the server), and making it auto-discover/configure the server from the /e/-OS account info;
working with important client apps (/e/-OS default apps first) to add support to them;
perhaps tweaking the U.P. server and distributor to better suit this use case, if and when needed.
