Consider/switch to libsignal-client

[gferon]

instead of libsignal-protocol-c. It's already used in production in (at least) the Android app.

Link: https://github.com/signalapp/libsignal-client

[rubdos]

Since this would basically archive 100% of the effort of @Michael-F-Bryan and @shekohex, tagging them here :'-)

[shekohex]

I support this transition, for obvious reasons:

1. the new one will be maintained and supported by the Signal team, which is nice!

2. it's fully written in Rust, no more C and Rust glue.
   (although, our implementation on top of the C base, was already somewhat safe and easy to use, but I guess nothing better than a fully Rust codebase from the beginning)

3. I already use some of it's parts in my application owlchat/keystore 😉

So, I hope the refactoring step will be easy and the tests pass correctly!

[Michael-F-Bryan]

I agree with @shekohex that it doesn't make sense to use FFI to link to the C library when there is a native Rust version available. A nice consequence of switching is that it also avoids a bunch of effort keeping libsignal-protocol-rs in sync with changes in the C library.

This sounds like a no-brainer 👍

[rubdos]

Good! I have an army of alpha-testers over at the Sailfish community. We'll need them, because our tests are ... well we have more alpha testers than tests :'-D

[Be-ing]

Hi Whisperfish developers, I'm organizing an effort for a new mobile Linux Signal client using the new upstream Rust libraries. I'm planning to do as much as possible in Rust and use cxx for a thin C++ layer to connect the Rust to Qt Quick & Kirigami. I have glanced at the Whisperfish code and I don't think much of it would be useful for us because of the proprietary Jolla QML library and Sailfish OS-specific code, so I think it will be easier to start from scratch. Nevertheless, I'm trying to figure out what we can collaborate on. I am discussing this with the Axolotl developers as well.

I've discussed this a bit with the upstream Signal developers and they say the new Rust library is incomplete and the API may break at any time. I'm still unclear what the upstream libraries do and what will be necessary to implement ourselves. What exactly are the capabilities of this library? IIUC the upstream libraries only handle processing the messages and we'll have to handle the networking I/O and an encrypted database ourselves.

[rubdos]

Hey @Be-ing , thanks for getting in touch! I saw the convo at Axolotl pass by a few hours ago :-)

This library is very capable. It's just been a bit unpleasant that libsignal-protocol-rs was finished a few weeks before Signal launched their signal-client replacement.

Before dismissing Whisperfish as a base for your project, please consider that we want to do the same thing. I want to absolutely work together with other people (including those from Axolotl, if we ever can share code).

In fact, there are multiple efforts (https://gitlab.com/rubdos/whisperfish/-/merge_requests/77, https://gitlab.com/rubdos/whisperfish/-/merge_requests/152, https://gitlab.com/rubdos/whisperfish/-/issues/183, and https://gitlab.com/rubdos/whisperfish/-/merge_requests/138) for refactoring the Whisperfish code into something more generic. The reason for the close coupling with SailfishOS is not because we want that. It's because it was so historically. If anything, SailfishOS support should be an automatically infered build target (worst case cargo build --feature sailfishos), such that other user interfaces can be supported.

I've had plans for a while to get async Rust decently integrated with qmetaobject-rs. Also woboq/qmetaobject-rs#102. If that's done, QML-interfacing should be as easy as putting a macro around a struct.

---

So, to go a bit more technical on the many existing libraries. These two are Rust libraries by Signal themselves:

• signal-client: doesn't do what you think it does. It's not a client. It's an implementation of the ratchet and some other cryptographic primitives.
• zkgroup is the cryptographic system that does the zero-knowledge group authentication stuff.

These are our libraries:

• libsignal-protocol-rs: old equivalent of signal-client, equivalent of libsignal-protocol-c, also textsecure
• libsignal-service-rs: equivalent of the old libsignal-service in Java
• libsignal-service-actix: Actix Web-based backend for libsignal-service
• libsignal-service-hyper: Hyper-based backend for libsignal-service

---

What a client still needs to implement is a GUI, local storage, and state management (database with a bit of logic when to accept a request and when not to). That's what Whisperfish does, that's also what Axolotl does. This is easily 10k lines for a modern Signal client.

So, if you want to join effort, I kindly invite you to #whisperfish on Freenode or #whisperfish:rubdos.be on Matrix to have a chat. We have cookies!

[Be-ing]

The reason for the close coupling with SailfishOS is not because we want that. It's because it was so historically. If anything, SailfishOS support should be an automatically infered build target (worst case cargo build --feature sailfishos), such that other user interfaces can be supported.

Oh, great! I didn't understand that was your intention. Have you thought about moving the Rust backend code to a separate library? We could collaborate on a set of Rust libraries implementing a common backend with different frontends. Or would you be open to replacing the Jolla QML libraries in Whisperfish with Kirigami? In that case, there wouldn't be a need for a whole new project.

I've had plans for a while to get async Rust decently integrated with qmetaobject-rs. Also woboq/qmetaobject-rs#102. If that's done, QML-interfacing should be as easy as putting a macro around a struct.

That would be cool. It also sounds like a ton of work that would be above my skill level. I'm just a beginner with Rust.

Why do you have two networking backends? Are you committed to using one or the other yet?

[Be-ing]

So, if you want to join effort, I kindly invite you to #whisperfish on Freenode or #whisperfish:rubdos.be on Matrix to have a chat. We have cookies!

I'm having trouble adding that server in Element:

We've been discussing in #plasmamobile:kde.org. If you're open to replacing the Jolla QML library with Kirigami, I think the KDE developers would welcome Whisperfish joining Plasma Mobile.

[rubdos]

The reason for the close coupling with SailfishOS is not because we want that. It's because it was so historically. If anything, SailfishOS support should be an automatically infered build target (worst case cargo build --feature sailfishos), such that other user interfaces can be supported.

Oh, great! I didn't understand that was your intention. Have you thought about moving the Rust backend code to a separate library? We could collaborate on a set of Rust libraries implementing a common backend with different frontends. Or would you be open to replacing the Jolla QML libraries in Whisperfish with Kirigami? In that case, there wouldn't be a need for a whole new project.

Intention is a big word, but it's been in our heads for over a year. I'm not okay with dropping the proprietary QML interface, but I have absolutely no objection to remodeling whatever is needed to make KDE people happy. Splitting logic from UI is a good pattern anyway, but it'd be nice to have it still in the same repository :-)

I've had plans for a while to get async Rust decently integrated with qmetaobject-rs. Also woboq/qmetaobject-rs#102. If that's done, QML-interfacing should be as easy as putting a macro around a struct.

That would be cool. It also sounds like a ton of work that would be above my skill level. I'm just a beginner with Rust.

Why do you have two networking backends? Are you committed to using one or the other yet?

We're mainly using the Actix one. The Hyper back-end has been added recently by Gabriel, because "fun".
There's a major problem in async-Rust land: the interface to async is in std, but executors are not. Makes for a bit of a split, and that's why there's multiple back-ends.

[rinigus]

Let me chip in on Silica, Ubuntu Touch, and Kirigami QML. As started with Pure Maps, it is possible to split QML into platform-specific and generic parts. This approach with the platform-specific parts has been used also for OSM Scout Server and Amazfish. The latter has the newest revision of these platform-specific bits and should probably extended from there.

The platform gets selected during compilation, so you can support (on GUI side) all these platforms. It is not super-trivial to do so and the app has to be rewritten in part, but not a huge effort either. For SFOS developers, it means that you can actually develop new functionality on the desktop which is way faster than syncing with the device. At least that is my experience with the maps apps.

I presume that the code for contacts updates from OS would be also specific to the platform. Maybe keepalive (and it's analogs support on other platforms) as well, but that is in part already there in Pure Maps QML platform-specific bits. Just if you wish to interact with the device suspend from Rust/C, it may require some bits there as well.

PS: @Be-ing - just subscribe to the room without browsing Matrix server

[rubdos]

(and in order to just join the room, use /join #whisperfish:rubdos.be. I'll try to get my federation fixed. Again.)

[gferon]

Hey @Be-ing adding more here, although it'll probably be discussed on the Matrix chat: I've started https://github.com/gferon/presage, which is a higher level library leveraging both libsignal-service and libsignal-client-rs - which was originally made to be used a test bed for new features with a CLI on Linux. I'd be glad if we could join effort and make something that's generic and can be reused everywhere!

[Be-ing]

Awesome. Yeah, the more developers involved, the better. I think we can work on a shared cross platform Rust backend with multiple frontend projects.

[rubdos]

If we are to put real effort in presage, let's get as much as possible extracted from Whisperfish into there, modernising where necessary. Would be a bit sad to duplicate my last year's worth of work :p

[Be-ing]

If we are to put real effort in presage, let's get as much as possible extracted from Whisperfish into there

Do you mean extracted from Whisperfish into this library? Or maybe into a new library which uses this?

[rubdos]

If we are to put real effort in presage

Extract from Whisperfish into https://github.com/gferon/presage

[rubdos]

As said in #83, the total of ibsignal-service-rs will be licensed as AGPLv3, because we link to libsignal-client. The simplest way to do so, is to ask permission of all people that ever contributed here to relicense their contributions under AGPLv3.

I'll make a checklist here of our nine contributors (I don't think we need include @traviscibot 😉 ):

• @rubdos
• @gferon
• @gamag
• @mjtorn
• @ntninja
• @matej-g
• @thibautvdv
• @boxdot
• @Michael-F-Bryan

If you are mentioned above, please reply to this pull request, saying you agree relicensing your code under AGPLv3. If you do not agree (but please do), we will have to put your part of the code under GPLv3 until it's deleted.

We believe that libsignal-client is the best way forward for the future viability of having Signal clients written in Rust. Additionally, we will soon start contributing parts of our code (@gferon and me) to libsignal-client, moving from here: https://community.signalusers.org/t/lets-join-forces-deduplicating-ios-android-node-code-into-libsignal-client/31667. If your code would be affected, we will certainly contact you before that happens, but I don't expect such a thing to happen.

[mjtorn]

Sure I do agree! And this is a very interesting turn of events, worthy of celebration :)

[gferon]

I also agree! Great news, really!

[boxdot]

I agree.

[thvdveld]

I agree.

[matej-g]

Obviously agree 😉

[gamag]

I agree too, obviously, sounds very promising!

[ntninja]

I see I'm on the list too. While I don't see why need my permission for enforcing additional restrictions on the existing GPLv3 code, I of course don't mind officially relicensing it either. So by all means, you have my full agreement! 🙂

[rubdos]

That went a lot quicker than I had anticipated! Yay. Let's get this under AGPLv3 then, starting at #83 .