TextSecure
TextSecure copied to clipboard
JavaJens
Make FORCE_WEBSOCKETS option configurable at runtime (not build-time)
This is simple change that will make it possible to use WebSocket instead of GCM even on devices which have Google Play Services installed. Now it is needed to maintain two builds (one with FORCE_WEBSOCKETS build-time option enabled and one without it) for this purposes, this would make only one universal build sufficient.
You will find the Force WebSocket option in Advanced Settings.
Why should users ever want to switch? Imho that is a developer only option and should therefore not be exposed to users.
@schachmat I disagree. I want to have one universal LibreSignal build useful on both GCM/non-GCM devices and I want to be able to change this setting at runtime (without reinstallation) to compare battery stats, try it on microG instead of Google Play Services, etc.
Option is hidden in Advanced settings menu, so it should not confuse users. And I am really not a fan of removing options and dumbing down apps (iOS / GNOME style)...
Since it is one of the basic ideas of TextSecure to focus on simplicity, I think giving the user an option to change the message delivery channel would not help being accepted upstream. Reading WS issue tracker, moxie is strongly against additional user options. IMHO, developer related (low-level) options should stay in a developer environment.
@art1fa Well, like I said above I don't agree with this. And seeing Moxies attitude, I don't believe anymore that WebSocket support will ever get merged upstream. But of course final decision is on @JavaJens ;-)
@xmikos @JavaJens @art1fa Some users who have GAPPS installed on their phones would like to force the use of WebSocket so that Google (GCM) doesn't track when and from where there are using LibreSignal/Signal/TextSecure.
Maybe you can take a look at the discussion in https://github.com/JavaJens/TextSecure/pull/28 This PR somehow got lost in the fleet of mails I got around the Signal release...
I got to be honest, I don't know what to do with this. Maybe, @f41c0r as the steady contributor of upstream can weigh in. I just started this fork because I though it should be done. But I don't use it or (sadly) actively work on it. So I don't know if I am the right one to make any calls.
@JavaJens People are using your fork because: a) They don't have gapps (no PlayStore and no GCM). b) They have gapps included in their ROM or installed, but they don't want to use them, or don't want to use GCM (as I said in my previous comment).
I agree with @art1fa that moxie will not want to include this commit, but since moxie will not include WebSocket in Signal and doesn't want to put his app on F-droid (and doesn't want any forks under the name Signal), I don't see any reason why this PR is ignored.
@art1fa @JavaJens All conversations about WebSocket and Signal on F-droid are locked and when I opened a new one, it was almost immediately closed by moxie with a strange comment. https://github.com/WhisperSystems/Signal-Android/issues/4430
I still have hope that we can get merged back into upstream in some fashion. I don't have a strong feeling one way or another on this PR. I don't know what Moxie would think of this feature, but I do think it is more convenient for end users interested in this fork than the current status quo.
On the other hand, if moving this into a preference means you can't set that preference prior to registration with the TS service, then I'm not a fan of this PR. In older versions of TS, you could not register with the service and only use it for SMS/MMS - presumably then you could flip that preference, and then register with the service. I'd want to check they kept that functionality. Even if they did, is that really intuitive enough of a process as opposed to compiling from source or specifically installing a websockets only apk.
@f41c0r I think this fork will never be merged upstream. Moxie doesn't want to merge it and doesn't even want to explain why.
He only explained why he didn't want Signal to be distributed outside of the PlayStore, but I'm not convinced by his explanation. https://github.com/WhisperSystems/Signal-Android/issues/127
@mimi89999 I don't think your judgment is fair here. I am not too certain that this will eventually be merged upstream either, but to be fair: we haven't even tried. Furthermore Websockets and F-Droid are two different things.
@JavaJens Moxie will not want to merge it upstream because the only visible advantage of using WebSocket is not using Google... In #22 we didn't prove any performance advantage...
@JavaJens Maybe we could move the discussion about this fork being merged upstream somewhere else?
@mimi89999 why are you always speaking for moxie? Are you his ambassador extraordinary and plenipotentiary? I don't think so.
Why are you referencing #22 with a "we"? I cannot see any contribution or help from you there… All I see is repeated double-posted lamenting about already known facts and the status quo without any sign of new enlightenment or proposal.
If you think a little bit, maybe you will understand the answer from https://github.com/WhisperSystems/Signal-Android/issues/4430
I give you a hint: You are annoying people.
What I wanted to say is that it would be great to allow users to change from GCM to WebSocket and vice-versa (for various reason: privacy, comparing performance) without having to rebuild the app.
I came here to ask for a feature to automatically switch to websocket if gcm-server is not available for too long (eg. 15 Minutes). But reading this issue I guess this would not be welcome…
@jensMF I think this is a separate issue and could (potentially) be better suited at upstream as most(?) people here, probably don't even habe GCM. However I think the main problem lies somewhere else. AFAIK there is no way to programmatically detect if the GCM server is available, but I just might not be that into the GCM API.
I use Signal Jolla Edition, which is built off of this code, and would definitely love to see a clearer situation in these builds. I recently heard of LibreSignal which afaict (without caring to look) is just a rebuild of upstream to circumvent distribution.
Now that websockets are a real deal in the server, there's no actual reason (apart from "we want to distribute only on Google and depend heavily on Google") not to merge this.
Forking is a good way to develop, test and polish new features before having them merged and IMO having websockets as a toggle makes merging much more plausible, and maintainership of the fork probably easier, and at least the situation clearer.
As long as there is no official version with websocket support, I second this pull, as I'd more likely would test a version that has this switch than one that does not. I agree this is perhaps not intended to ever get merged upstream, but for the Libre build this is a great thing to do (also in the light to not need to build and maintain 2 branches anymore).
@xmikos You are the one who currently builds and publishes websocket LibreSignal, right? Have you another branch that you rebase to this one or are you adding own patches? I'd love to get some insight how we could streamline the process and make it a bit more verifyable.
Perhaps you also could solve the merge conflicts, so we could get some progress here :)?
@JavaJens What are you thinking?
@Diapolo Yes, I am maintainer of https://fdroid.eutopia.cz repository. I don't have some private fork, I am building it always directly from this JavaJens GitHub repo (I only do automated patching that renames strings from Signal to LibreSignal), you can find my build scripts here: https://github.com/xmikos/fdroiddata
I always try to review diffs between previous version and latest version before publishing builds in my repository.
@Diapolo But I am considering creating independent LibreSignal repository with more patches (like this one and much more importantly bringing back ZRTP key continuity check - see issue https://github.com/JavaJens/TextSecure/issues/44 - ZRTP key continuity check removed from Signal/RedPhone). Only didn't have time for it yet...
@xmikos Thanks for your explanation :). Thumbs up for your work, you're doing with this. As you may have seen I'm starting to get interested in this fork.