Mixnet Components

Nym Nodes

Although a large proportion of the Nym mixnet's functionality is implemented client-side, several key anonymity features rely on the decentralised node network that make up the Mixnet that run in different modes:

• Nym Nodes running in Mix Node mode provide network security for network content and metadata by performing packet-mixing on traffic travelling through the network: accepting incoming Sphinx packets from other Nym nodes and, using a variable delay, 'mixing' them with other packets (not forwarding on received packets according to FIFO but instead relying on a randomised delay function).
• Nym Nodes running in Entry Gateway mode act as message storage for clients which may go offline and come back online again, and (once zk-nyms are enabled) check for anonymous proof of access credentials. They represent the first hop Mixnet packets travel through when travelling between clients.
• Nym Nodes running in Exit Gateway mode act as message storage for clients which may go offline and come back online again, and communicate with the wider internet on behalf of Nym Clients. They represent the last hop Mixnet packets travel through when travelling between clients and/or external services. These can be thought of somewhat analogously to Tor Exit Nodes.
• Services are applications that communicate with Nym Clients, listening and sending traffic to the Mixnet.

See the traffic flow page for detailed information on how traffic moves through the Mixnet as well as the Loopix (opens in a new tab) design paper for overview of the stratified nature of the Mixnet.

Node Smoosh Status

The various Mixnet components were originally completely separate binaries. They are in the process of being 'smooshed' together into a single nym-node binary which runs in different modes for ease of use, as well as to allow for a more developed and responsive Mixnet design, where the role of a node in a given time period is decided and changed automatically based on network conditions (more on this in the future).

Completed:

• All nodes are now a nym-node. A node's role is defined manually at runtime by the operator.
• The nym-network-requester is now part of a nym-node running in Exit Gateway mode.

Upcoming:

• Whether a nym-node is running as a Gateway or Mix Node will be set based on network conditions, and change epoch to epoch. Currently the role is set manually by the operator and does not change automatically over time. A node will be able to be running in the role of a Mix Node, an Entry Gateway, or an Exit Gateway.

Nym Clients

A large proportion of the Nym Mixnet's functionality is implemented client-side.

Clients perform the following actions on behalf of users:

• Determine network topology - what nodes exist, their public encryption keys and IP, etc.
• Register with a Gateway
• Authenticate with a Gateway
• Receive and decrypt messages from the Gateway
• Create layer-encrypted Sphinx packets
• Send Sphinx packets with real messages
• Send Sphinx packet cover traffic when no real messages are being sent
• Retransmit un-acknowledged packet sends

At the moment due to the fact that Nym clients are message-based, using the Mixnet requires another client on the 'other side' of the mixet to send packets to, unless you're using the nymvpn client (part of the NymVPN app) or the socks5 client, which operates as a SOCKS4,4a, or 5 proxy and is able to utilise the client embedded within the nym-node's Exit Gateway functionality (prev. this functionality was a standalone service, the Network Requester). In the future we wish to remove this point of friction and have all Nym clients construct IP packets instead, easing the integration burden and abstracting away the message-based nature of client communication.