Dependency on libsodium as a system library causes issues for integrators

[LukasQ]

The SDK currently depends on libnacl for its NaCl/E2E cryptography. libnacl is a Python binding for libsodium that is no longer actively maintained and requires libsodium to be present as a native system library at import time — even when only the simple (non-E2E) API is used.
I'm building a Home Assistant integration using this SDK. Home Assistant has a large contributor base, and the transitive libsodium system dependency causes ImportError on any system where libsodium is not installed — blocking developers from even running the test suite.
The well-maintained, widely adopted alternative for the same functionality is pynacl (by the Python Cryptographic Authority), which is actively maintained and also wraps libsodium.

Request: Consider replacing libnacl with pynacl as the cryptography backend. This would address both the maintenance concern and the unconditional native dependency at import time.

Environment:

• threema.gateway==8.0.0
• Python 3.14
• Error on systems without libsodium: OSError: Could not locate nacl lib, searched for libsodium

[threema-danilo]

Hello @LukasQ, thanks for the offer! A HomeAssistant integration definitely sounds nice.

We are currently evaluating whether we can reimplement our various Gateway SDKs on top of the Rust SDK, through generated bindings.

Would you be willing to test a Python wrapper if we come up with a PoC?

[LukasQ]

Well, Rust bindings via PyO3 are in theory a good one. Modern, performant, well-maintained single codebase for all language SDKs
But for HA in practice:

• Rust bindings still require pre-compiled wheels for every platform HA runs on: x86_64, arm64 (Pi 4), armv7 (older Pis), etc. (maintenance effort)
• If you don't publish wheels for all those platforms, HA users would need a Rust compiler (which sounds to me completely unrealistic)
• Still a native dependency — same class of problem as libsodium, just in a different packaging form

A Rust wrapper doesn't solve integration problems. It might even be harder to manage than libsodium.

PR as ref: home-assistant/core#165993

[edenhaus]

armv7 (older Pis)

No HA is not supporting anymore so we don't need them. Just build the wheels for linux x64 and arm64 with glibc and muslinux (alpine used in production)
Would be nice to create also wheels for macos but they will just be used for the dev env.
I'm maintaining a HA library with Rust code and PyO3. Completely tested in CI for all archs. See https://github.com/DeebotUniverse/client.py/blob/dev/.github/workflows/ci.yml

If you don't publish wheels for all those platforms, HA users would need a Rust compiler

HA core has a pipeline to build muslinux wheels for all dependencies if the library is not providing ones. But it would be better if the library is also releasing all wheels and uploading them to pypi. See my library above

A Rust wrapper doesn't solve integration problems. It might even be harder to manage than libsodium.

If you provide the wheels it's a lot easier. HA will not allow any new integration that needs system packages (in your case libsodium) be installed

[threema-danilo]

Thank you for your feedback. We would probably not go the PyO3 route, but rather uniffi plus probably something like maturin. Building wheels for both x64 and arm64 would definitely be part of that story.

[LukasQ]

See, that's the part I like about tech people - tech facts win (usually ;) )
So, with these new infos from @edenhaus i'd happily test the rust wrapper @threema-danilo.

[LukasQ]

@threema-danilo I try to foster the as-is implementation as ffmpeg uses it too. Hopefully it gets merged. I'll then improve and add features (e.g. Media) and later switch the SDK. Do you have a rough timing? With that in mind, the PR should be approved IMHO.

[LukasQ]

Well, I'm stuck: no publishing with the current implementation according to HA. Any updates on the ETA?

[threema-danilo]

ETA: If no blocker pops up, by the end of June.

[threema-danilo]

Work is ongoing here: threema-ch/threema-msgapi-sdk-rust#127

[LukasQ]

@threema-danilo should I have a look at your branch or wait for the merge?

[LukasQ]

Hey all
Any News?

[threema-danilo]

Hi @LukasQ - no news yet unfortunately. Until we are ready with our plans, you could consider experimenting with a fork that uses pynacl - the encryption primitives used are quite few, and it would probably not be hard to replace them. There are currently no plans to do this replacement in an official version of the current Python SDK.

[LukasQ]

Ah, ignore that.
I thought about the rust implementation with appropriate wrapper and commented in the wrong repo. see: threema-ch/threema-msgapi-sdk-rust#127 (comment)