GRIN/nym
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fixed broken link (#6193)

Browse Source
This commit is contained in:
mfahampshire
2025-11-12 15:12:38 +00:00
committed by GitHub
parent 386e1790dd
commit fa40acbeca
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/docs/pages/network/architecture/mixnet.mdx
+2 -2
View File
@@ -32,7 +32,7 @@ Upcoming:
## Nym Clients
<Callout type="info" emoji="ℹ️">
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).
</Callout>
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.