What integration means
Integration is a set of per-endpoint decisions. You decide which traffic goes through the mixnet for each endpoint. Two questions pick the package. A per-endpoint pass picks what to route.
Two questions pick the package
Where does your code run, and does the other end run Nym? A browser wallet reaches an ordinary RPC provider. That puts it in one cell: the mix-* packages in proxy mode.
| Runtime | End-to-end (both ends run Nym) | Proxy (exit to the internet) |
|---|---|---|
| Native Rust | nym-sdk: Mixnet, Stream, Client Pool | smolmix, nym-sdk SOCKS5, nym-smoldvpn |
| Browser or WebView | @nymproject/sdk (raw messages) | ★ mix-fetch, mix-dns, mix-websocket on mix-tunnel |
The highlighted cell is the case this site covers: a browser wallet that reaches an ordinary RPC provider in proxy mode. The Rust column uses the same model with native sockets. It is not a different protocol, so a native integration maps straight across.
Other entry points: standalone SOCKS5 and WebSocket clients; FFI for Go and C and C++ (uniffi for Swift and Kotlin); on mobile, a WebView with the browser packages, or the Rust SDK as a native library.
The browser packages
These are what you reach for in a browser or WebView. Each is one import, all on the shared mix-tunnel:
mix-fetch
fetch() over the mixnet
mix-websocket
WebSocket over the mixnet
mix-dns
DNS over the mixnet
mix-tunnel
the shared tunnel the others run on
Routing is a per-endpoint decision
Work through these questions for each endpoint. Any one of them can change the answer on its own.
| Question | Why it decides the answer |
|---|---|
| Does it see something that identifies this user? An account address, an authenticated session, a device ID, an email. | This is the reason to route first. A destination that sees no application identifier has less to correlate, but it still sees and logs the IP address itself. |
| Is it HTTPS? | The exit gateway reads plain HTTP in full, so routing an http:// endpoint moves the observer without removing it. |
| Does a user wait on it? A request that blocks a screen, against a background refresh. | Latency is the mechanism, not a shortfall you can tune away. Deferred work absorbs it; a call in front of a user does not. |
| Is it called in sequence with others? | Sequential dependent calls multiply the cost, and no single request reveals it. |
| Can you reach its transport at all? | Third-party frames, vendor SDKs and libraries that do their own networking stay outside your control, whatever your policy says. |
Route the smallest set that identifies users over HTTPS, then widen it. Starting broad means debugging the routing underneath a UI that already hangs.
What cannot be routed from a web runtime
Some traffic never reaches your JavaScript. Record it: your users stay exposed through this traffic even after the routed part works.
| Source | Why it is out of reach |
|---|---|
| Cross-origin iframes | A separate browsing context with its own networking. Embedded swap widgets, on-ramp providers and dApp frames route nothing through your code. |
| Vendor SDKs in their own contexts | Payment and identity providers, analytics loaders, and connect libraries that open their own windows or frames. |
| Third-party WebSocket relays | mix-websocket carries ws and wss, but a library that opens its own WebSocket will not use it without an adapter. |
| Hardware wallets | Some paths are local and touch no network at all (WebHID, WebUSB). Others reach out from a vendor-hosted page that you do not control. |
| Browser-initiated requests | navigator.sendBeacon, EventSource, <img> and <script> sources, and prefetch hints. |
If a destination in that table learns something you want to hide, no transport change fixes it. Drop the integration or move it behind your own backend.
Prove the traffic went through the mixnet
Routing code that fails to route raises no error, so add a check underneath it that does (the browser-routing page has the code). Three checks exist. Detection traps direct requests to a routed host and reports them as bugs; it proves that your code ran. Positive proof compares the source address one echo service sees over the tunnel and over the clearnet; only this check proves that a request went through the mixnet. Enforcement removes the direct path at the platform level; it stops bypasses, within what the platform governs.
What the integration gets you
The destination stops seeing the user’s IP address, for the endpoints you routed. It still sees request timing, request content, and any identifier your requests already carry. Traffic you could not route still shows the real address. Report the result as that, not as “the app is now private”.