GTK Rust mobile Linux client for Signal

[Be.]

Do not clutter this thread with criticisms of Signal. Take that discussion elsewhere please.

Hi,
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 Also, the security of a reimplementation is dubious.

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. Considering there is a C FFI (which I presume they implemented to implement the S, it may be possible to add Signal support to libpurple which is used by Chatty. However, I am doubtful that would work out well. libpurple was made in a different era when messaging didn't include audio and video calls, emoji reactions, or disappearing messages. Trying to cram those into the libpurple API may be more trouble than it is worth. I would also be concerned about starting a new project using such an old code base which I am guessing has quite a bit of legacy cruft.

So, I think the best way forward would be a new client using the Rust bindings for GTK so the upstream libsignal-client, zkgroup, and ringrtc Rust libraries can be used directly. I don't have much experience developing with Rust or GTK and I barely know anything about cryptography, plus I already maintain another very complex application, so I couldn't lead development of this but I'd be happy to test and contribute code where I can. I am starting this thread to try to organize people who are interested in working on this.

I propose this roadmap for implementing features:

1. Device registration
2. Sending and receiving text messages
3. Import contacts
4. Use the WebSocket API for notifications like the Android client does on Android with neither Google Play nor microG
5. File attachments
6. Voice calls
7. Video calls
8. Device linking. If we could get this application to link to itself, that could be an awesome way to have the primary installation on a PinePhone and use the same application on a Linux laptop.
9. Figure out a way to do notifications in a more battery friendly way. This will require cooperation with the Signal Foundation and we may need to write the changes for the server software ourselves. Maybe OpenPush? Or perhaps get Firebase push notifications working on Linux without Android?
10. SMS support
11. MMS support

I think the GUI design could largely copy the Android client.

[linmob]

I like this idea a lot!
While I totally agree on libpurple, I know that Purism are currently adding Matrix support to Chatty that does not rely on libpurple (see this changelog), but uses a new, chatty specific API if I understand it correctly. Maybe this API could be used to implement Signal, too. I would suggest you to get in touch with Mr Sadiq (who has been working on Matrix for Chatty).

[barray]

I would suggest starting with what already exists out there: http://pidgin.im/plugins/

[Be.]

I like this idea a lot!
While I totally agree on libpurple, I know that Purism are currently adding Matrix support to Chatty that does not rely on libpurple (see this changelog), but uses a new, chatty specific API if I understand it correctly. Maybe this API could be used to implement Signal, too. I would suggest you to get in touch with Mr Sadiq (who has been working on Matrix for Chatty).

Interesting. I didn't realize they were expanding the scope of Chatty beyond libpurple. I posted on Purism's issue tracker for Chatty. I'm unclear how audio and video calls could fit into Chatty. Maybe Chatty could communicate with Calls over dbus for that.

Someone on the PinePhone Matrix room suggested reaching out to the Plasma Mobile developers. They suggested a new application written with Qt, QML, and Kirigami. This could work by writing a QObject wrapper around the Rust Signal libraries with cxx, running that in its own thread for networking, and communicate with QAbstractItemModels backing the QML views via Qt signals and slots.

I've also posted on the Signal forum trying to get people together to work on this.

[Be.]

I would suggest starting with what already exists out there: http://pidgin.im/plugins/

As I already said in the initial post, I don't think that would be a good idea.

[kop316]

Just so you know, I would avoid using libpurple. The entire reason that chatty is going away from using libpurple is because it is not very flexible, the documentation is bad/non-existant (putting it nicely), and you end up having to use a bunch of hacks in order to get it to do what you want. I can tell you I spent way too many hours trying (and failing) to get group chats to work with libpurple, and it is because there are a bunch of undocumented things you need to do to get it to work.

Most of what you are proposing would work with Chatty (or chatty already supports). It may be worth looking into the chatty code base and seeing if you can build a backend into there. Possibly look at the chatty-ma-chat code or the chatty-mm-code?

[mattpenn]

As a non expert in such things I would be interested to know how portable Sailfish OS apps can be. The reason I ask is that there is a quickly developing Alpha Signal client here:
https://gitlab.com/rubdos/whisperfish

This ticks the mobile UX box well. Not sure if the other concerns are covered.

[Be.]

As a non expert in such things I would be interested to know how portable Sailfish OS apps can be. The reason I ask is that there is a quickly developing Alpha Signal client here:
https://gitlab.com/rubdos/whisperfish

This ticks the mobile UX box well. Not sure if the other concerns are covered.

Whisperfish uses the proprietary Jolla QML libraries so that's a nonstarter. It is also still using the unmaintained libsignal-protocol-c library although the developers plan to switch to the new Rust libraries.

[Be.]

I've decided to use Qt Quick and initialized a repository called Flare on KDE's GitLab server. So far it's just a template with a README and license. Please contribute! If you're interested in helping, join the #plasmamobile:kde.org Matrix room.

[Be.]

I've decided to use Qt Quick and initialized a repository called Flare on KDE's GitLab server. So far it's just a template with a README and license. Please contribute! If you're interested in helping, join the #plasmamobile:kde.org Matrix room.

After discussion with the Whisperfish developers, I've decided to help them decouple Whisperfish from Sailfish OS and implement a new GUI with KDE's Kirigami QML library instead of starting a new Kirigami application from scratch. Join us in the #whisperfish:rubdos.be Matrix room if you are interested in helping!