800+ IT
News
als RSS Feed abonnieren📚 starting a native adaptive Linux client for Signal
💡 Newskategorie: Linux Tipps
🔗 Quelle: reddit.com
Please do not respond with criticisms of Signal. I am trying to get something done here, not start a debate.
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. Whisperfish is a nonstarter because it uses the proprietary QML libraries from Jolla. It is also using the unmaintained libsignal-protocol-c library, but the developers plan to switch to the new upstream Rust libraries.
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 are several paths forward:
- A new application with the GTK Rust bindings. This would have the advantage of not needing any intermediate layers between the upstream libraries and the client application.
- 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.
- Integrate the Rust Signal libraries with an existing chat application instead of writing a whole new GUI. Integrating into Chatty would have the advantage of also handling SMS & MMS like the Signal Android client, but I'm unclear how audio and video calls could be integrated into Chatty. Maybe that could be separately integrated into Calls. Integrating Signal into Fractal or NeoChat could be other approaches, but would make those applications much more complex and I'm not sure their developers would welcome that.
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 on 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.
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 so studying that code could be helpful.
If someone wants to make this client work on Windows and macOS, notifications could be done with WebSocket. But I'm far more interested in getting it working on Linux smartphones.
I don't really have the capacity to lead this long term, so right now I am trying to organize people who are interested in doing the work. Hopefully once there is a minimal proof-of-concept that can register an account and send & receive text messages, more developers will join.
I've also started a discussions on the Pine64 and Signal forums about this.
[link] [comments] ...