diff --git a/documentation/docs/pages/network/architecture/mixnet.mdx b/documentation/docs/pages/network/architecture/mixnet.mdx index 352db039d8..4843a292a6 100644 --- a/documentation/docs/pages/network/architecture/mixnet.mdx +++ b/documentation/docs/pages/network/architecture/mixnet.mdx @@ -32,7 +32,7 @@ Upcoming: ## Nym Clients - You can read about setting up and using various clients in the [Developer Docs](../../developers/clients). + You can read about setting up and using various clients in the [Developer Docs](../../developers/clients/socks5). A large proportion of the Nym Mixnet's functionality is implemented client-side. @@ -48,4 +48,4 @@ Clients perform the following actions on behalf of users: * Send Sphinx packet [cover traffic](../concepts/cover-traffic) when no real messages are being sent * Retransmit [un-acknowledged packet sends](../traffic/acks) -> At the moment due to the fact that Nym clients are [message-based](../../developers/concepts/messages), 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. +> 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.