Overview
Every Nym integration sends its traffic through the mixnet via a Nym client. Which crate or package you use comes down to two questions:
- Runtime: where does your code run?
- Approach: do you control both sides of the connection (end-to-end), or are you reaching a third-party service through the mixnet (proxy)?
The table below maps those two answers to a package.
Choosing a package
| Runtime | End-to-end (both sides run Nym) | Proxy (exit to clearnet) |
|---|---|---|
| Native Rust (desktop / CLI / server) | nym-sdk: Mixnet, Stream, Client Pool | smolmix: TcpStream / UdpSocket · nym-sdk SOCKS |
| Browser / WebView (JS + WASM) | TypeScript SDK: @nymproject/sdk raw messaging | mix-fetch HTTP/S · mix-dns DNS · mix-websocket WS/WSS |
Mobile is a host, not a runtime. The same phone can run either row. Compile the Rust SDK to a native library (uniffi plus cargo-swift (opens in a new tab) for an iOS XCFramework, or cargo-ndk (opens in a new tab) for Android jniLibs/), or load the WASM packages inside a WebView (Capacitor, Cordova, Ionic, WKWebView, Android WebView). The SDK ships FFI bindings for Go and C/C++ only; for Swift or Kotlin you generate your own from the sdk/ffi/shared (opens in a new tab) uniffi crate. The WebView path needs no Nym-specific native code. On Android the native path has a TLS bootstrap gotcha.
End-to-end or proxy
The runtime axis is about where your code runs: a native process has raw sockets and a filesystem, so it runs the full Rust client; a browser or WebView has neither (only WebSockets and fetch, under mixed-content rules), so it runs a WASM client inside a Web Worker. The approach axis is about who runs Nym at the other end.
End-to-end: both sides run a Nym client. Traffic stays Sphinx-encrypted the whole way (what this protects). Use it for peer-to-peer setups or anywhere you control both endpoints.
Proxy: only your 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; protecting the payload (TLS, Noise) is your application's job, exactly as on a direct connection. Use it for third-party services such as blockchain RPCs or external APIs.
Past the Exit Gateway, traffic travels the public internet like any other connection. The mixnet anonymises the sender but does not encrypt the payload beyond the gateway. Use TLS or another application-layer cipher. See Exit security for what the exit can and cannot observe.
In a browser or WebView, your app talks to that WASM client through JS bindings rather than direct calls. The mixnet behaviour is identical in both modes, only the integration shape differs. See mix-* architecture for the full picture.
Packages
Rust
| Crate | Use it for |
|---|---|
nym-sdk | End-to-end mixnet messaging, AsyncRead/AsyncWrite byte streams, client pooling. Start with the Tour. |
smolmix | TcpStream and UdpSocket over the mixnet via a userspace IP stack. Compatible with tokio-rustls, hyper, tokio-tungstenite, and the rest of the async Rust ecosystem. |
TypeScript
The four mix-* packages share one tunnel (mix-tunnel) and one WASM instance; install only what you need. See mix-* architecture for how they're wired.
| Package | Use it for |
|---|---|
mix-tunnel | The shared tunnel the three feature packages build on. Most apps don't import it directly. |
mix-fetch | Drop-in fetch() for HTTP and HTTPS through the mixnet. |
mix-dns | Hostname-to-IP resolution through the mixnet. UDP DNS via the IPR. |
mix-websocket | WebSocket-like class for WS and WSS through the mixnet. |
| TypeScript SDK | @nymproject/sdk: end-to-end raw messaging when you control both ends. Smart contracts via @nymproject/contract-clients. |
Standalone and other
| Resource | Use it for |
|---|---|
| SOCKS5 / WebSocket clients | Language-agnostic binaries for piping traffic through the mixnet without an SDK. |
| Chain interaction | Query Nyx state, submit transactions, call Nym smart contracts. |
| APIs | Auto-generated reference for Nym infrastructure HTTP endpoints. |