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) | via nym-vpn-client (uniffi + cargo-swift / cargo-ndk) | via nym-vpn-client (uniffi + cargo-swift / cargo-ndk) |
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
There is no first-party mobile SDK, but nym-vpn-client (opens in a new tab) ships production iOS and Android apps built around the Nym stack and is the reference we'd point you at. The relevant pieces are nym-vpn-core/crates/nym-vpn-lib-uniffi (uniffi (opens in a new tab) FFI wrapper), nym-vpn-core/iOS.mk (cargo-swift (opens in a new tab) → XCFramework + SwiftPM), and nym-vpn-core/Android.mk (cargo-ndk (opens in a new tab) → jniLibs/, driven from Gradle).
If you try this and hit (or solve) blockers, drop a note in the Nym dev channel on Matrix (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