OK, a bit of a cryptic headline, I admit, so here’s the full story: I use my Pixel 8 with GrapheneOS without any kind of Google infrastructure interaction. That limits the use of the ‘original’ Signal Messenger to Websocket notification for incoming messages. I don’t like that much, as this is quite battery intensive and keeps the cellular radio in active state for most of the time. Fortunately, there is a fork of the Signal messenger app called ‘Molly‘, which can use the UnifiedPush protocol as an alternative way to notify incoming messages to the app. In practice, this method of push delivery requires a proxy in the notification chain, as the Signal infrastructure does not natively support UnifiedPush. These proxies are called ‘MollySocket‘, and there are quite a number of public instances available. Unfortunately, all proxies I tried suffer from delay and reliability issues. I guess this is due to their popularity. But one can also host a private instance at home and this fortunately makes the use of UnifiedPush for Signal/Molly rock steady.
Let’s Air-Gap
Private MollySocket instances can be run in ‘air-gaped’ mode. This means that the instance does not expose a web front end which is otherwise used by devices to connect and configure the MollySocket proxy. Instead, parameters have to be exchanged offline via the shell. The barcode, which is otherwise found on the web interface is printed in the log output of MollySocket and can be scanned with the phone from the shell. In return, the parameters Molly gives to the MollySocket have to be copied to the clipboard and then used in a shell command to register the device with the MollySocket. This is the only way to sign up, so this instance of MollySocket can remain private.
A NAT is not a Problem
Another interesting feature is that the air-gaped MollySocket instance can run behind a NAT, as it only establishes outgoing connections. One outgoing connection is made to a Signal server to receive push notifications for incoming messages for the Molly client(s) it represents. When a push notification is received, the proxy forwards the notification via another outgoing connection via a Unified Push provider to Molly. Very nifty, both connections are outgoing, there is no open port and no incoming connection request to the proxy.
The Documentation on Github is…
When I had a look at the documentation of MollySocket on Github, I was a bit discouraged, as it looks very complicated. Also, only a docker image is referenced, documentation for a docker compose setup is missing. So I used an LLM to generate easier step by step instructions for what was available to get going with a docker compose setup. I would have had MollySocket up and running in 5 minutes with this, but decided to read the instructions carefully and understand what I was actually doing, so it took me 15 minutes. Still, not much effort for getting reliable push notifications for my devices with Molly on it.
In the next post, I’ll document my setup process in case you want to self host a MollySocket instance and also want to do that with a docker compose setup.