Sorry to file this as a bug report -- after my original bug report was closed, as suggested there I posted on the Signal User Community forums and filed a pull request in May 2020, but haven't received a response and don't know how else to reliably get in contact with the team.
As per the User Community discussion, I have written some patches to Signal that stub out Google Play Services, Firebase Cloud Messaging and Machine Learning code, so Signal can build and run without these libraries, connecting via WebSocket. I mentioned this on the F-Droid forums and users were receptive to the idea of distributing a Signal build there that meets their FOSS requirements, however this has never worked out in the past; the last time this was mentioned Greyson indicated signing builds would be a holdup.
So, which approach would the Signal team prefer?
In any case, could Signal please merge the patch to remove a few unnecessary calls to GMS APIs? They're all one-line tweaks (usually using Signal's existing Util library code e.g. hex conversion) and that would make maintenance easier! I've signed the CLA; the best source is the latest branch on my GitHub with -FOSS in the name (currently 4.69.6.0-FOSS). Thanks :).
If it was up to me I would simply remove all ML code and features. Face recognition is not secure anyway as a picture could be used to trick it (I never tried Signal so I don't know what the ML is used for besides that)
Hey there! Just some background on the website release: it was never intended to be completely free of any Google Play dependencies -- instead, all our builds have a fallback such that during registration, if we detect there's no Play Services, we will fallback to using a websocket for notifications. Using FCM for notification delivery still provides the most reliable user experience and is something we'd prefer to use if the user has Play Services available on their device.
Concerning F-Droid, we already providing an auto-updating APK directly from our site, and we really don't want forked versions of the app maintained by other parties connecting to our servers. Not only could the users using the forked version have a subpar experience, but the people they're talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn't support). I know you say you'd advocate for a build expiry, but you know how things go. Of course you have our full support if you'd like to fork Signal, name it something else, and use your own servers.
I think the rest of the discussion can happen on #9644. Thanks!
Hi @greyson-signal , I've force-pushed the patch in the pull request to just the utility function removal, thanks if you can merge that for now.
Most helpful comment
Hey there! Just some background on the website release: it was never intended to be completely free of any Google Play dependencies -- instead, all our builds have a fallback such that during registration, if we detect there's no Play Services, we will fallback to using a websocket for notifications. Using FCM for notification delivery still provides the most reliable user experience and is something we'd prefer to use if the user has Play Services available on their device.
Concerning F-Droid, we already providing an auto-updating APK directly from our site, and we really don't want forked versions of the app maintained by other parties connecting to our servers. Not only could the users using the forked version have a subpar experience, but the people they're talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn't support). I know you say you'd advocate for a build expiry, but you know how things go. Of course you have our full support if you'd like to fork Signal, name it something else, and use your own servers.
I think the rest of the discussion can happen on #9644. Thanks!