Create proper pull request to add LibreSignal's WebSocket support to OWS Signal

[vanitasvitae]

Title sais it all. Some work was done before in https://github.com/WhisperSystems/Signal-Android/issues/1000 but that needs at least to be polished up.

[vanitasvitae]

Link to bountysource: https://www.bountysource.com/issues/35722527-create-proper-pull-request-to-add-libresignal-s-websocket-support-to-ows-signal

[vanitasvitae]

To make it clear for people, who did not read #37: The pull request must be of a good quality so it will be accepted by @moxie0. https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-226646872

[BengaloBongali]

I'm really happy to read this. 2 questions:

1. Will LibreSignal work until WebSocket support was added to Signal?
2. How will "WebSocket-Signal" be distributed (without Play)?

[vanitasvitae]

1) If the PR is there in the near future :) (Libre)Signal has a built-in "time bomb" that warns the user whenever the version is too old. I believe this was the last version of LibreSignal.

2) There is no "WebSocketSignal". There will only be Signal. OWS will not allow distributions outside Google Play until some more points are addressed (eg. crashlogs, user statistics etc)

I have to say, that I'm neither part of the LibreSignal team, nor of OWS. I'm just a user that wants to use Signal without Google Services :)

[BengaloBongali]

(Libre)Signal has a built-in "time bomb" that warns the user whenever the version is too old.

Will it stop working, too?

So the only way to get Signal (with WebSocket) on a phone is and will be https://fdroid.eutopia.cz/?

[vanitasvitae]

Will it stop working, too?

The PR should have no negative impacts on Signals behavior.

So the only way to get Signal (with WebSocket) on a phone is and will be https://fdroid.eutopia.cz/?

If the PR gets merged, you can use OWS Signal. If you don't have Google Play you can either build it yourselve or use the independent build from https://fdroid.eutopia.cz/

There will be no more need for LibreSignal.

[BengaloBongali]

Thanks for your answers!

The PR should have no negative impacts on Signals behavior.

I meant whether LibreSignal will stop working (before there is WebSocket support in Signal) or is the warning of using an old version all to come? I'm changing phones right now (from one with Google to one without) and I'd like to know whether I can just use LibreSignal now and change to Signal with WebSocket when it's done or I have to think about something in the meantime.

[vanitasvitae]

That depends on how quick the PR is ready.

[bonanza123]

As there doesn't seem to be much progress with this, we maybe should think about hiring a professional developer. We could try to crowd-source the money, but I guess an issue that we need an estimate of the approx. costs for this. What do you think? Do you have other ideas how to motivate devs to help out here?

[vanitasvitae]

I don't think that'll work out. Most Libresignal devs have abandoned the project and switched to other ones. I can fully understand that there is no more motivation to contribute to Signal.

[bonanza123]

I didn't mean hiring existing project members, but external that we just hire for this PR. If this websocket problem is solved, the current project members may be more interested again this project.

[vanitasvitae]

Of course you can try it, but I doubt that there will be much support. There are a lot of other nice projects that have a much more open attitude towards forks...

[bonanza123]

If already you are so sceptically ... ;-) But what those (real) alternatives to Signal?

[vanitasvitae]

To be clear, in no way I want to keep you from doing anything :) I'd really appreciate Signal supporting websockets natively. That would solve many issues and if you think you want to do something to achieve that goal, go ahead, I wish you all luck :)

Personally I have switched over to use conversations + OMEMO. Together with Gajim + Gajim-omemo that enables chatting on Linux + Android. The next month or so ChatSecure-iOS will join in providing OMEMO under iOS.

[mimi89999]

@bonaza123 Please try Conversations and Gajim with an XMPP server, that supports all Conversations XEPs. They are really great!

I could try to work on that PR, but I doubt it makes much sense...

[mimi89999]

The only thing that needs to be added is checking for the presence of GMS core (~GCM client) and if it isn't found, Signal should fail to WebSocket (which is implemented in LibreSignal thanks to @JavaJens)

[paride]

What would make sense, in my opinion, is:

• Implementing the WebSocket fallback mechanism;
• Removing the telephony code (RedPhone), as the server is non-free;
• Adding a configuration field where the user can specify the server to use;
• Compiling it with microg gmscore (or removing the GCM stuff altogether).

This would be a generic, "unbranded" client for the Signal server, working with or without gapps (and, if they're present, using the free gmscore library), distribuibile on f-droid, and encouraging the independent deployment of Signal servers and federated networks. It's not easy to setup a Signal server, but it's possible and the procedure is somehow documented.

Removing the RedPhone code (or completely disabling it) is a bold move to show that the generic client is not intended to be used with the official OWS server, but with really free deployments. The user is still free to decide to break the OWS server ToS or not.

[mimi89999]

1. Did I say the TLS cert is embeded in the app?
2. Moxie won't like the fact that some users using unofficial clients can use their servers.
3. No federation. It will be very hard for unofficial servers to federate among them self and the official server won't federate. Without federation it doesn't make much sense since people, that you potentially want to contact other than your closest friends probably won't be using the same server...
4. Why to do that since there is XMPP with great clients supporting good encryption: OMEMO

[paride]

I didn't know about the TLS cert, and I agree in that federation would be difficult, and impossible with the official server.

It's true that xmpp+omemo works well, but it's also a pity that a really good piece of libre software is "wasted" like this. Another point is that xmpp doesn't allow to register with the phone number and no password, which is what the average user expects nowadays.

[moxie0]

Did I say the TLS cert is embeded in the app?

You can embed your own trust root into the app, or include a CA trust store instead and use CA certs.

No federation. It will be very hard for unofficial servers to federate among them self and the official server won't federate. Without federation it doesn't make much sense since people, that you potentially want to contact other than your closest friends probably won't be using the same server...

Both the Signal app and the Signal server already support federation, so it should be pretty simple for you to do.

Just because I don't believe this is a viable or desirable strategy doesn't mean that others shouldn't try. I'd love it if someone proved me wrong, let me know if you need help setting anything up.

[Heimdal300]

It would be really nice to have the offical Signal app to support websocket before the last LibreSignal-websocket version runs out. I think apps like conversations or kontalk are not as widespread and advanced as signal. If some starts a crowdfunding I will definitively support it. Please get through it and make the Signal app ready for websocket.

[vanitasvitae]

@Heimdal300 you can already go ahead and support the bounty source on this issue ;)

[Heimdal300]

@vanitasvitae Done. Thank you for this hint! For others here is the link: https://www.bountysource.com/issues/35722527-create-proper-pull-request-to-add-libresignal-s-websocket-support-to-ows-signal

[paride]

If this ever reaches upstream I'll consider setting up an independent Signal server to be used with a rebranded Signal client. The service would allow 3rd party clients and would be fairly open to federation.

What worries me mostly is the cost of the registration SMS messages from Twilio. This cost needs to be somehow estimated and donations asked accordingly.

While I think I can manage the server stuff, maintaining an Android app is not for me, so this is why I'll seriously consider working on this only if the official client could be used almost unmodified (i.e., gets the websockes patch merged). In this way the only things that would remain to be modified are:

• The branding;
• Disabling RedPhone (easy).

[ghost]

Link to discussion on the OWS community forum: https://whispersystems.discoursehosting.net/t/websocket-version-without-gcm-everyone-happy/

[mimi89999]

@moxie0

let me know if you need help setting anything up.

RedPhone server source or doc would help designing GCM-less signaling.

[ale5000-git]

Just a question, instead of infinite discussions wouldn't be better to just create a pull request to add WebSocket to main Signal and discuss everything else just after the code is merged?

This discussion just seems too much theoretical.

[mimi89999]

@ale5000-git There was already https://github.com/WhisperSystems/Signal-Android/issues/1000 ...

[ale5000-git]

But it is an issue, not a pull request.

[vanitasvitae]

https://github.com/WhisperSystems/Signal-Android/pull/1960

[mimi89999]

@moxie0 @eightbitkid Just reminding, that I am blocked in the Signal repo, so can't do anything on that...

[vanitasvitae]

@mimi89999 Why that? @eightbitkid Great work!

[mimi89999]

@eightbitkid @moxie0 I see 3 possibilities:

1. The RedPhone (voice) server implements WebSockets and we register on that server using WebSockets. Of course, then we will have to keep two connections (one to Signal and one to RedPhone). That will ~doubble LibreSignal's/Signal WebSocket battery usage.

2. We do signaling over Signal. That requires even bigger changes to the server.

3. We take the code from microg so that we can talk to GCM servers.

[anarcat]

On 2016-12-18 16:33:42, Michel Le Bihan wrote:

1. The RedPhone (voice) server implements WebSockets and we register on that server using WebSockets. Of course, then we will have to keep two connections (one to Signal and one to RedPhone). That will ~doubble LibreSignal's/Signal WebSocket battery usage.

that seems like too big of an overhead.

2. We do signaling over Signal. That requires even bigger changes to the server.

i would assume this would be the proper way.

both of those require access to the RedPhone server source code, which is not currently public, AFAIK.

3. We take the code from microg so that we can talk to GCM servers.

that is already possible right now - no need to patch signal.

[mimi89999]

1. The RedPhone (voice) server implements WebSockets and we register on that server using WebSockets. Of course, then we will have to keep two connections (one to Signal and one to RedPhone). That will ~doubble LibreSignal's/Signal WebSocket battery usage.

that seems like too big of an overhead.

I agree. We should avoid that option.

2. We do signaling over Signal. That requires even bigger changes to the server.

i would assume this would be the proper way.

The preferred, but I don't know if OWS will want to do that...

both of those require access to the RedPhone server source code, which is not currently public, AFAIK.

3. We take the code from microg so that we can talk to GCM servers.

that is already possible right now - no need to patch signal.

Right now you need signature spoofing for it to work. Only (very) advanced users know how to do this....

In my suggestion, the code would be directly in Signal, so no need for microg apps and signature spoofing.

[relyt29]

I support option 1. I have not seen signal having any particularly bad or aggressive battery usage, and I have been using it for months. Opening two connections instead of one is not such a terrible overhead.

Option 2 is not realistic.

Option 3 is bad. Grabbing MicroG code and embedding it in Signal may allow someone to run free software, but it has the effect of causing the phone to poll google servers for updates. So your software is free instead of nonfree - who cares, you're still phoning home to big brother Google, sending requests to their servers on a regular basis.

[mimi89999]

@eightbitkid As for Doze, I doubt, that Google will have a problem with Signal escaping it since it is only when Play Services are not available.

[mimi89999]

@eightbitkid Could you ping @moxie0 under that issue to unblock me, please?

[thestinger]

@eightbitkid We'll happily host a default-enabled F-Droid repository with this for CopperheadOS whether or not it's accepted, but we need a straightforward way to build and host it. It also needs to be rebranded from Signal to something without Signal in the name. It would be nice if the server was made configurable at runtime too but that's not a requirement for starting out. I would want to keep it as a rebased set of patches on top of the latest stable Signal release, to allow for easy upstreaming it at any point.

If you can help us set that up, I can take care of maintaining it as a clean set of patches indefinitely.

[paride]

@thestinger you're surely aware of the fact that moxie opposes third party clients using their servers...

[thestinger]

I won't be using their servers, just hosting a modified build of a GPL3 project with their trademark stripped from it. I don't see any legal issues with that. Support for runtime server configuration would be nice, but they choose not to provide that upstream and only supporting their hard-wired server is not a blocker for this to be useful.

[thestinger]

Some reading material: https://nplusonemag.com/issue-19/essays/chat-wars/. I'd suggest server-side SafetyNet checks as a technical mechanism to forbid non-stock Android if that's the intent. SafetyNet isn't very good yet, but Google will probably end up turning it into full blown remote attestation over time. Easiest to piggyback on their DRM vs. making it from scratch.

[thestinger]

Alright, just need to generate an F-Droid repository.

[mimi89999]

@thestinger Maybe XMPP with OMEMO would be better...

[thestinger]

CopperheadOS will continue recommending Conversations. It needs an option that's compatible with Signal though.

[thestinger]

Reality: people have many contacts with Signal, they have trouble moving them to Conversations. It's by far the number one complaint we get. Nothing else compares. It's the main reason for people wanting Play Services or microG, which isn't happening. So this is a requirement.

The usage guide can be extended to offer this as a fallback option, with caveats explained (drawbacks of being tied to a phone number, poor battery life vs. Conversations at the moment, etc.) and with using Conversations OMEMO whenever possible being highly recommended.

[mimi89999]

@thestinger Then I could continue updating LS and rebrand it, if you need that...

[thestinger]

I really don't mind maintaining it. I already have it built and in an F-Droid repository. Needed the F-Droid repository anyway, so this works well as a test case. Just need proper production metadata generated for the repository and rebranding.

[thestinger]

Also I'd like to keep the changes rebased since it's not really going to be a separate project but rather just maintenance of patches that should land in Signal. I am assuming that they are going to land in Signal, but I'm tired of waiting, so this will be the solution until then.

[h-2]

@thestinger I expect more f-droid users will be interested in this. It appears moxie has had some change of heart/mind at least or he wouldn't be considering accepting the PR. So maybe we shouldn't rush the entire thing right now, and just wait a little? Since official f-droid now accepts upstream signatures if the builds are reproducible, moxies' main concern about f-droid has been addressed. But like I said, I think maybe we wait for the acceptance patches, and then bring up f-droid again? You could still go for your solution if that fails, and I think we have until end of january until the last LibreSignal build expires...