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

CoMaps for Android – Part 2 – Privacy and Location Sharing Done Right

Continuing from the previous post about the pros and cons of CoMaps, a fork of OrganicMaps for Android, let’s have a look at how private and offline CoMaps actually is. From a privacy respecting maps app, I expect that the app doesn’t spill my location to anyone on the network, including potential project servers. So that’s my baseline here.

CoMaps for Android – Part 1 – Bringing the Speed Back for Maps

I’ve been a frequent user of OpenstreetMaps for Android (Osmand) for many many years. It is packed with features and does everything for me from finding nearby businesses, adding and editing features on the map for the community to navigation advice, i.e. routing, over large distances. However, over the years I’ve noticed a gradual slow down when I zoom in and out of maps or swipe in any direction to see a different part of the map. It got to a point with my Pixel 8 and GrapheneOS where I really started to get annoyed and actively started to look for something different. And it seems there is a very good and privacy respecting alternative: CoMaps, a recent fork of OrganicMaps.

Being Mobile Device Overlord For a Day

If you are working for a company that employs more than a handful of people and use a company smartphone or tablet, chances are that the device is owned and ‘managed’ by the company. ‘Managed’ basically means that the company uses a remote Mobile Device Management (MDM) solution that hooks into a management API of the smartphone. The same applies to notebooks as well, but I want to focus on mobile devices in this post. While the concept was clear to me in theory, the practical aspects of this have always been a bit vague, as I’m not working in an IT department that ‘manages’ remote devices. Recently, however, I came across an MDM solution that offers a free trial account. So I jumped at the chance and became a ‘Device Overlord’ for a day to see just how much can be controlled remotely and how the device enrollment process works.

UnifiedPush – Part 4 – Power Efficiency

Finally in this series, I’d like to say a few words about UnifiedPush (UP) and power efficiency. UP is a decentralized system and can use different transport options. Have a look at previous posts on this topic for details. And surprisingly, some transport options are much better than other when it comes to sending keep alive packets to ensure that Network Address Translations (NAT) gateways do not forget the connection and inadvertently block incoming notifications.

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: