What We Learned Running Services Through Nym
Nym is an interesting mixnet. It can hide traffic patterns far better than a normal low-latency proxy. After building real services around it, however, we found a different problem: the network is difficult to treat as dependable infrastructure.
This is not a report about mistakes in our applications. NymDrop, N2Usenet, and our small IRCv3 connector were useful precisely because they forced us to use the official client and gateway path as ordinary users would. The issues below are the structural and network-level problems that kept appearing at that boundary.
Three projects, one recurring lesson
NymDrop is an anonymous submission system. N2Usenet carries a message through a Nym SOCKS path before it reaches a mail gateway and Usenet. The IRCv3 connector sends a normal TLS IRC session through the same kind of SOCKS exit. They have different application protocols, but the same transport dependency: a local SOCKS port, an entry gateway, the mixnet, a requester or exit gateway, and a remote service.
The mixnet can be cryptographically healthy while the complete path is not. That distinction is the main thing we think users should understand.
The address is tied to the gateway
A Nym service address is not just a stable service identity. It includes the gateway through which the service is reached. When a requester changes gateway, the address distributed to clients changes too.
That is a serious design problem for a permanent service. Gateways expire, lose capacity, become unreachable, or need maintenance. Failover should be invisible to clients. In this model, failover can invalidate the address that every client has saved. The network has anonymity-oriented addressing, but not the equivalent of a stable service name with built-in failover.
SOCKS can say yes while the path is dead
The local SOCKS client sometimes returned request granted before an
end-to-end connection existed. We saw accepted connections that never produced
the first application greeting at the remote side. From the application's point
of view, the socket opened and then became a silent timeout.
This is not a minor status-message issue. A local process being alive is not a useful readiness signal when the remote data plane is asynchronous. Applications need a reliable way to distinguish "the SOCKS listener is running" from "the requested destination can actually be reached". The official path did not give us that distinction early enough.
Bandwidth and credentials are part of availability
Nym's economic and credential systems are part of the transport, whether an application wants them to be or not. A gateway can remain registered and the client can remain active while the usable bandwidth is effectively zero. The process looks healthy, the port is listening, and messages still fail.
That creates a hidden dependency on ticketbooks, gateway registration, provider capacity, and network operator uptime. These are reasonable ingredients for a metered mixnet, but they make a public service much harder to operate than a simple encrypted tunnel. A health check that only checks the process is not checking the thing users actually depend on.
Exit policies are not a capability system
The exit path decides what the service can reach. In our IRC test, several independent gateways rejected the same TLS IRC destination, even though HTTPS through the mixnet worked. The SOCKS interface was identical, but the useful application capability was not.
This matters for every protocol that is not ordinary web traffic. SMTP ports, IRC ports, and other destinations can be blocked by policy or by requester behaviour. There was no dependable client-side discovery step saying which exit could actually carry a given protocol. The result was trial and error followed by timeouts, not a clean capability error.
Reply state makes recovery fragile
Nym's asynchronous replies depend on SURBs and related local state. After an unclean stop, preserving or discarding that state becomes part of the delivery path. A conservative cleanup policy may protect security, but it can also make an interrupted service lose the ability to complete replies that were already in flight.
For a short interactive session this may be acceptable. For a public inbox or a posting gateway, crash recovery and reply continuity need to be first-class properties, not an implementation detail hidden inside the client.
Why we are building Fog
We still value the mixnet idea: batching, delay, padding, and cover traffic are the right tools against traffic analysis. Our concern is the gap between those privacy properties and the operational contract required by a service that must be reachable every day.
Fog is our attempt to start from that missing contract: stable addressing, explicit readiness, bounded queues, authenticated topology, deliberate failover, and recovery designed into the protocol. It is not a claim that building a new mixnet is easy. It is a conclusion from using one in anger: anonymity and availability have to be designed together.