Project Direction

[Michael-F-Bryan]

This crate now covers a fair amount of the libsignal-protocol-c API, so it's probably time to be more organised and write down our goals.

My end goal is to be able to write a bot in Rust which can communicate using Signal. For example, I could run a service on a Raspberry Pi and have it send notifications to my phone when something happens.

As such, I guess the next step would be to create a libsignal-service-rs project which builds on top of libsignal-protocol-rs and handles things like communicating with signal's servers and securely managing keys/sessions.

This also gives us a chance to use libsignal-protocol-rs in a real-world scenario (e.g. to see if the API is ergonomic or logically sound), seeing as we've only really got the generate_keys and sessions examples to go on at the moment...

@shekohex, what are your thoughts?

[shekohex]

Hi Michael, that of course would be awesome, for me, my goal is using this library to implement the same thing but instead of signal application, the WhatsApp Service, i know that WhatsApp has a private API but i managed to reverse engineering the application while ago and written a small library called (open-whatsapp)

(closed source currently for legal reasons with WhatsApp and Facebook company)

anyway, using this library will enable us to do incredible things, more in that later..

Using this library in real world application will enable us to find more bugs and improve the public API library to match the ergonomic rust style.

[Michael-F-Bryan]

It looks like we're both wanting to build clients on top of the signal protocol. Have you tried using this library for talking to WhatsApp? And how did you get started reverse-engineering WhatsApp's communication protocol?

[Michael-F-Bryan]

I've created a libsignal-service-rs repository to start working on the equivalent of libsignal-service-java. I'm not overly familiar with that Java library though, so I've been finding it hard to get started...

[Michael-F-Bryan]

We may as well release libsignal-protocol and libsignal-protocol-sys to crates.io, seeing as the crate itself is mostly complete.

@shekohex, I'll add you as an owner.

[whatnick]

Hi all, I am coming into this late. Excited to see the WhatsApp protocol library still functioning. I have previously used python-axolotl with limited success and quick bans. I am eager to try out

open-whatsapp

if that works reliably. Here is my use case : https://twitter.com/hewanike ( Automated weather updates in Kenya). It can / will reach a wider audience when coupled with WhatsApp as well. Will build out a signal implementation of the twitter bot and see how that goes. P.S. I hope this is an appropriate spot to post this.

[kaushalyap]

Want to see this project moving forward!

[rubdos]

Just chirping in here. I'm redesigning Whisperfish, which was previously build around a custom-implemented Go library, to use this crate instead (and Rust). Main reason is that it's easier to follow the C library (like this library is doing) than keeping a parallel implementation.

I'm using Actix/Tokio (together with Qt) for that application, so I'd be interested in an async-compatible crate too. Is this something that might go into your -service crate, or would that better be something separate?

[Michael-F-Bryan]

I'd be interested in an async-compatible crate too

As it stands, this should be async-compatible because libsignal-protocol-c just does crypto and message management without any IO.

I was envisioning libsignal-service-rs as a sort of client that uses libsignal-protocol-rs to talk to the Signal servers, but because I didn't have a project that actually needed to talk to Signal at the time it kinda fizzled out before coming to fruition (notice the repo's measly 5 commits).

[rubdos]

As it stands, this should be async-compatible because libsignal-protocol-c just does crypto and message management without any IO.

Yes, exactly what I thought too. That'll be very useful.

I was envisioning libsignal-service-rs as a sort of client that uses libsignal-protocol-rs to talk to the Signal servers, but because I didn't have a project that actually needed to talk to Signal at the time it kinda fizzled out before coming to fruition (notice the repo's measly 5 commits).

Expect patches :-)

[rubdos]

Hi @Michael-F-Bryan, I'm having a look at libsignal-service at the moment. If you'd be interested in discussing a bit, and you have an IRC client or Matrix account, would you join me on Freenode #whisperfish or #whisperfish:rubdos.be? If not, it's no problem, I'll open issues and merge requests on that repo.

[jeffrade]

I have a Slack client-server project where users can send encrypted messages to each other (a basic public/private key and AES implementation inspired by OpenPGP), but would like to add the Signal protocol for direct messaging once two client peers are introduced.

I was going to port the Java implementation, but luckily found your Rust implementation instead so will try and use it going forward.

[Michael-F-Bryan]

The libsignal-protocol-rs project is a wrapper around the official C library, so hopefully it'd be more feature-complete and secure/correct than if you ported the Java code yourself.

Something to keep in mind is that libsignal comes in two layers:

• libsignal-protocol - the underlying cryptographic routines, works completely on data in memory and doesn't care about IO or sync vs async
• libsignal-service - the code for communicating with Signal's servers using libsignal-protocol to do high-level operations like sending messages and establishing a secure connection with a peer. This uses a normal REST client and websockets for communication so implementations can vary a lot depending on how you want to do IO

This repo contains the former and covers the vast majority of the API surface, while @rubdos has been doing a lot of work on the service layer in Michael-F-Bryan/libsignal-service-rs. If you are interested, you may want to work with him over there to get more of the service layer completed.

[jeffrade]

@Michael-F-Bryan Thanks for the overview. :+1: