[Feature request] Release on crates.io

[werdahias]

I intend to package libsignal for debian. This would require this crate being on crates.io. I'd appreciate it if you could publish it.

Cheers

[jrose-signal]

We can certainly consider releasing on crates.io, but I don't think the project is well-suited for a Debian package. As noted in the readme, we don't promise any support for use outside Signal; in particular, "all APIs and implementations are subject to change without notice". We maintain protocol compatibility across our range of currently supported clients, but that's all we guarantee. Combined with Debian's stringent update requirements that leads to packages falling behind their source projects, and you could pretty quickly have something that's no longer consistent with what Signal itself uses. Of course, libsignal can be used as a building block for other programs and protocols, but without compatibility promises updating from version to version has to be understood as a manual step, and making libsignal a standard Debian package dilutes that message somewhat. (It's also a little weird that that package wouldn't come from us, the Signal Foundation.)

Let's take a step back: what are you actually hoping to accomplish?

[werdahias]

I intend to package Flare in the long run ( a unofficial GTK Signal client). As it uses libsignal as dependency I'd need to package that first (debian policy calls for no vendored dependencies) . I agree that by the time libsignal would make it into debian stable it might be out of date/incompatible. But because Ubuntu pulls ~70% of the new debian packages in testing, it would be made available for a lot of endusers/developers.

[gferon]

I would really love to see libsignal on crates.io as it would allow us to publish crates that make use of it, and it's pretty easy to update and make sure everything stays compatible with the official Signal ecosystem.

However, I feel like @jrose-signal really has a point with Debian packages, and I don't see it very fitting either.

[werdahias]

The release on crates.io is somewhat separate from the package. A debian/ubuntu rust package provides the same files as in the repo, e.g. src/lib.rs. As in regards to possible API breaks: Since most of the users/possible developers in the debian ecosystem run some version of ubuntu because of the newer packages (or debian testing/unstable) I don't see this as a big issue.

[werdahias]

Any update? Or are you not going to release it?

[jrose-signal]

We're still considering, and it's only one priority amidst many. There are a number of things working against putting this on crates.io, such as the usual complexity around multiple crates and the dependence on forks of other crates (curve25519-dalek and boring).

libsignal-protocol on its own would be fairly suitable to crates.io as is, but that isn't necessarily what's being asked for here. The other crates are a little harder.

[gferon]

Thanks for your insight. I believe if you decide to make it happen, publishing libsignal-protocol and zkgroup only would already be really useful.

[werdahias]

If some crate depends on some fork, that will indeed pose an obstacle. From a quick glance some crates aren't depending on specific crates. Releasing just those would also help.

[FintanH]

I'm also interested in a crates.io release, but maybe at the same level as the APIs for the other languages. Essentially, I have an idea for an application that I'd like to build for mobiles, and would like to have Signal's E2EE encryption. Since it's just little old me working on this, I'd love to be able to feed two birds with one scone and build it using Tauri which says it has cross-platform support for mobile devices. That means I could likely build nearly everything in Rust, which is currently my wheelhouse 😁 If not, maybe I could use the TypeScript API, but it would be great to keep as much of it in Rust as possible.