-
libsignal
Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
libsignal-service-rs
A Rust version of the libsignal-service-java library for communicating with Signal servers.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Fortunately, the Signal developers are now using a new Rust library with bindings to C, Java, Swift, and TypeScript for their own clients. Currently this is undocumented and does not yet implement all the logic necessary to write a complete client. However, upstream has advised that using this new library would be the best option for starting a new client.
There is already an effort to create a Signal client for Sailfish OS, a Linux distro for mobile, called WhisperFish. It's written in Rust with a Qt/QML GUI. I'd imagine it wouldn't take too mich effort to get it working on other Linux distro, beside the Sailfisb-only QML components it's using.
So I think we need a native Linux client. I do not think Axolotl is a viable long term solution because it uses its own implementation of the Signal network protocol (written in Go). Reimplementing the cryptography and network protocol is a ton of work and will continue to be a ton of work as upstream adds more features. Axolotl has only just started reimplementing the new Signal groups protocol which was introduced 5 months ago. Also, the security of a reimplementation is dubious.
https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165 https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7
I just ordered a PinePhone and the biggest obstacle for me to use it as my daily driver to replace Android will be having a Signal client. I've been following the issue of getting Signal working on Linux smartphones for a while and I've come to the conclusion that it is probably best if we start a new client application. The Signal developers are uninterested in making their clients work for our use case. The Signal "Desktop" (Electron) client does not and will not support registering an account, is not designed for small screens, and does not build on ARM. The latter two issues may be fixed upstream (eventually), but they've specifically said they do not want to make the Electron client have feature parity with the Android and iOS clients. I doubt using the Android client in Anbox would be a good long term solution for battery or RAM usage.
So I think we need a native Linux client. I do not think Axolotl is a viable long term solution because it uses its own implementation of the Signal network protocol (written in Go). Reimplementing the cryptography and network protocol is a ton of work and will continue to be a ton of work as upstream adds more features. Axolotl has only just started reimplementing the new Signal groups protocol which was introduced 5 months ago. Also, the security of a reimplementation is dubious.
I am leaning towards using QML and cxx because I'll be able to reuse those skills for my main project. That's an old QWidgets application that we're planning rewriting with QML and have discussed integrating Rust libraries. The thought of using C to add Signal support to Chatty is unappealing to me. I have no experience developing with GTK, so that would add a lot of work to this project for me. Ultimately, which technical path to choose will be up to whoever does the work.
A new application with Qt and Kirigami. I discussed this idea with the Plasma Mobile developers and they suggested it could work by making a QObject wrapper class around the Rust libraries using cxx, run that in its own thread to handle the networking, and use Qt signals & slots to communicate with QAbstractItemModels backing the QML.
For push notifications, I think we should implement a native Linux daemon for Firebase Cloud Messaging without Android. This would require no extra effort for the Signal Foundation. It could also be used for reimplementations of other Android chat applications such as WhatsApp, Facebook Messenger, Slack, Zulip, and more. microG has already reimplemented the Android API in Kotlin and studying that code could be helpful.
I have not done this, but I gather than installation of microG, GApps and the Google Play Store in Anbox is possible: https://github.com/geeks-r-us/anbox-playstore-installer
I’m experienced with Rust and I’d be glad to help with this project. Regarding the options I think 1 could work well. Admittedly my experience with GTK is not extensive but for the little things I made with it using the gtk rust bindings worked quite well. The bindings seem mature and are officially supported by the gtk team. There’s also relm that helps with state management and other architectural concerns.
There’s also this project to bring SailfishOS apps to other mobile Linux platforms https://gitlab.com/dylanvanassche/convergence-components that might be applicable here.
Our plan is to put most of the backend logic in a portable Rust library building on upstream's Rust libraries. Someone is already interested in using that for a new CLI/bot client.
Hi, I started working on a GTK client. Although, the backend is still non-existent. It is just a UI preview for now, but it is already adaptive. https://github.com/SeaDve/Hermes
I'm rooting for https://github.com/Rust-GCC/gccrs, which addresses most of them.