Molly App On /e/OS: Fixing UnifiedPush Recognition
Understanding the UnifiedPush Dilemma in Molly
If you're a privacy-conscious user rocking the /e/OS operating system and have recently switched to Molly, you might have encountered a peculiar issue. Specifically, Molly, a fork of Signal focusing on enhanced privacy, doesn't seem to recognize the native UnifiedPush service available on /e/OS. This is a bit of a bummer because UnifiedPush is designed to be a more efficient and battery-friendly way for apps to receive notifications, replacing the often resource-intensive WebSocket method. Our goal here is to dive deep into why this is happening and, more importantly, how we can potentially fix it. We'll explore the steps to reproduce the bug, what the expected behavior should be, and the actual, frustrating outcome. By understanding the nitty-gritty details, we can better advocate for better integration and perhaps even find a workaround. So, let's get started on unraveling this technical puzzle and ensuring your Molly app plays nicely with the privacy-centric features of /e/OS.
Reproducing the UnifiedPush Glitch in Molly
To truly grasp the problem, we need to walk through the exact steps that trigger the bug. Reproducing the UnifiedPush recognition issue in Molly on /e/OS involves a specific sequence of actions that consistently leads to the app failing to connect to the native notification system. First, you'll need to ensure you have a fresh installation of Molly. After that, log in to your Signal account within the Molly app. The crucial step follows: navigate to your /e/OS settings, specifically Settings >> System >> UnifiedPush, and make sure you enable the distributor. This tells the operating system that you want to use UnifiedPush for notifications. Now, head back into the Molly app's settings. Go to Molly app Settings >> Notifications >> Delivery service. Here's where the problem lies: when you attempt to change the delivery service from the default WebSocket to UnifiedPush, Molly still asks for a QR code. This is unexpected, as the native distributor should ideally be recognized automatically without needing a QR code, which is typically used for initial setup or migrating between devices/services. Even after a phone reboot (steps 5 and 6), the issue persists. Upon restarting your device and revisiting Molly's notification settings, you'll find that it still prompts for a QR code, stubbornly refusing to acknowledge the enabled native UnifiedPush distributor. This consistent failure to integrate highlights a clear disconnect between Molly and the /e/OS UnifiedPush framework.
Expected vs. Actual: The UnifiedPush Discrepancy
When we talk about Molly's notification delivery service on /e/OS, there's a clear divergence between what we expect to happen and what actually occurs, especially concerning UnifiedPush. Ideally, after enabling the native UnifiedPush distributor in /e/OS settings, any app that supports it, like Molly, should automatically detect and utilize this more efficient notification system. The expected result is straightforward: Molly should recognize that UnifiedPush is available and seamlessly switch its notification delivery from the power-hungry WebSocket protocol to the battery-saving UnifiedPush. This would mean smoother notifications, reduced battery drain, and a more streamlined experience overall, aligning perfectly with the privacy and efficiency goals of both Molly and /e/OS. However, the actual result paints a different picture. Despite having UnifiedPush enabled at the system level, Molly continues to operate on its default WebSocket service. When you try to manually select UnifiedPush within Molly's settings, instead of a smooth transition, the app frustratingly presents a prompt for a QR code. This QR code requirement is typically for setting up new connections or migrating accounts, not for integrating with a natively available and enabled system service. It implies that Molly isn't
