I've used Molly for over a year. Overnight it lost the device registration and will not contact the servers to re-register. The backup feature also does not work which left me dead in the water for several days with no fix. I switched back to signal and had to start a new database. It was a disaster. YMMV
Sounds pretty much like my experience with the official Signal app. It is a mess too and I only use Signal/Molly because I have friends who use it.
But sadly the competitors are as bad, just in different ways. Why has nobody yet managed to build a good IM client? It does not seem like we have come far from what we had back in the Pidgin days.
Very few of the protocols supported by Pidgin were encrypted, unless you used the OTR plugin. That makes it a lot easier to support things like chat history.
conversations (xmpp) and deltachat work pretty well in my experience.
Dino (XMPP, https://dino.im) is a great desktop client to talk to other XMPP clients, in particular Conversations, due to its broad support of XEPs.
Conversations has an issue where the main tool for reading a backup on a computer (ceb2txt (so, say, I can properly and correctly archive a text dump archive of a person I loved who died)), will not work for me. I filed a support request and there's been no movement on it whatsoever and it genuinely seems like nobody gives a shit. Restoring a backup even with all the images and media files in the correct place with the correct filenames will then refuse to show any filenames.
This is par for the course with chat backups, though.
Messenger - Bad - No way to save chat responses of people you have talked to. This means you only ever have one side of a conversation, making it meaningless.
Twitter DMs - Bad - See Messenger.
Jami - Ehhhh - Saves a git local repository of messages. The only problem is message syncing is effing abysmal.
Dino (XMPP) - Bad - Does not allow backing anything up, this is "intentional". Depending on which protocol you use, as soon as you move to another device all the messages you _had_ are retroactively converted to Cannot Decrypt. They're my effing messages!
Discord - Good - Discord History Tracker (tedious to use but slurps everything up into a sqlite3 database that is itself, an official archival format)
WhatsApp - Good - Dumps a text record + files/images/etc. onto the phone's filesystem. This is reasonably easy to archive.
Signal - Mediocre - If you have an old Signal backup from 2018? That you could only transfer off your phone by deleting old messages? lmao you're effed. Load up a version from ten years ago, gradually update it and then maybe, MAYBE you can extract the sqlite3 archive? These days you have a .signalbackup or whatever which is an encrypted archive, and I assume that there's a tool to decrypt it, but uhhhhhh. Last I tried to use it it required way more RAM than I had accessible.
Beeper is pretty good. I daily drive it on multiple protocols.
I love beeper and have been using it for a very long time at this point, but I wouldn’t go as far as calling it a good client.
Whatsapp mentions don’t work (just show the name of the mention to the other users), and polls or albums don’t work.
Messenger disconnects every couple of days at this point.
Pasting links won’t always expand.
Attachments are always hit or miss.
So many small other things. Still love it.
> Contains no proprietary blobs, unlike Signal
What "proprietary blobs" does Signal have?
I'll also just add: it's probably not a good idea to use any modifications to an E2EE messenger unless you are comfortable with those privacy/security guarantees possibly being violated by the 3rd party code.
The only exception to this would be if I really trusted the goals of the 3rd party, like Graphene.
> What "proprietary blobs" does Signal have?
As they say in the Github readme, FCM and Google Maps.
FCM doesn't technically require a blob — it's just that Google wants you to think it does. I reverse engineered their library and it turned out to be a criminally over-engineered wrapper around two broadcast receivers. So, the Mastodon app is proudly the first app ever to both support FCM push notifications, and be 100% open-source.
>As they say in the Github readme, FCM and Google Maps.
Thanks, I didn't notice that. Reading this, I'm kind of surprised that Signal doesn't offer an OpenStreetMaps build as it seems like it'd be more inline with their philosophy.
The app doesn't even recognize geo:.. links, which makes degoogling rather hard.
Oo, do you have a link for your implementation? I will soon be looking at creating a library to support FCM (android push notifications) in Android apps written in Rust. And having a simpler interface with the OS (esp. if it therefore doesn't require building a non-syste library) would be incredibly helpful.
Looks like this is the first commit where it was added: https://github.com/mastodon/mastodon-android/commit/a0cbf0fa...
Thanks! It looks like that repo is GPL though, which I respect but isn't going to work for my usage (where I'm trying to build a generic UI toolkit that can be used by all sorts of applications including closed source ones).
It's just two broadcast receivers (one for receiving the push token, another for receiving actual notifications), and one broadcast sender to ask GSF to give you a token. This code is so trivial it's not even worth separating into a library.
Here's how you request a push token:
Here are the two receivers:Intent intent = new Intent("com.google.iid.TOKEN_REQUEST"); intent.setPackage("com.google.android.gms"); intent.putExtra("app", PendingIntent.getBroadcast(context, 0, new Intent(), PendingIntent.FLAG_IMMUTABLE)); intent.putExtra("sender", FCM_SENDER_ID); intent.putExtra("subtype", FCM_SENDER_ID); intent.putExtra("scope", "*"); intent.putExtra("kid", "|ID|1|"); context.sendBroadcast(intent);
The first one is where you get notifications. The parameters you sent from the server will simply be your intent extras.<receiver android:name=".PushNotificationReceiver" android:exported="true" android:permission="com.google.android.c2dm.permission.SEND"> <intent-filter> <action android:name="com.google.android.c2dm.intent.RECEIVE" /> </intent-filter> </receiver> <receiver android:name=".api.PushSubscriptionManager$RegistrationReceiver" android:exported="true" android:permission="com.google.android.c2dm.permission.SEND"> <intent-filter> <action android:name="com.google.android.c2dm.intent.REGISTRATION"/> </intent-filter> </receiver>The second one is where you get push tokens. There will be a "registration_id" extra string which is your token. It may start with "|ID|1|" (the "kid" parameter from the request, not quite sure what it does), in which case you need to remove that part.
You want to refresh your push token every time your app gets updated and also just periodically if you haven't done it in a while. I do it every 30 days.
If you need something permissively licensed, I believe microG also has implementation of the notification protocol: https://github.com/microg/GmsCore/blob/cb9be8f682d7649dae23b...
It's Apache 2.
Please consider supporting https://unifiedpush.org/ in addition to/instead of FCM.
I reverse-engineered the notification infrastructure in Android, but for me it was the desire to be able to use customer-provided Google API keys ("google-services.json").
The protocol itself was easy, but my problem was that Google Play Services have a special permission to exempt itself from power management. And more importantly, grant that permission temporarily to the individual apps when they have a notification. I don't think I ever found out how to work around this.
OTOH it's nice to have an alternative client. If E2EE messenger system is going to lock itself down hard, trying to "protect" itself from the user even harder than third party adversaries, then I personally see no point - might as well use Whatsapp.
I miss the times IM software respected, or at least didn't fight hard to defeat, the end-user's freedom to computing on their own device, which includes viewing and sending messages through whatever interface they see fit, including indirectly as part of a script/automation. But that was all before E2EE era, hell, before mobile dominance.
Stop being so ridiculous. You can criticize Signal (and there's plenty to critique) but that's just silly. What, should we also just use telegram where E2EE is off by default?> might as well use Whatsapp. - still scrapes metadata - run by company who's entire objective is to profile youYou know signal is open source, right? That's why Molly exists. They can run their own servers too.
Now I wish you could do both. Talk in both signal and the decentralized molly servers. I wish signal had a mesh like feature since it's way harder to snoop on conversations if you have to be physically near. I even wish Signal made the signal sticker site accessible from inside the app. There's tons of things they should do but let's not pretend that just because they're not perfect that we should use apps from a company whose motto might as well be "be evil".
> What, should we also just use telegram where E2EE is off by default?
There are plenty of others, all with their pros and cons.
Ultimately,the network effect is usually the hardest parameter to overcome.
Ironically, the only person who mentionned wanting to use signal instead of whatsapp in my network circle is my 71y old mother.
Firebase, GMS (Google Mobile Services). The Alphabet Corporation is part of many security and privacy conscious users' threat model, and these users aren't generally thrilled about leaking even limited message metadata like timing to their adversary, particularly when that adversary is known to cooperate with global passive adversaries.
There are actually two builds of Molly: Molly and Molly-FOSS. IIRC Molly uses regular Firebase, which can be faster and more reliable but comes with the above tradeoffs, while Molly-FOSS uses UnifiedPush.
Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code, but given you seem to trust GrapheneOS, it's worth noting that they've formally endorsed Molly: https://xcancel.com/GrapheneOS/status/1769277147569443309
> Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code
Also a great point :) And thank you for the reference.
UnifiedPush not works if you not use Molly exclusively on one device. So of you sync between Signal on Win desktop and Android device, your battery drain faster.
The Whisperfish [1] project (a Signal messenger for Sailfish OS) maintains an independent Signal client library written in Rust [2]. It works quite well - unless Signal decides to change their protocols or kick non-standard clients.
To be clear this library depends on libsignal.
This app's killer feature for me is that it's actually available on F-Droid, unlike its upstream.
Happy user for many years now, thanks for the support!
The killer feature for me is that molly-im also supports UnifiedPush for notifications instead of just websocket and FCM like upstream Signal.
APKs are available btw
been using this for years.. it doesn't have the GCM crap and hence works on de-googlified custom ROMs as well. Surprised how many people don't seem to know about it.
Self-updating too!
There is also a signal build in the fdroid repo of the Guardian Project
which is easily enabled in f-droid: settings > repositories > toggle it on
Good to know - that would make my life a little easier.
$50 says this is some nation state trying to sow seeds of discord into the Signal user base. Signal is actually becoming so well adopted most of my friends are on it now. Trying to convince them all to use yet another app is going to be pretty tough, especially since there isn’t really any decent evidence that Signal is insecure.
It is a Signal client that uses same servers (i.e Users of Molly and Signal's official app can message and call each othera normally).
One thing that would be really nice from a new user perspective would be to have some screenshots so people can visually see the interface. Just giving some "get new users" feedback, not criticizing at all.
Does it lock me out of the app like signal if I don't update the app every few weeks? I'm looking for an app that never needs to be updated; Oh, I guess that is email.
Enjoy getting pwned by zero-click exploits that have been widely patched elsewhere and disclosed publicly, I guess?
weird, I have never been pwned via email which has been updated 0 times in the last 20 years. I guess Signal is just so poorly made it needs to be constantly re-written every 2 weeks.
Email has been updated many times in the last 20 years. All of the major sender authentication protocols (SPF, DKIM, DMARC) were created and deployed over the last 20 years. Email is also famously insecure and lacking a standard way of managing encryption - so the reason you never see updates is because the features signal is changing do not exist in email at all.
You're running 2005 versions of your mail-daemon in prod?
Why do you want an app that never gets updated? You want bugs to persist and security issues to persist?
AFAIK signal only blocks due to security patches. Which it's on a much longer timeframe than a few weeks.
I think the distinction here is they want an app that never NEEDS to be updated, not one that never DOES get updates (which is fair – I'm happy if things just work and are not changed every 2 weeks).
For a security app, it's pretty rational to need to be updated. One of the most common patterns in basically every technological attack is to take a freshly discovered vulnerability and target devices that haven't been updated yet.
> multi-device
Can someone explain, is this different from adding (up to 5) devices to your Signal account? Are these devices all "primary" or something?
Signal's official Android app does not support being linked, only the iOS and desktop apps support that. This is why I use Molly.
I would ideally want to not have one device being the master and the rest linked to it (e.g. Element can do that for Matrix) but that might be a too big change. And as far as I know Molly does not try to solve that.
I just saw a blog post they’re working on this in the official app, though! Finally. Fingers crossed.
please include a screenshot of your app somewhere on your website or repo. why would I download an app if I don't even know what it looks like?
i use it only because it happens to have a convenient 'supply trust chain' on GrapheneOS: (built-in) App Store -> Accrescent[0] -> Molly (seems to ship the 'FOSS' version)
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 like the regular app
i wonder if the supply chain risk of having a second entity (that signs the apks!) involved is really worth it to anyone... hope signal can be published on Accrescent or similar someday :p
can you install fdroid from the graphene store? signal is available in there: https://news.ycombinator.com/item?id=46082592
To be clear, Signal is not available from F-Droid. The above link is about a fourth party publishing a Signal build in an f-droid-compatible repository.
What about the server portion? that's the thing I would like to have forked / open source.
Good news! https://github.com/signalapp/Signal-Server
But is there federation between instances of this and the official signal servers?
There will likely never be federation between Signal's official servers and any other servers. Signal introduces privacy features semiregularly; we all saw with Matrix how difficult that is in a highly-federated environment.
No. But iirc Molly can connect to a federated version. You just have to pick. It's one or the other
Well, obviously not. Official Signal does not support federation.
> Protects database
What database?
This page is clearly written for developers that are already familiar with it.
From this I can already predict this project is going nowhere.
>What database?
The local database used by Signal to organize every message, every contact, every profile photo, every attachment, every group, basically every dynamic piece of data you interact with in the app.
Signal is basically a UI layer for a database. The in-transit encryption is genuinely good enough to be textbook study material for cryptographers, but the at-rest encryption became a joke the moment they stopped using your pin to encrypt the local DB and requiring it to open the app.
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.
TL;DR of Molly is that it fixes/improves several of those security regressions (and adds new security features, like wiping RAM on db lock) while maintaining transparent compatibility with the official servers, and accordingly, other people using the regular Signal client.
Signal is an end-to-end encrypted messaging app. People continue to breathlessly mentioning the lack of database encryption as a problem, but that never made it a real security issue: its job is not, and has never been, dissuading an attacker who has local access to one of the ends, especially because that is an incoherent security boundary (just like the people who were very upset about Signal using the system keyboard which is potentially backdoored - if your phone is compromised, of course someone will be be able to read your Signal messages).
Database encryption isn't comparable to the keyboard drama. Protecting against malware in your keyboard can be done by using a different meyboard and is of course out of scope.
But if my phone gets taken and an exploit is used to get root access on it, I don't want the messages to be readable and there's nothing I can do about it. It's not like I can just use a different storage backend.
It's also a very simple solution - just let me set an encryption password. It's not an open-ended problem like protecting from malware running on the device when you're using it.
If someone has root access to your apparently unencrypted phone, then they can just launch the Signal app directly and it'll decrypt the database for them.
Which is to say this is an incoherent security boundary: you're not encrypting your phone's storage in a meaningful way, but planning to rely on entering a pin number every time you launch Signal to secure it? (Which in turn is also not secure because a pin is not secure without hardware able to enforce lock outs and tamper resistance...which in this scenario you just indicated have been bypassed).
Any modern Android is encrypted at rest, but if your phone is taken after first unlock, they get access to the plaintext storage. That's the attack vector.
A passphrase can be long, not just a short numeric PIN. It can be different from the phone unlock one. It could even be different for different chats.
Yes, but this was not about the database, really.
Isn't the phone filesystem encrypted?
Depends on quite a few other factors, but if someone with a GrayKey or Cellebrite appliance gets your phone, there's a good chance they can get in both in BFU and AFU states, even if locked. 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.
This is less true for fully patched GrapheneOS devices than it is for fully patched iOS and other Android devices, but this space is basically a constantly evolving cat and mouse game. We don't get a press release when GrayKey or Cellebrite develop a new zero day, so defense in depth can be helpful even for hardened platforms like GOS.
> 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.
As always, it depends on your threat model.
I use signal because I value my privacy and don't trust Facebook. Not because I'm an activist. So I'm in the target group for Signal's new behavior and I welcome it (especially since to use it to share personal information that I don't want Facebook or advertisers to get, I need my parents and in-laws to use it as well, so it must be user friendly enough).
I wish they continue moving forward in that direction by the way and allow shared pictures to be stored directly on the phone's main memory (or at least add an opt-in setting for that), because the security I get from it not being is zero and the usability suffers significantly.
You're absolutely right that the appropriate level of security does depend on someone's threat model, but I do want to point out that you don't need to be an activist to benefit from privacy.
I'm a really big fan of the airport bathroom analogy. When you use the restroom in the airport, you close the stall door behind you.
You're not doing anything wrong, you have nothing to hide, and everyone knows what you're doing. But you take actions to preserve your privacy anyway, and that's good.
Everyone deserves privacy, and the psychological comfort that comes with it. Dance like nobody's watching, encrypt like everyone is :)
That's not the point the GP was making. They meant "I'd rather give up a bit of privacy for a big increase in usability, as I'm not in the group of people that needs extreme privacy". I happen to agree with them, I get more benefit from a fairly-private messaging app my friends can use than from an extremely-private messaging app nobody in my social circle can use.
> I get more benefit from a fairly-private messaging app my friends can use than from an extremely-private messaging app nobody in my social circle can use.
This is a much better way of saying what I wanted, thank you.
Meh, most phones have full disk encryption. For the average person, encryption at rest in signal doesn't provide very much.
I mentioned some of the pragmatic constraints of fully trusting typical Android / iOS FDE to fully protect the confidentiality of Signal messages in another comment above that I would encourage you to read.
That said, Molly definitely isn't designed for the average person's threat model, that's totally true, but it's also worth noting that just because someone isn't aware of a certain risk in their threat model, that doesn't mean they will never benefit from taking steps to proactively protect themselves from that risk.
IMO, security and privacy are best conceptualized not as binary properties where you either have it or you don't, but rather as journeys, where every step in the right direction is a good one.
I'd always encourage everyone to question their own assumptions about security and never stop learning, it's good for your brain even if you ultimately decide that you don't want to accept the tradeoffs of an approach like the one Molly takes towards at-rest encryption.
I assume its your comment about if the phone is compromised they still need to bruteforce the signal db.
I find that unconvincing. If your phone is hacked, your phone is hacked. I think its bad to make assumptions that an attacker can compromise your phone but not log keystrokes. I'm not super familiar with state of the art of phone malware and countermeasures, but i think anything trying to be secure in the face of a compromised platform is like trying to get toothpaste back in the tube.
> it's also worth noting that just because someone isn't aware of a certain risk in their threat model, that doesn't mean they will never benefit from taking steps to proactively protect themselves from that risk.
Threat models are just as much about ensuring you have all your bases covered as ensuring you don't spend effort in counterproductive ways.
> IMO, security and privacy are best conceptualized not as binary properties where you either have it or you don't
I agree. I think security is relative to the threat you are trying to defend against. There are no absolutes.
> but rather as journeys, where every step in the right direction is a good one.
Here is where i disagree. Just because you take a step does not mean you are walking forward.
A poorly thought out security measure can have negative impacts on overall system security.
My main grievances with the Signal app are mainly centered around UI and UX, and features. Without trying to be mean, I think it's plain ugly and clunky. Features like live location or persistent multi-device messages etc will probably never be implemented with the current strategy of Signal.
The fact that this "improved" version does not show a single screenshot of the UI on their own website, signals to me (pun intended) that this app will address none of my wishes.
I searched so long for a single screenshot, looking at the app stores (in my browser) and Github with no success.
It really is weird not to show a single screenshot when the 4th listed feature is design ("Material You | Extra theme that follows your device palette").
Really? Signal does everything I want from a messaging app. I can't imagine what could be better about its GUI. But I'm no GUI designer.
Seems interesting, but are there any screenshots?
it looks just like signal with a purple theme
An iOS version would be lovely in the future!
So, you still need a phone number? It doesn’t mention anywhere that’s not a requirement
I'd just wish Molly had a live-tracking feature, similar to Telegram-FOSS.
But not sure if even the upstream Signal client has this.
Why would privacy apps have this feature?
Extra privacy features and named after UK slang for MDMA, hrm.
Molly is the American slang, Mandy is the UK slang for MDMA.
https://github.com/mollyim/mollyim-android/blob/285650e38613...
I'm pretty unconvinced that this is a sane or useful thing to do.
Is there a specific part you're referring to? For those of us who don't read or write Java frequently, it's not clear whether it's worth it to spend time reading the code without at least having some sense of whether you might be making a compelling point or not.
You need to be more specific. Lots of security-conscious apps wipe their memory. Memory contains, among other things, the decrypted text and private keys for the app. RAM is known to hold data longer than you'd want, and it can be swapped out onto persistent storage like the internal SSD. If you don't know that wiping memory is a basic and common feature for apps like this, then you're not qualified to have an opinion. Now if you think wiping the memory is ineffective, inefficient, or superceded by a bigger issue, then we might have something to talk about.
What are the advantages of this?
It supports linking two Android devices.
this is why molly.im was a lifesaver for me.. trying to move a family member from VIBER to SIGNAL and ran into the annoying roadblock of not being able to link an Android tablet to an Android phone like Viber can - but molly does it fine.
This is huge. There's been 3rd party Signal library for this for years -- and for some reason I can't determine, the developers have opted NOT to do this.
Yeah, the Signal team's roadmap seems very strange to me as an outsider. There are some low hanging fruits which they just seem to refuse to fix.
And given how in this case Molly could fix it it cannot have been that hard to fix.
What is the point of this? Just use the regular signal app. It may be more safe, but are the developers trustworthy enough?
It has various improvements and you can also use your private signal server. I believe it also lets you backup your data! How about that for digital sovereignty.
Signal also lets you backup your data, for a small subscription
Wasn't aware you could run your own signal server. How do you go about setting one up?
Now we just need to drop the phone number requirements and signal would be "done" for all practical purposes
Can't wait to see how the lawsuit goes. Moxie is infamously protective of Signal.
Moxie hasn't been affiliated with Signal for years. He stepped back years ago.
The Signal Android app is AGPL licensed. What should the lawsuit be about?