Molly: An Improved Signal App

📝 Discussion Summary (Click to expand)

The discussion surrounding Molly and Signal reveals three primary, intertwined themes:

1. Desire for/Frustration with Android Multi-Device Support

A significant portion of the conversation centers on the lack of, or difficulty with, linking multiple Android devices natively within the official Signal application. Users express that this feature is common elsewhere and a major blocker for adoption or usability.

Supporting Quote: "Can someone explain, is this different from adding (up to 5) devices to your Signal account? Are these devices all 'primary' or something?" asked by "k_bx," followed by "Signal's official Android app does not support being linked, only the iOS and desktop apps support that. This is why I use Molly." stated by "jeltz."
Supporting Quote: "Yeah, that is why I started using Molly." stated by "jeltz" regarding the inability to use both an Android phone and an Android tablet simultaneously.

2. Security Regressions and At-Rest Database Encryption

There is a strong undercurrent of dissatisfaction with Signal's security posture regarding local data storage. Proponents of Molly view it as addressing specific security 'regressions' where the official app allegedly prioritizes usability over protecting data at rest via pin-protected local encryption.

Supporting Quote: As someone who's been enthusiastic about Signal since it was TextSecure and RedPhone, the changes made over the years to broaden the userbase have been really exciting from an adoption perspective, and really depressing from a security perspective." noted by "anonym29," followed by Molly fixing "several of those security regressions."
Supporting Quote: "Once unlocked (or broken into), stock Signal offers you zero protection, while Molly forces them to start a brute force attack against the password you gave Molly." explained by "anonym29" when discussing forensic device access.

3. Concerns Over Proprietary Dependencies (De-Googling)

Users focused on maximizing privacy and running custom, de-Googled Android distributions (like GrapheneOS) are strongly attracted to Molly because it removes reliance on Google Mobile Services (GMS/FCM) for critical functions like push notifications.

Supporting Quote: "Contains no proprietary blobs, unlike Signal" noted by "landr0id" prompting a deeper discussion on FCM/GMS.
Supporting Quote: "It doesn't have the GCM crap and hence works on de-googlified custom ROMs as well." stated by "twothreeone," highlighting better compatibility for users outside the standard Google ecosystem.

🚀 Project Ideas

Android Device Multi-Link Utility (ADMLU)

Summary

A simple utility application designed specifically for Android that allows a standard Signal/Molly client to register and maintain a persistent connection with a secondary Android device (like a tablet) as a linked device, bypassing the restriction where Signal primary devices (phones) fight for control over non-phone secondary Android devices.
Core Value Proposition: Seamless, persistent multi-device access for Android tablets/secondary phones on Signal/Molly networks, addressing a major UX hurdle mentioned by users.

Details

Key	Value
Target Audience	Users with Signal installed on an Android Phone and a secondary Android Tablet/Phone who want both to operate simultaneously without one being constantly logged out.
Core Feature	Intercepts the initial device linking process (or analyzes the existing configuration) to maintain the secondary Android device as a non-primary, permanently linked client, similar to how desktop clients function.
Tech Stack	Kotlin/Java (Android Native), potentially leveraging experience from Molly; focus on secure IPC/session persistence.
Difficulty	Medium (Involves deep understanding of Signal's device registration logic and persistence mechanisms.)
Monetization	Hobby

Notes

HN commenters expressed significant frustration: "The deathblow for Signal was that I was in a group and some group messages just got lost for some members completely unnoticed... I can only log into signal on one [Android device]." (jeltz, ahazred8ta, krater23).
This is a direct, highly requested feature that Molly partially solves, but a dedicated, simple tool focused purely on this linkage parity could gain traction, especially if it could be made compatible with official Signal builds (if the API allows).

Decentralized Push Notification Abstraction Layer (DPNAL)

Summary

A transparent service layer for Android applications that abstracts away the dependency on Google Play Services (FCM) for push notifications, defaulting to and promoting open standards like UnifiedPush, while providing an easy fallback mechanism.
Core Value Proposition: Eliminates proprietary blobs (FCM/GMS) from messaging apps (like Signal or others wishing to de-Google) while ensuring users still receive timely notifications without requiring complex self-hosting of dedicated notification servers.

Details

Key	Value
Target Audience	Users on minimalist custom ROMs (GrapheneOS, CalyxOS) or those actively seeking to remove all Google dependencies from their devices.
Core Feature	A standardized overlay that receives notifications via UnifiedPush (or similar protocols) and relays them reliably to the target application, with an optional, user-configured fallback to a self-hosted or third-party FCM endpoint if UP is unavailable or fails.
Tech Stack	Android Service, UnifiedPush bindings, potentially leveraging insights from the Mastodon reverse-engineering effort regarding FCM broadcast receivers.
Difficulty	High (Requires deep integration into the Android OS notification system and dealing with power management exemptions that FCM often relies on.)
Monetization	Hobby

Notes

This directly addresses the conversation around Signal's proprietary blobs: "Contains no proprietary blobs, unlike Signal" (landr0id), and the issues regarding battery drain: "i don't use any of the enhancements, but it does receive notifications over the websocket it keeps open in the background vs only waking up on an FCM push notification" (throawayonthe).
It attempts to solve the usability/battery trade-off for de-Googled users by making cross-platform push abstraction seamless.

Local Signal Database Auditing Tool (LSDA)

Summary

A cross-platform (desktop/mobile) utility that allows users to safely inspect and audit their local Signal/Molly database contents, focusing on metadata that attackers might exploit or that the official client obscures, without requiring message export mechanisms.
Core Value Proposition: Provides high-transparency users with verifiable proof/insight into local data protection status, particularly concerning database encryption (at-rest security) and metadata exposure via ancillary services.

Details

Key	Value
Target Audience	Security-conscious users concerned about Signal's local database encryption posture or metadata leakage via GMS/Firebase.
Core Feature	Reads the local SQLite database (after user decryption via PIN/Passphrase if available in the fork), checks DB encryption status against stated security goals, and reports on any known external connections (e.g., Firebase/Analytics identifiers).
Tech Stack	Cross-platform framework (e.g., Rust/Tauri or Flutter) to handle local file system access and database reading securely.
Difficulty	Medium (Requires secure handling of cryptographic keys/passphrases to access the DB, but the querying itself is straightforward if the DB structure is known.)
Monetization	Hobby

Notes

This taps into the deep user concerns about at-rest encryption: "The in-transit encryption is genuinely good enough... but the at-rest encryption became a joke the moment they stopped using your pin to encrypt the local DB" (anonym29).
It also addresses the proprietary dependencies: "Firebase, GMS (Google Mobile Services)" are part of the threat model (landr0id). A tool proving the local data is clean, or highlighting where it isn't, would appeal to this segment.