It comes with GNOME and Flatpak. There is already a menu in the GNOME settings that allows you to manage access to the microphone, camera and location.
1 Like
4 Likes
FWIW the Signal Electron client is already available as a Flatpak: https://flathub.org/apps/details/org.signal.Signal
1 Like
Yes, but:
- “To use the Signal desktop app, Signal must first be installed on your phone.”
- It’s not designed to be used on smartphone screen
- Is there a ARM64 GNU/Linux compatible version ?
Hello everybody, Axolotl contributor here.
I’m running Ubuntu Touch and don’t own a Librem 5, but I don’t want to use Android, and I deeply use Signal for years. So when I started using Ubuntu Touch when Firefox OS died, I started to look at a Signal client and found Axolotl. Many things were working, many else weren’t, so I started to contribute.
However, today, I feel like implementing a third party client like we’re doing isn’t the good way to be able to use Signal on GNU/Linux, for two main reasons:
- We will always be behind upstream, by definition. They implement new features, and then we try to follow, with less resources. It’s a continuous race we can’t win, and that’s exhausting, the last example being new groups feature quickly followed by the deprecation of old groups. All communication can stop instantly and without us being warned, leaving Axolotl users cut from their contacts, sometime even without noticing it. It already happened, and it will happen again. That’s scary.
- Security. Axolotl code is written with love and passion, and we deeply want to create a nice application. But we’re doing that on our spare time. The code has many bugs, doesn’t have a testsuite (yet) and never had any security audit. Signal is sometimes used in critical situations, and if users of Axolotl knows it is an unofficial client with worse quality, this situation isn’t acceptable for other Signal users writing to Axolotl users without knowing that the level of security is way lower.
And that’s without listing all “minor” problems like no push notifications + not knowing what upstream thinks and if they will block us etc.
So in my opinion, even if Axolotl is serving me well and I’m using it daily, and even if OWS is currently pushing a new lib for the Signal language written in Rust which could maybe be used, that’s not the way to go. We have in my opinion two other choices.
The best one would probably be to make Anbox working great and run the Signal APK. This would even profit to every other Android application and is probably the most important things to do if we want GNU/Linux phones to reach mass-market one day. The good news is that UBPorts (the foundation behind Ubuntu Touch) is now funding a developer on Anbox full time, and every GNU/Linux distributions will benefit from that.
However, this will take time and as a web developer, Anbox and every low level work is out of my skill. That brings me to the second solution, not perfect as it still means a lot of work, but at least reassuring regarding the two main points raised above: use the desktop Signal client, which is a web app running in electron. That way, most of the code comes from OWS, is done with quality processes and will provide all upstream features.
The way I see it, this project would have two main steps : 1 make the desktop client runs on phone (support ARM, adapt the UI, remove the need of electron if there are lighter webengines like qtwebengine on Ubuntu Touch) 2 add primary client capability to the desktop apps (ability to use it as the master Signal, not as a linked device: ability to register, to import contacts, to synchronize them on Signal server and to link secondary clients).
Obviously, I hope that upstream would accept the contributions. About the first part, it could be, I don’t see why they would block that (there already are many issues about it, support for ARM almost work and I already created mockups to improve the UI on small screen). But they aren’t active there so I don’t know honestly. The second step, to turns the desktop client into a primary client however will probably not be accepted, see for example the inactivity of contacts management even if it’s a requested feature…
So if we engage ourselves in this, we will probably have to maintain a fork, and with upstream maybe not loving what we’re doing. That’s also why I would prefer the Anbox solution but I can’t help on that topic.
A very different solution would be to have a Signal website where you can log and simply use it in your browser, but that’s also not pushed by upstream, but only OWS can do this.
Of course, before launching ourselves in anything, I want to have opinions from the different GNU/Linux community (Purism / PureOS, PostmarketOS, Ubuntu Touch, Sailfish…) and also from the desktop distributions as this would allow people to use Signal without having a smartphone. And I want to bring our thinking to OpenWhishperSystem as creating a fork is always the worst solution so if they finally see that the GNU/Linux community is active and wants Signal, maybe they will also propose something. After all, it’s their product.
So, first steps, collecting opinions of GNU/Linux users. What do you think?
10 Likes
Thank you for sharing your experience and perspective @Fla. I very much agree that attempting to duplicate upstream’s work in a fork is an impractical strategy.
I am glad to see the upstream Signal-Desktop team is considering adaptive design changes.
As for adding primary client capability to the Electron application, IIUC – and I may be wrong about this – the reason that isn’t available is because of the dependency on phone numbers for contact addressing. I hope that once Signal has a way to register without a phone number they make that available in the Electron application.
A workaround that might be acceptable to upstream is to allow the Electron application to do the usual phone number based SMS registration. This could be done by letting the user manually enter a phone number and have the SMS received on whatever device is using that number – which could be the same Librem 5 running the Electron application, or a cheap throwaway Android device, or an ancient feature phone, or whatever. Then, the user would manually enter the code received in the SMS. Another alternative could be to somehow get the phone number from ModemManager or whatever system service has that info on the LIbrem 5 into the Electron application. I just asked upstream if this approach would be accepted.
Running the “web” application inside a different browser environment than Electron is an interesting idea. I am doubtful upstream would be too happy about that because they’re using Electron to minimize compatibility issues between devices & OSes. I also don’t know if that would have a practical advantage in terms of memory use, battery efficiency, or other issues.
I like the idea to gather feedback from various communities and collectively present proposals to upstream.
2 Likes
I think it may be feasible to have both the Electron application and the Android application via Electron as usable options. I suspect the Android application would end up being more efficient than running another web browser in the background all the time, but I also don’t know how much resources Anbox requires.
Thank you so much for your response & sorry for my delayed reply!
Thanks for the insight.
1 Like
Hi all,
I’m not sure I’m qualified to add to this topic as I haven’t used Signal, but I found the discussion interesting. Maybe I’ll start by explaining why I’m not a Signal user (yet):
It relies on Android push notifications, which require at least some Google services to be present and I use a mobile phone running LineageOS without any Google services (as far as I’m aware). While Moxie claims in his 36C3 talk that Signal needs push notifications, the XMPP app Conversations I use works very well without it. Apart from that, I’m not aware of an official way to install Signal on my LineageOS device as (for the reason above) it doesn’t feature the Google Play Store either.
I appreciate many points Moxie raised in his talk about the “moving ecosystem” and that a service like Signal needs to be able to evolve quickly and be user friendly while at the same time maximising security. And I’m sure it does this well for the majority of users. I especially like the fact that they appear to have come up with a beautiful design which avoids having to store anything about its users in their databases - it would be really nice if this was possible with XMPP as well. The last question however shows where problems arise and again, it is to do with those push notifications: Since they rely on the integration of 3rd parties (namely, Google and your mobile service provider as I currently understand) with your personally identifiable device (phone number, SNI), I have some doubts about the anonymity Signal offers to, for example, political activists and dissidents.
So in my opinion (based on the information I looked into), it feels like Signal needs to do two things to become a better instant messenger:
- drop the dependency on push notifications. This would take Google out of the loop, and remove one (maybe the final) obstacle to
- make the desktop client a fully featured, first-class citizen in the Signal network.
I think factoring out the libsignal-client library could be a great step to enable new apps for different platforms to be developed, but I think it’ll be very limited as long as it is tied to a Google service.
To me, it just feels a bit odd to buy a freedom-first device like the Librem 5 to then want to install Anbox on it with all the proprietary software we wanted to avoid in the first place.
1 Like
Your post is relevant but I think this topic is a better place for that:
As you are not a Signal user, I recommand you to consider Matrix as an alternative.
No, it doesn’t. That’s a thing of the past. It works fine without them and you could build from source without them. I’m using GrapheneOS which also doesn’t have Play services.
Right there: https://signal.org/android/apk
5 Likes
This is the best case scenario, and I expect it to happen before long–a lot of indications point toward this happening.
It seems like signal is trying to add non-phone-number identifiers as a prerequisite to adding several other features. In a few places, they’ve mentioned adding non-phone-number identifiers, including this blog post about PINs (https://signal.org/blog/signal-pins/)
I think it makes sense that a first-class desktop client would fit into this category of projects to be completed after non-phone-number identifiers have been added.
I saw a tweet from Moxie once that mentioned he has used Linux as his desktop OS for his entire adult life, so it’s hard to imagine that he would be uncompromisingly opposed to a standalone Linux app. Signal just has a long-term plan, and they want to take one step at a time.
I think there is good reason to believe that a standalone Signal Linux client will come along soon, and I will be very, very happy about it 
5 Likes
Thanks for your response and the updates. About Signal’s dependency on Play services:
That’s great to hear. I was deriving my information from Moxie’s 36C3 talk - the change must’ve happened after? Do you have a reference to that change, what are they using now instead?
Also thank you for the APK link - I may try it out
That happened definitely before 36C3 and I don’t have his talk in mind anymore but I guess he is talking about the standard case.
The fallback has been implemented in 2017, you can see the commit here:
It’s using websockets when Play services are not installed on the system.
You are welcome!
1 Like
@Fla
as i am using Signal on mobile only, my first priority would be a native Sailfish [insert OS of choice] app - but I see the problems here too.
Anbox looks like a FOSS alternative to the android virtual machine (Alien Dalvik) now running on Sailfish - I think this would be the smoothest way to go (and I don’t expect objections from OWS to that solution).
Electron relies on chromium? Do we have Google and Microsoft (via Github) on board that way?
My two cents - maybe not really helpful on the topic - but nevertheless: Signal has been just the lesser of many evils for me. I really don’t like to use walled garden solutions and I would be glad if instead more developers worked on xmpp, activitypub or other federated protocols/networks/solutions.
2 Likes
I don’t know if “fund my app” is the right way to donate to the signal app, but that’s what I have done. I gave 100$ but would be willing to pay more if it was spent directly on signal.
2 Likes
I think the right way to go is to use the Unix philosophy of writing a cli tool and a UI that uses it. That will be the easiest thing to port and maintain. It also gives power-users cli control.
1 Like
I agree that a more open e2e encrypted app would be a better alternative. I like the ease of using signal and I have gotten most of my friends to use it a few years ago. At that time it was the only option for normal users. I’ll get my friends to switch again if a better system comes forth.