WirelessMoves – My Thoughts on the Evolution of Wireless, FOSS and the Past, Present and Future of Computing

UnifiedPush – Part 3 – Molly-FOSS and the Gateway to Signal

In the previous post, I’ve had a look at how to set up UnifiedPush (UP) on Android. The easiest option: Download the SunUp app, switch-off battery optimization so it can run in the background and you are done. Easy! At the moment, I’m using UP on GrapheneOS for two applications: Tusky, a Mastodon reader and Molly-FOSS, a Signal messenger fork which replaces the Google cloud notification service with UnifiedPush. Molly-FOSS can run on its own without UP, but then uses Signal’s fallback proprietary web socket push system that sends keep-alive packets several times a minute. This is very power inefficient and I wouldn’t want to use this method in practice. Setting up UP in Molly-FOSS is not difficult, but it was a bit confusing for me at first, because it requires an additional setup step which is not part of the normal UP configuration procedure. Let me explain:

UnifiedPush – Part 2 – An Easy Practical Example

In the previous post, I’ve had a look at UnifiedPush (UP) and how it works in theory to deliver push notifications from servers to apps on mobile devices. UnifiedPush has been designed to be de-centralized, and if one does not want to self-host a UP server, there are a number of different transport options and UP server providers available for use. I use two apps on my Android device with UnifiedPush, Tusky, a Mastodon feed reader and Molly-FOSS, a de-googled Signal messenger fork. While I was tempted to go straight for a description of how Molly-FOSS uses UP, I’ve decided to defer that into a separate post and rather go for a description of how Tusky uses UP, as the setup for this use case is simpler. Let’s go from simple to more complicated!

UnifiedPush – Part 1 – Why and How

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.

From Signal to Molly-FOSS and Unified Push

As you might know, I’m using the ‘Conversation’ XMPP based messenger app on Android and my Linux notebook for text, audio and video communication with friends and family. A federated self-hosted XMPP server keeps me independent from- and interconnected with others at the same time. And then there are friends and associates in a somewhat wider circle for whom it is not very appealing to use yet another messenger. Perhaps as unappealing as it is for me to use Whatsapp. But perhaps there is a middle ground?

Keep Alive Timing of Google’s Firebase Cloud Messaging

In the previous post I had a look at the background keep-alive data traffic of messaging apps on my GrapheneOS device that do not use the Google Firebase Cloud Messaging (FCM) service for push notification. I’ve optimized my apps and servers to have keep alive timers of 5 to 6 minutes, which ensures that even aggressive NAT routers in the path do not kill the connections. So how do these values compare to Google FCM?

Background Traffic of Android Apps – An Update

It’s been 5 years since I’ve had a look at how often the apps I use on my smartphone send or receive data in the background. Keeping the amount of background traffic to a minimum is important to reduce power consumption while the phone is not actively used. Google and Apple have recognized this and are offering a single channel to each device through which notifications can be sent. While the approach is understandable, there are people like me who are not very fond of having notifications run through a single centralized entity. On Android, fortunately, apps can keep their own decentralized notification channels open in the background. Some of those apps and servers are better than others when it comes to minimize traffic and thus to reduce battery consumption. When I recently switched to GrapheneOS, it was time again to have a closer look at background data exchanges and to see if there is anything I can optimize. And here is the result:

WebRTC Video Bandwidth Requirements

In a previous post I’ve been looking at the network behavior of voice calls over WebRTC on Android. In that graph, one can see that the bandwidth, independent of Wi-Fi (over DSL) or cellular is around 80 kbit/s in each direction. During the Conversations XMPP app call, we then switched from voice-only to voice+video. Needless to say that bandwidth requirements then change significantly.

From Firefox to Fennec to Vanadium?

I think I’ve been using the ‘original’ Firefox web browser since 2004 on my notebook and also on Android from the day it was released. Over the years, there has been criticism around anti-privacy features that came and went, most of them probably well founded. Nevertheless, I stuck to Firefox on my smartphone until recently but decided to switch after seeing just how often Firefox ‘calls home’.

Wireguard on Android – A Bit of a Mixed Bag

Earlier this year, I had (another) look at Wireguard. Beginning with Ubuntu 24.04, the client is now fully integrated in the network GUI and a Docker based server installation has become available as well. One thing I didn’t have time for at the time was to look at Wireguard on Android. So let’s have a go now.

WebRTC Handover between Wi-Fi and Cellular

I use the Conversations XMPP messenger a lot on my Android phone, not only for text, image and video chat messages, but also for voice and video calling. It’s a joy to use! While in the early days, voice calls dropped when moving between the cellular network and Wi-Fi, the process has become pretty much seamless in the meantime. When I recently jumped between Wi-Fi and cellular a number of times on purpose, I was surprised that I couldn’t hear the switch between the networks in the audio channel at all. So perhaps the call didn’t switch and staid on cellular? I decided to have a closer look.