Choosing an Approach
Any application that integrates with Nym sends its traffic through the Mixnet via a Nym client. The right product depends on two factors: your environment (where your code runs) and your architecture (whether you control both sides of the communication).
At a glance
| End-to-end (both sides run Nym) | Proxy mode (Nym → clearnet exit) | |
|---|---|---|
| Rust (native / desktop / CLI) | nym-sdk (Stream, Mixnet, Client Pool) | smolmix (TCP / UDP) · nym-sdk SOCKS client |
| TypeScript (browser) | TypeScript SDK (WASM Mixnet Client, messaging only) | mix-fetch (HTTP) |
| Mobile (iOS / Android) | untested; see Mobile note below | untested; see Mobile note below |
Environment
Different runtimes have different transport constraints: a browser cannot open raw sockets or access the filesystem, while a desktop app can.
- Native / Desktop / CLI: full access to system networking and persistent storage. Use
nym-sdk(the Rust SDK) for E2E messaging or byte streams, orsmolmixfor TCP/UDP socket-shaped access in proxy mode. - Browser: restricted to WebSockets, Web Transport, and
fetch; HTTPS-only mixed-content rules; no filesystem access. Usemix-fetchfor HTTP(S) requests, or the TypeScript SDK's WASM Mixnet Client for raw message passing.
Mobile (untested ground)
There is no first-party mobile SDK, and we have not yet shipped tested mobile builds. The Rust crates should cross-compile to mobile targets. This is the path we'd take if starting today:
- Build
nym-sdkorsmolmixfor the target triple (aarch64-apple-ios,aarch64-linux-android, etc.). - Generate FFI bindings with
uniffi(opens in a new tab) and call them from Swift or Kotlin. The existing Rust SDK FFI (Go, C/C++) is a useful reference for the binding shape. - Run the tokio reactor on a dedicated background thread. iOS in particular has strong opinions about backgrounding and
libdispatchinteraction. - Plan for TLS / cert-store integration up front. On mobile you'll typically want to call out to platform TLS (
SecTruston iOS, AndroidNetworkSecurityConfig) rather than embed a CA bundle.
If you try this and hit (or solve) blockers, we'd like to hear about it. Drop a note in the Nym chat (opens in a new tab) or open an issue on GitHub (opens in a new tab).
Architecture
The second factor is whether you control both sides of the communication.
End-to-end (E2E): both sides run Nym clients. All traffic stays Sphinx-encrypted the entire way. Appropriate for peer-to-peer setups or any case where you control both endpoints.
Proxy: only the client side runs Nym. Traffic exits the Mixnet at an Exit Gateway and continues to the destination over the public internet. The mixnet anonymises the sender; payload protection (TLS, Noise, etc.) is your application's job, as on a direct connection. Appropriate when connecting to third-party services such as blockchain RPCs or external APIs.
Once traffic leaves the Exit Gateway, it travels over the public internet to the destination, exactly like any other server-initiated connection. The mixnet anonymises the sender but does not encrypt the payload past the gateway. Use TLS or another application-layer cipher as you would on a direct connection. See Exit Gateway Services for what the exit can and cannot observe.
Browser apps: both proxy and E2E modes work slightly differently in a browser setting. The Nym client runs as a WASM blob inside a Web Worker, and your application communicates with it via JS bindings rather than direct function calls. The mixnet behaviour is identical; the integration shape differs.
Where to go next
- Rust, E2E messaging or byte streams:
nym-sdk - Rust, TCP/UDP socket replacements:
smolmix - Browser, HTTP(S) requests:
mix-fetch - Browser, raw mixnet messaging or Nyx smart contracts: TypeScript SDK
- Background on Sphinx, gateways, and the mixnet itself: Key Concepts