Developers
Playground (embedded clients)

Mixnet playground

This playground runs Nym's browser TypeScript packages against the live mixnet. It covers both integration models:

  • Proxy, via the mix-* family: bring the shared tunnel up once, then drive fetch, DNS, WebSocket, stress and file-download traffic through it to clearnet destinations.
  • End-to-end, via the raw messaging SDK: Sphinx-encrypted messages between two Nym clients, with nothing exiting to the clearnet.

Some sections send the same request over the tunnel and over the clearnet, so you can compare the two.

HTTPS / DNS / WebSockets

Watch the Network tab. Open DevTools → Network before you connect. Once setupMixTunnel reports ready, every tunnel operation here (mixFetch, mixDNS, MixWebSocket) adds no new request to that tab: it is multiplexed inside the single WebSocket to the entry gateway. Only the clearnet comparison buttons add rows. (Setup also fetches the network topology over HTTPS and refreshes it periodically, so those nym-api calls and the gateway WebSocket are the only clearnet requests you will see.) Your real traffic never leaves the browser as an identifiable, per-destination request.

Everything here runs client-side over the live Nym mixnet. The first setupMixTunnel is slow (a few seconds): it loads the WebAssembly client, registers a fresh client identity with a gateway, and discovers an IPR exit. Later calls reuse the tunnel.

Connection
Advanced options
Not started
Press setupMixTunnel to bring up the tunnel.
One-shot per page: after disconnectMixTunnel you must reload to reconnect, and each load uses a fresh client identity.
This timeline shows the API-level events your code sees; the Rust client's deep transport logs (gateway, IPR discovery, smoltcp) go to the browser console behind Verbose transport logs.
DNS resolve: tunnel vs clearnet
The clearnet DoH query appears in DevTools Network; the tunnel resolution does not.
Resolve the same hostname twice: the second answer comes from the in-wasm DNS cache, served locally with no mixnet round-trip.
Idle.
GET: tunnel vs clearnet
Both buttons request the same URL, but the clearnet one reaches the server from your own IP and the tunnel one from the IPR's exit gateway.
The clearnet button is a normal browser request, so some hosts block it with CORS while the tunnel request to the same URL succeeds; the defaults here are CORS-permissive.
The first tunnel request to a host runs a full TCP + TLS handshake (visible in the browser console with debug logging on). The HTTPS connection is then pooled, so a second request to the same host skips the handshake; the log timings show the difference.
Idle.
WebSocket
Not connected
–bytes
Connecting runs a TCP handshake (plus a TLS handshake for wss://) inside the worker, visible in the browser console with debug logging on.
Idle.
Stress test
Random mix of 128 B / 1 KB / 10 KB / 100 KB / 1 MB responses (httpbin.org/bytes).
Requests to the same host share one pooled TCP + TLS connection, so only the first pays the handshake cost.
Idle.
File download
Fetches a real file over the tunnel and reports its size and SHA-256. Fetch it twice and the second download reuses the pooled HTTPS connection, skipping the handshake.
Idle.

Raw mixnet messaging

The sections above share one smolmix tunnel and exit to the clearnet through an IPR. The Messaging SDK (@nymproject/sdk) is the other model: end-to-end mixnet messages between two Nym clients, where you control both ends and nothing exits to the clearnet. It runs a separate wasm client, so it loads on demand:

Raw mixnet messaging
Creates a client with @nymproject/sdk-full-fat and sends a message to a Nym address through the mixnet (defaults to your own address). This loads a separate wasm runtime and connects its own client, so it is opt-in.
Not connected
Press Connect to create a mixnet client.

Source and examples

Per-package docs

For the API of each package, see mix-tunnel, mix-fetch, mix-dns, and mix-websocket.

FFImix-tunnel (shared tunnel)