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.
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.
Here's how you request a push token:
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);
<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.
It's Apache 2.
Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.
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.
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.
> might as well use Whatsapp.
- still scrapes metadata
- run by company who's entire objective is to profile you
You 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".
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.
> - run by company who's entire objective is to profile you
And? Pick your poison. Being profiled by Meta isn't high enough on my threat board to be worth switching to E2EE as a countermeasure; in fact, I only use E2EE because Meta forced it on me with Whatsapp (new network effects) and by enabling it in Messenger (old network effects).
But that's besides the point. The point is, I did not expect such an alignment of outcomes between user-hostile corporations and grassroots OSS developers, as both fight to saturate the IM space with network effects-driven apps that disenfranchise end users "because security".
I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification? All more ways to protect the integrity of the network and ensure the user isn't accidentally stripping E2EE by doing something silly like perusing their messages in ways not prescribed by the developer?
> What, should we also just use telegram where E2EE is off by default?
I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).
> I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification?
But does Signal comply with government warrants? Yes, absolutely. But they don't get many requests because they designed their program to assume Signal is an adversary to the user[2]
> I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).
[0] https://signal.org/blog/uk-online-safety-bill/
[2] https://signal.org/bigbrother/
[3] For anyone interested https://news.ycombinator.com/leaders
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
Also a great point :) And thank you for the reference.
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.