feat(service): Add Signal support about notify

[KiptoonKipkurui]

Hi, @nikoksr since you did the Matrix service, could i take on the signal support?

[x32ll]

I'll take this one if that is okay?

[nikoksr]

Leaving this here as a potential library for the Signal service implementation.

crossle/libsignal-protocol-go

[nikoksr]

@arnocornette yes please. That would definitely be preferable!

[nikoksr]

@KiptoonKipkurui sure thing! That would be highly appreciated. Want me to assign you to this issue?

[x32ll]

Is it good that I split this in two seperate branches/prs?

One for matrix and one for signal?

[ppmdo]

Is this being worked on? If not, I would like to offer some help.

[nikoksr]

Hi @ppmdo, thanks for your interest in helping the project out! Signal is currently not being worked on but it's definitely one of those services we're desperately waiting for! Your contribution would be more than welcome.

The problem so far has been the lack of up-to-date and well maintained client libraries; have you looked into that yet? The most promising client library that I could find is RTann/libsignal-go.

[x32ll]

Hey @ppmdo and @nikoksr,

I had a look at this a while ago.. From what I intially saw (and remember) the community client libraries aren't well maintained.
Signal does have a libsignal repository, however this does not seem to support Go.

The routes I saw when looking into were using cgo (does this work with rust?) or implemenenting a Go only implementation of the client library.

[nikoksr]

@arnocornette thanks for your input on this! That's exactly how I see the situation with Signal and why we haven't implemented it ourselves yet.

Regarding your rust cgo compatibility question; there seems to be a way but from what I can tell it would require the libsignal Rust implementation to export the necessary functions to make them callable for us. An amazing article on this can be found here. @FiloSottile I hope you don't mind if I throw you into this mix. Maybe you could quickly give us your 2c whether this is a reasonable approach or not.

Also, there's this comment in the official libsignal library describing a potential solution where we could call the C part of their Swift implementation.

Most likely we all agree that cgo this is a very unpreferable solution all together though. An official or at least actively maintained Go library would be much prefered. But also, unless you want to do this yourself @arnocornette or @ppmdo, I don't see a way of us having the capabilities of actively maintaining our own libsignal implementation.

[ppmdo]

Thanks for the detailed explanations. I do agree that we need and official or maintained Go library to implement this. So I guess in the meantime we should put this on hold.

Based on the comment you linked, looks like it's not on the official roadmap. Maybe the best way forward is to wait for this one to be stable https://github.com/RTann/libsignal-go.