For reference, here is an outdated comparison chart by the EFF:
They say they are working on an update, but the status is the same for a few months now. Optimistically, that means the update will be out soon. 
I’m the project lead for Matrix (and Riot) and can categorically state we are not using user data for profit on Riot, and never will. The Riot privacy policy is indeed too heavy and scary atm but it boils down to “we collect information required to actually power communication; we don’t allow illegality or abuse; we keep the option to use analytics to see what features of Riot people use and so how to focus our dev effort”, which seems pretty reasonable to me. It also applies only to the default matrix dot org homeserver; if you use a different one (eg a hypothetical Purism one) then it can have whatever privacy policy it likes. More info over at About matrix and riot.
Personally, I rate the freedom to select and trust your preferred service provider as high as the need for privacy, which is why Matrix exists (rather than just using Signal). But OWS release a Signal app for the Librem5 you are of course welcome to use it. (Whereas with Matrix you are not beholden to OWS choosing to release an app for the platform).
11 Likes
I do not think this is enough. I am using Signal as a Chromium-plugin. It has to be associated via a QR-code with a phone using the Android or iOS app to be used. I assume the same is true for the Desktop App, so some further hacking is needed for a comfortable solution (you might install Signal for Android on Anbox on a GNU/Linux system, but this would be quite some effort just to use Signal on your phone).
I’d also really like to see Signal on the Librem 5. Signal may have its flaws (as in “it is not perfect”), but its the most privacy aware and secure messenger that you can even make your parents/less computer literate friends install and communicate with them. I do not see this level of security, privacy and ease of use with other applications so far. And in the end you also want to use your phone for communication.
While I appreciate the effort put in the matrix/riot project, at the moment, I see it as quite a different application. It’s fairly easy to set up on your own server, however encryption in Riot is still in a testing phase (imho it shouldn’t even allow for unencrypted anything in the first place) and it relies heavily on storing data/messages on the/a server. Signal, on the other hand, tries to store as little as possible on the server. The downside of course is a non universally accessible history.
All in all I see matrix/riot as a nice replacement for discord/irc and anything targeting multi-user chats, but less as an one-on-one instant messenger/sms replacement.
Please make Signal work on the Librem 5.
1 Like
Hi @Raven,
I think you already noticed it but I posted some information regarding the possibility to write a Signal client for the Librem 5.
I I might find some time to spend into it soon, although it would not go as initially planned. A first version could be written in Java, using as much code as possible provided by Open Whisper Systems and/or the Signal Foundation. A better version could come later in C or C++.
Purism has also already set-up a developer portal for the Librem 5. It is also up to us to enrich the platform with Free Libre Open Source Software 
1 Like
Yes I noticed your post, but somehow after writing here.
I appreciate the incentive, but I think should be backed by OWS somehow. At least having their okay would be nice, as they were not really endorsing any third party applications in the past.
Technically it’d only require an extended desktop client, allowing for activation of phone numbers.
I definitely agree with you. I tried to reach them on Twitter and on their (unofficial) community forums. Several people tried to reach Moxie through Github issues. Moxie has a lot to skim through, and quickly closed the issue as he thought PureOS was yet another Android ROM.
I believe the best to do in the meantime is:
- Use as much Signal code as possible and as little extra code as possible to stay as close as we can to the client they intended to write
- Explicitly mention that this client is not supported in any way by Signal
This should be enough to start peaceful discussions regarding how we someone/me can work together without causing them issues
Be assured that if I could have stood out of all the noise around them before having them noticing an existing client, I would have!
EDIT: clarified that this is a project of my own and does not involve Purism responsibility
What about facilitating Conversations (FOSS) as chat app within Librem5?
1 Like
Conversations is FLOSS, but based on the Android framework. So as soon as the device will be Anbox-enabled, Conversations will also work. However, it might be easier to adapt Gajim (which supports OMEMO) to be usable on the Librem 5.
I mean if you’re really paranoid about privacy there’s other Linux messengers out there that are totally zero-access encrypted and decentralized. Check out some at Prism Break. I just don’t use them because:
A: Decentralization is good for privacy, bad for convenience/usability (no offline messaging, etc… you’re essentially going back to the days of simple IRC).
But Wire is basically the good of encryption and all, without decentralization, so I favored that a bit.
B: Nobody else I know uses them.
B is really the main issue. Nobody uses them, and what’s the sense in having it if nobody uses them? If I have a buddy I’m trying to keep top-secret shit with, it’s great since we’ll both use it and know what we’re doing. But since I don’t have any such thing going on… yeah, these things ain’t the most useful.
And this is why even though I’m a security/privacy nut, I still have a Windows computer and still have Skype & Discord… sigh… someitmes it seems to keep secure and private, you have to just not have any social life. And trust me, I’m damn close, but I ain’t totally ground-zero with it at least.
I think the next big step for these applications is to get enough people using them that using them starts to make sense. I know it’s kind-of a self-dependent problem though, that first big influx of users is needed.
2 Likes
There is a good program for XMPP on Gnome Desktop, it’s named Dino-im, it’s not ready yet but looks cool and it’s improving.
Here is a link to an already existing stand alone Signal app for Ubuntu Touch.
Anyone want to talk to this guy and see what he can do for the project?
https://open.uappexplorer.com/app/textsecure.nanuc
Info:
Author: Aaron Kimmig
Packager/Publisher: Aaron
Support: https://github.com/nanu-c/textsecure-qml/issues
Source: https://github.com/nanu-c/textsecure-qml
License: GNU GPL v3
Hi @Seven,
I already investigate porting a Signal app for the Librem 5 using their guidelines
Basically that would be a client based on AsmaK’s signal-cli, using D-Bus signals and methods to be fully integrated into PureOS mobile Features. That would most probably be shipped in a Flatpack.
There only are a few methods to write to complete the D-Bus support, plus probably a bit of rewiring when the Features specifications are done
1 Like
Hi Thib,
So how much effort would this take overall?
Not much actually, you can alreay send and receive messages and group messages using the daemon and D-Bus.
A few methods are left to add in this interface and in this class. I conctacted AsamK who’s okay with his project being used as a base for the Librem 5 Signal client. Moxie is aware of signal-cli and seems not to have done anything to stop it.
The whole shipping issue is different though. It is not technically complicated, but Moxie is against a packaging of signal-cli’s dependencies as .deb packages.
Any reason why Moxie is against the packaging?
Well I wouldn’t want to make things difficult lol. I did make another post offering an alternative. Let me know what you think
Is the encryption done in the Java layer? If so, the traffic is in the clear on dbus, which is not ideal.
Hi @fabrice,
Yes the encryption is done in the Java layer.
I am not a DBus expert, especially regarding security issues.
That said, there are two security elements that seem reasonable to me:
- The bus used by the daemon will be session bus, and not system bus
- The policy regarding the signals and methods will be deny-by-default and allowed only for the user who needs to access such information. In the context of an integration with the Librem 5, I can’t say yet which user will be used by the Features frontend. See dbus doc, policy section for more information
If you think of anything that would help harden the application, please speak