In a previous post I’ve had a look at how I can use the Signal Messenger app on my GrapheneOS Android phone without Google’s push notification service (FCM) for incoming messages. There are a number of options and I settled for the combination of the Molly-FOSS fork of the Signal App and UnifiedPush (UP) for notification. It works like a charm so I had a more detailed look at how UnifiedPush actually works and which options there are. It was a bit challenging to get my head around the online documentation so I thought I’d write a couple of blog entries to see if I can explain the concept in simpler terms. Not only for you, but also for me, because I’m sure the topic will come up again in the future.
A Super High-Level Overview
So on a very high level, UnifiedPush (UP) aims to be an open source, de-centralized and very flexible alternative to Google’s cloud push notification service. So from this point of view, UP replaces two components:
First: UP offers an alternative to Google’s cloud service that receives push notifications for apps on a mobile device from many servers and then forwards them over a single optimized connection to the mobile device. UP is not a drop-in replacement for Google’s service, so servers that want to send a push notification to an app on a mobile device need to be enhanced to not only support Google’s push notification service, but also UnifiedPush.
Second: UP offers an alternative to Google’s push notification API on Android. This is normally provided by the Google Play service in the background. To replace this, an app is required. This app offers an interface to other apps on the device to receive push notifications. As UP is not a drop-in replacement for Google push notification and can happily run alongside it, apps that want to support UP need to implement that interface. In other words, apps need to be modified to support UP in addition Google’s notification service.
Decentralization
OK, so far, so good, let’s go one step further down: Actually, the description above is not quite accurate, because UP is not a single server sitting somewhere. Rather, UP describes an API for the network side and an API on the mobile device side. In other words, it specifies how a server on the network can send a push notification to the UP server and it specifies the API interface an app on a mobile device has to expose to other apps that want to receive push notifications.
There are two important points here:
First: How the message is delivered from the UP server to the app on the mobile device that acts as an API front end for mobile apps wishing to receive notifications is NOT specified. Different kinds of transports can be used. In the simplest case, it’s an optimized TCP connection with an open or proprietary protocol. Or, one could use the XMPP protocol, server and client to act as the conduit for the push notifications. Or, one could use other notification servers and apps to also transport UP notifications. The important point here is that the mobile apps and the application servers on the network do not know what kind of transport protocol is used. This is fully transparent to them. They have a well defined API and that is all they have to care about.
Second: UnifiedPush is a decentralized system, there are many UP servers out there and the user has the choice which one to use. There are a number of UP servers out there that can be used by anyone, but one can also deploy a private server. Application servers that want to send push notifications do not really care how many servers are out there. While in the Google case, the domain name of the server is hard coded, the server must remember which UP server to use for which client. All of this is configured in the background when the mobile app is installed, so the overhead for the user is kept to a minimum.
Next Steps
This is my high level description of UnifiedPush. Perhaps still a bit abstract. Therefore I will have a few follow up posts that give some practical examples of how this is used in practice for two mobile apps: Molly, a fork of the Signal messenger, and Tusky, a popular Mastodon feed reader. Stay tuned…