Max/docs gen update (#5333)
* update landing page icons * new architecture diagram * force dark theme * new nyx consolidated page * epoch page * overhaul traffic flow + add diagram * note on dvpn mode * fix formatting of lists * remove old todo
This commit is contained in:
mfahampshire
@@ -6,10 +6,14 @@ import { useTheme } from "@mui/material/styles";
|
||||
import Image from "next/image";
|
||||
import Link from "next/link";
|
||||
|
||||
import networkDocs from "../public/images/landing/network-docs.png";
|
||||
import developerDocs from "../public/images/landing/developer-docs.png";
|
||||
import sdkDocs from "../public/images/landing/sdk-docs.png";
|
||||
import operatorGuide from "../public/images/landing/operator-guide.png";
|
||||
// import networkDocs from "../public/images/landing/network-docs.png";
|
||||
// import developerDocs from "../public/images/landing/developer-docs.png";
|
||||
// import sdkDocs from "../public/images/landing/sdk-docs.png";
|
||||
// import operatorGuide from "../public/images/landing/operator-guide.png";
|
||||
import networkDocs from "../public/images/landing/Vector1.png";
|
||||
import developerDocs from "../public/images/landing/Vector2.png";
|
||||
import sdkDocs from "../public/images/landing/Vector3.png";
|
||||
import operatorGuide from "../public/images/landing/Vector4.png";
|
||||
export const LandingPage = () => {
|
||||
const theme = useTheme();
|
||||
const isTablet = useMediaQuery(theme.breakpoints.up("md"));
|
||||
|
||||
@@ -100,7 +100,7 @@ const config = {
|
||||
},
|
||||
{
|
||||
source: "/docs/nodes/overview.html ",
|
||||
destination: "/docs/network/architecture/mixnet/nodes",
|
||||
destination: "/docs/network/architecture/mixnet#nym-nodes",
|
||||
permanent: true,
|
||||
basePath: false,
|
||||
},
|
||||
@@ -132,21 +132,19 @@ const config = {
|
||||
},
|
||||
{
|
||||
source: "/docs/nyx/smart-contracts.html",
|
||||
destination: "/docs/network/architecture/nyx/smart-contracts",
|
||||
destination: "/docs/network/architecture/nyx#smart-contracts",
|
||||
permanent: true,
|
||||
basePath: false,
|
||||
},
|
||||
{
|
||||
source: "/docs/nyx/mixnet-contract.html",
|
||||
destination:
|
||||
"/docs/network/architecture/nyx/smart-contracts/mixnet-contract",
|
||||
destination: "/docs/network/architecture/nyx#mixnet-contract",
|
||||
permanent: true,
|
||||
basePath: false,
|
||||
},
|
||||
{
|
||||
source: "/docs/nyx/vesting-contract.html",
|
||||
destination:
|
||||
"/docs/network/architecture/nyx/smart-contracts/vesting-contract",
|
||||
destination: "/docs/network/architecture/nyx#vesting-contract",
|
||||
permanent: true,
|
||||
basePath: false,
|
||||
},
|
||||
@@ -631,7 +629,7 @@ const config = {
|
||||
},
|
||||
{
|
||||
source: "/docs/network/architecture/nyx/smart-contracts/ecash",
|
||||
destination: "/docs/network/architecture/nyx/smart-contracts/zknym",
|
||||
destination: "/docs/network/architecture/nyx#zk-nym-contract",
|
||||
permanent: true,
|
||||
basePath: false,
|
||||
},
|
||||
|
||||
@@ -9,7 +9,7 @@ At present, there are three Nym clients. These are built as standalone binaries
|
||||
- the SOCKS5 client - most easily accessed via the [Rust SDK](./rust).
|
||||
- the wasm (webassembly) client - most easily via the [Typescript SDK](./typescript).
|
||||
|
||||
> For information about the role that clients play within the Nym system and their role when communicating with the Mixnet, see the [Client network docs](../network/architecture/mixnet/clients).
|
||||
> For information about the role that clients play within the Nym system and their role when communicating with the Mixnet, see the [Client network docs](../network/architecture/mixnet#nym-clients).
|
||||
|
||||
### The websocket client
|
||||
This is a compiled program that can run on Linux, Mac OS X, and Windows machines. It can be run as a persistent process on a desktop or server machine. You can connect to it with **any language that supports websockets**.
|
||||
|
||||
@@ -45,7 +45,7 @@ make
|
||||
```
|
||||
|
||||
## Mnemonic Generation
|
||||
Create an account at [nymvpn.com](https://nymvpn.com) to obtain your mnemonic.
|
||||
Head to the mnemonic generator at [https://nym.com/account/create](https://nym.com/account/create) and obtain a mnemonic.
|
||||
|
||||
## Start the daemon
|
||||
```sh
|
||||
|
||||
@@ -43,7 +43,7 @@ npm install @nymproject/sdk-full-fat
|
||||
The Nyx blockchain is a general-purpose CosmWasm-enabled smart contract platform, and the home of the smart contracts which keep track of the mixnet, amongst others.
|
||||
Further information about the chain can be found on the [Nyx blockchain explorer](https://nym.explorers.guru/).
|
||||
|
||||
Using the [Nym mixnet smart contract clients](../../network/architecture/nyx/smart-contracts), you will be able to query contract states or execute methods when providing a signing key.
|
||||
Using the [Nym mixnet smart contract clients](../../network/architecture/nyx#smart-contracts), you will be able to query contract states or execute methods when providing a signing key.
|
||||
|
||||
*You can learn about our different methods to interact with the chain [here](../chain)*.
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Network Components
|
||||
|
||||
Core components:
|
||||
* A **Mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the [**Loopix** design](concepts/loopix). This is made up of [Nym nodes](architecture/mixnet/nodes) runnning on servers around the world.
|
||||
* A **Mixnet**, which mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the [**Loopix** design](concepts/loopix). This is made up of [Nym nodes](architecture/mixnet/nodes) runnning on servers around the world maintained by a decentralised group of Operators.
|
||||
* Various [**Nym clients**](architecture/mixnet/clients) which manage sending and receiving Sphinx packets, encrypting/decrypting traffic, and providing [cover traffic](./concepts/cover-traffic) to hide 'real' traffic timing.
|
||||
* A CosmWasm-enabled blockchain called [**Nyx**](architecture/nyx), the home of the various smart contracts used by the mixnet.
|
||||
* A CosmWasm-enabled blockchain called [**Nyx**](architecture/nyx), the home of the various smart contracts used by the mixnet. A subset of Nyx Validators run [NymAPI]() TODO LINK instances, taking part in also producing and verifying [zk-nym credentials](cryptography/zk-nym).
|
||||
|
||||
|
||||
|
||||
@@ -1,16 +1,54 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
// TODO REDIRECTS FROM PREVIOUS PAGES TO THESE NEW SUBSECTIONS
|
||||
|
||||
|
||||
# Mixnet Components
|
||||
The mixnet is made up of nodes running in several different roles:
|
||||
* **Mix Nodes** provide network security for network content _and_ metadata by performing packet-mixing on traffic travelling through the network.
|
||||
* **Gateways** 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 and last hop Mixnet packets travel through when travelling between clients.
|
||||
* **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the Network Requester.
|
||||
|
||||
> **Clients** are used to connect to and send messages through the Mixnet to other clients, utilising Gateways for ingress and exit. These are however on the 'user' side and not a Mixnet component per se.
|
||||
## Nym Nodes
|
||||
|
||||
## Smoosh Status
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
|
||||
If you want to run a node, the setup and maintenance guides can be found in the [Operator Docs](../../../operators/introduction).
|
||||
|
||||
</Callout>
|
||||
|
||||
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](../traffic) page for detailed information on how traffic moves through the Mixnet as well as the [Loopix](https://arxiv.org/pdf/1703.00536) 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:
|
||||
* The `nym-network-requester` is now part of a `nym-node` running in as an Exit Gateway.
|
||||
* 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
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
You can read about setting up and using various clients in the [Developer Docs](../../developers/clients).
|
||||
</Callout>
|
||||
|
||||
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](../cryptography/sphinx)
|
||||
* Send Sphinx packets with real messages
|
||||
* 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.
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"nodes": "Nodes",
|
||||
"clients": "Clients"
|
||||
}
|
||||
@@ -1,22 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Nym Clients
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
You can read about setting up and using various clients in the [developer docs](../../../developers/clients).
|
||||
</Callout>
|
||||
|
||||
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, etc.
|
||||
* Register with a gateway
|
||||
* Authenticate with a gateway
|
||||
* Receive and decrypt messages from the gateway
|
||||
* Create layer-encrypted [Sphinx packets](../../cryptography/sphinx)
|
||||
* Send Sphinx packets with real messages
|
||||
* 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.
|
||||
@@ -1,19 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Mixnet Nodes
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
|
||||
If you want to run a node, the setup and maintenance guides can be found in the [Operator Guides book](../../../operators/introduction).
|
||||
|
||||
</Callout>
|
||||
|
||||
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.
|
||||
|
||||
As outlined on the previous page, the various types of Mixnet nodes - Mix Nodes, Gateways, and Network Requesters - are in the process of being compounded into a single `nym-node` binary which will run performing the features of all three nodes:
|
||||
- Acting as the first and last hops for traffic moving through the mixnet - a role fulfilled currently by Gateways.
|
||||
- (Once the payment system is turned on) checking client credentials to check for payment via the [zk-nym scheme](../../cryptography/zk-nym) - a role fulfilled currently by Entry Gateways.
|
||||
- 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) - a role currently fulfilled by Mix Nodes.
|
||||
- Forwarding packets on to their final destination: the 'receiving' Nym client.
|
||||
|
||||
See the [traffic flow](../../traffic) page for detailed information on how traffic moves through the Mixnet as well as the [Loopix](https://arxiv.org/pdf/1703.00536) design paper for overview of the stratified nature of the Mixnet.
|
||||
@@ -10,6 +10,80 @@ If you want to run a Validator node, check the [Operator guides](../../../operat
|
||||
|
||||
</Callout>
|
||||
|
||||
Nyx is a Cosmos SDK blockchain. It records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards.
|
||||
Nyx is a Cosmos SDK blockchain. The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet](#mixnet-contract), [Vesting](#vesting-contract) and [zk-nym](#zk-nym-contract) smart contracts are deployed.
|
||||
|
||||
The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain (the other being `NYX`, used for Blockchain consensus), and the chain is where the Mixnet, Vesting, and zk-nym-related smart contracts are deployed.
|
||||
## Validators
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
The validator setup and maintenance guide can be found in the [Operator Docs](../../../operators/nodes/validator-setup).
|
||||
</Callout>
|
||||
|
||||
Validators secure the Nyx blockchain via Proof of Stake consensus. The Nyx blockchain records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. The Nyx validators are run via the `nyxd` binary ([codebase](https://github.com/nymtech/nyxd)), maintaining a CosmWasm- and IBC-enabled blockchain.
|
||||
|
||||
Detailed info on Nyx Validators and token flow can be found in [Nym Reward Sharing for Mixnets document](https://nym.com/nym-cryptoecon-paper.pdf) in section 2.3 and 2.4 and in the [Nym Whitepaper](https://nym.com/nym-whitepaper.pdf) section 3.1.
|
||||
|
||||
## NymAPI
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
The Nym API setup and maintenance guide has moved to the [Operator Guides book](../../../operators/nodes/validator-setup/nym-api).
|
||||
</Callout>
|
||||
|
||||
The NymAPI is a binary operated by a subset of the Nyx validator set. This binary can be run in several different modes, and has two main bits of functionality:
|
||||
|
||||
* Network monitoring (calculating the routing score of Mixnet nodes)
|
||||
* Generation and validation of [zk-nyms](../cryptography/zk-nym/zk-nym-overview), a combination of the Coconut Selective Disclosure Credential and Offline Ecash schemes.
|
||||
|
||||
This is important for both the proper decentralisation of the network uptime calculation and, more pressingly, enabling the NymVPN to utilise privacy preserving payments.
|
||||
|
||||
## Smart Contracts
|
||||
The Nyx blockchain is [CosmWasm](https://cosmwasm.com/) enabled.
|
||||
|
||||
The following contracts are deployed to the chain:
|
||||
* The [Mixnet contract](#mixnet-contract) which manages the network topology of the mixnet and tracks delegations & rewarding.
|
||||
* The [Vesting contract](#vesting-contract) which manages `NYM` token vesting functionality. This will soon be deprecated.
|
||||
* The [Quorum Multisig](#multisig-contract) used by the subset of the Nyx Validators that generate and validate [zk-nyms](../cryptography/zk-nym) to manage reward payouts for nodes.
|
||||
* The [zk-nym contract](#zk-nym-contract) which keeps track of `NYM` deposits used as payment for zk-nym generation.
|
||||
|
||||
The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
|
||||
|
||||
### Interacting with Contracts
|
||||
You can use the [API docs](../../apis/introduction) to see how you can interact with the contracts. The [NymAPI](../../apis/nym-api) in particular has multiple endpoints to query the Mixnet state, topology, and various zk-Nym-related endpoints.
|
||||
|
||||
### Mixnet Contract
|
||||
The Mixnet smart contract is a core piece of the Nym system, functioning as the mixnet directory and keeping track of delegations and rewards: the core functionality required by an incentivised mixnet. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/mixnet).
|
||||
|
||||
> Having a smart contract act as a decentralised topology directory for clients connecting to the Mixnet allows us to mitigate several possible attacks which systems relying on P2P networking are susceptible to. See [Why Nym is not P2P](./nym-not-p2p).
|
||||
|
||||
The Mixnet contract has multiple functions:
|
||||
* Storing bonded mix node and gateway information (and removing this on unbonding).
|
||||
* **Providing the network-topology to the (cached) Validator API endpoint used by clients on startup for routing information.**
|
||||
* Storing delegation and bond amounts.
|
||||
* Storing reward amounts.
|
||||
|
||||
### Vesting Contract
|
||||
The vesting contract allows for the creation of vesting accounts, allowing `NYM` tokens to vest over time, and for users to minimally interact with the Mixnet using their unvested tokens. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/vesting).
|
||||
|
||||
The Vesting contract has multiple functions:
|
||||
* Creating and storing vesting `NYM` token vesting accounts.
|
||||
* Interacting with the Mixnet using vesting (i.e. non-transferable) tokens, allowing users to delegate their unvested tokens.
|
||||
|
||||
### Multisig Contract
|
||||
The multisig contract used by the [NymAPI Quroum](../cryptography/zk-nym/zk-nym-overview) - a subset of the Nyx Validator set taking on the additional work of generating and validating zk-nyms - to execute certain actions in the [zk-nym](./ecash.md) contract.
|
||||
|
||||
It is essentially an instance of the [canonical](https://github.com/CosmWasm/cw-plus/tree/main/contracts) `cw3-flex-multisig` using the `cw4-group` contract, with one minor change to restrict the addresses allowed to submit proposals.
|
||||
|
||||
### Zk-Nym Contract
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Note that within the monorepo contract repo this contract is referred to as `ecash`. This is a historical artifact that hasn't yet been changed.
|
||||
</Callout>
|
||||
|
||||
This contract is a hub for zk-nym related actions, being called by either:
|
||||
- The zk-nym payment backend
|
||||
- Nodes running in Gateway mode
|
||||
- The multisig contract
|
||||
|
||||
The following functionality is controlled by the multisig contract:
|
||||
- Getting the list of blacklisted addresses who have tried to double-spend a zk-nym.
|
||||
- Proposing to add an address to the blacklist.
|
||||
- Executing an open proposal.
|
||||
- The the zk-nym [payment backend](../cryptography/zk-nym/zk-nym-overview) can deposit funds with information used to identify the deposit.
|
||||
- Finally, nodes running as Gateways can create a proposal to redeem a set of spend zk-nyms.
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
{
|
||||
"validator": "Validators",
|
||||
"nym-api": "Nym API",
|
||||
"smart-contracts": "Smart Contracts"
|
||||
}
|
||||
@@ -1,14 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Nym API
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
The Nym API setup and maintenance guide has moved to the [Operator Guides book](../../../operators/nodes/validator-setup/nym-api).
|
||||
</Callout>
|
||||
|
||||
The Nym API is a binary that will be operated by the Nyx validator set. This binary can be run in several different modes, and has two main bits of functionality:
|
||||
|
||||
* Network monitoring (calculating the routing score of Mixnet nodes)
|
||||
* Generation and validation of [zk-nyms](../../cryptography/zk-nym/zk-nym-overview), a combination of the Coconut Selective Disclosure Credential and Offline Ecash schemes.
|
||||
|
||||
This is important for both the proper decentralisation of the network uptime calculation and, more pressingly, enabling the NymVPN to utilise privacy preserving payments.
|
||||
@@ -1,9 +0,0 @@
|
||||
# Smart Contracts
|
||||
|
||||
The Nyx blockchain is based on [CosmWasm](https://cosmwasm.com/).
|
||||
|
||||
The following contracts are deployed to the chain:
|
||||
* the [Mixnet contract](./smart-contracts/mixnet-contract.md) which manages the network topology of the mixnet and tracks delegations & rewarding.
|
||||
* the [Vesting contract](./smart-contracts/vesting-contract.md) which manages `NYM` token vesting functionality. This will soon be deprecated.
|
||||
* the [Quorum Multisig](./smart-contracts/multisig.md) used by the subset of the Nyx Validators that generate and validate [zk-nyms](../../cryptography/zk-nym) to manage reward payouts for nodes.
|
||||
* the [zk-nym contract](./smart-contracts/ecash.md) which keeps track of `NYM` deposits used as payment for zk-nym generation.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Mixnet Contract
|
||||
|
||||
The Mixnet smart contract is a core piece of the Nym system, functioning as the mixnet directory and keeping track of delegations and rewards: the core functionality required by an incentivised mixnet. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/mixnet).
|
||||
|
||||
> Having a smart contract act as a decentralised topology directory for clients connecting to the Mixnet allows us to mitigate several possible attacks which systems relying on P2P networking are susceptible to. See [Why Nym is not P2P](../../nym-not-p2p).
|
||||
|
||||
Functionality
|
||||
The Mixnet contract has multiple functions:
|
||||
* storing bonded mix node and gateway information (and removing this on unbonding).
|
||||
* **providing the network-topology to the (cached) Validator API endpoint used by clients on startup for routing information.**
|
||||
* storing delegation and bond amounts.
|
||||
* storing reward amounts.
|
||||
|
||||
> The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
|
||||
@@ -1,8 +0,0 @@
|
||||
# Multisig Contract
|
||||
|
||||
The multisig contract used by the [NymAPI Quroum](../../../cryptography/zk-nym/zk-nym-overview) - a subset of the Nyx Validator set taking on the additional work of generating and validating zk-nyms - to execute certain actions in the [zk-nym](./ecash.md) contract.
|
||||
|
||||
It is essentially an instance of the [canonical](https://github.com/CosmWasm/cw-plus/tree/main/contracts) `cw3-flex-multisig` using the `cw4-group` contract, with one minor change to restrict the addresses allowed to submit proposals.
|
||||
|
||||
|
||||
> The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
|
||||
-10
@@ -1,10 +0,0 @@
|
||||
# Vesting Contract
|
||||
|
||||
The vesting contract allows for the creation of vesting accounts, allowing `NYM` tokens to vest over time, and for users to minimally interact with the Mixnet using their unvested tokens. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/vesting).
|
||||
|
||||
### Functionality
|
||||
The Vesting contract has multiple functions:
|
||||
* Creating and storing vesting `NYM` token vesting accounts.
|
||||
* Interacting with the Mixnet using vesting (i.e. non-transferable) tokens, allowing users to delegate their unvested tokens.
|
||||
|
||||
> The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
|
||||
@@ -1,25 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Zk-Nym Contract
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Note that within the monorepo contract repo this contract is referred to as `ecash`. This is a historical artifact that hasn't yet been changed.
|
||||
</Callout>
|
||||
|
||||
This contract is a hub for zk-nym related actions, being called by either:
|
||||
- the zk-nym payment backend
|
||||
- nodes running in Gateway mode
|
||||
- the multisig contract
|
||||
|
||||
### Functionality
|
||||
|
||||
- The following functionality is controlled by the multisig contract:
|
||||
- getting the list of blacklisted addresses who have tried to double-spend a zk-nym.
|
||||
- proposing to add an address to the blacklist.
|
||||
- executing an open proposal.
|
||||
|
||||
- The the zk-nym [payment backend](../../../cryptography/zk-nym/zk-nym-overview) can deposit funds with information used to identify the deposit.
|
||||
|
||||
- Finally, nodes running as Gateways can create a proposal to redeem a set of spend zk-nyms.
|
||||
|
||||
> The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
|
||||
@@ -1,15 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Validators
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
The validator setup and maintenance guide has moved to the [Operator Guides book](../../../operators/nodes/validator-setup).
|
||||
</Callout>
|
||||
|
||||
Validators secure the Nyx blockchain via Proof of Stake consensus. The Nyx blockchain records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. The Nyx validators are run via the `nyxd` binary ([codebase](https://github.com/nymtech/nyxd)), maintaining a CosmWasm- and IBC-enabled blockchain.
|
||||
|
||||
The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet](./smart-contracts/mixnet-contract), [Vesting](./smart-contracts/vesting-contract) and [zk-nym](./smart-contracts/ecash) smart contracts are deployed.
|
||||
|
||||
## Further Reading
|
||||
* Detailed info on Nyx Validators and token flow can be found in [Nym Reward Sharing for Mixnets document](https://nymtech.net/nym-cryptoecon-paper.pdf) in section 2.3 and 2.4.
|
||||
* [Nym Whitepaper](https://nym.com/nym-whitepaper.pdf) section 3.1
|
||||
@@ -1,2 +1,2 @@
|
||||
# Core Concepts
|
||||
There are a lot of moving parts with the Nym system, conceptually and otherwise. This section contains an overview of the main concepts you will need to understand the motivations and technologies behind the Mixnet.
|
||||
The balancing act of creating a working incentivised decentralised overlay network involves multiple mutually-supporting mechanisms that are novel and/or experimental. This section contains an overview of the main concepts you will need to understand the motivations and technologies behind the Mixnet and how it provides the privacy qualities that it does.
|
||||
|
||||
@@ -2,5 +2,6 @@
|
||||
"mixing": "Packet Mixing",
|
||||
"loopix": "Loopix",
|
||||
"cover-traffic": "Cover Traffic",
|
||||
"anonymous-replies": "Anonymous Replies"
|
||||
"anonymous-replies": "Anonymous Replies",
|
||||
"epochs": "Epochs"
|
||||
}
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
# Epochs
|
||||
|
||||
Time in the context of the Mixnet is organised into epochs. The length of an epoch is configurable but currently set to be one hour.
|
||||
|
||||
Several actions happen per epoch:
|
||||
- Reward calculation and distribution for Nym Nodes. See the [Operator Docs](../../operators/tokenomics/mixnet-rewards) for more information on reward calculation.
|
||||
- Topology rerandomisation: the arrangement of each layer of the Mixnet is re-randomised in order to make it more difficult for dishonest nodes to create 'full routes' of dishonest nodes running modified software. Currently, this is also where Nodes may enter or leave the active set based on uptime monitoring.
|
||||
@@ -1,5 +1,4 @@
|
||||
{
|
||||
"sphinx": "Sphinx",
|
||||
"zk-nym": "Zk-Nym Credentials",
|
||||
"node-to-node": "(Coming soon) Node to Node Communication"
|
||||
"zk-nym": "Zk-Nym Credentials"
|
||||
}
|
||||
|
||||
@@ -15,7 +15,7 @@ import { Callout } from 'nextra/components'
|
||||
|
||||
Generation of zk-nyms involves the following actors / pieces of infrastructure:
|
||||
- **Requester needing a zk-nym** for example a single user using the NymVPN app, or a company purchasing zk-nyms to distribute to their app users, in the instance of an app integrating a Mixnet client via one of the SDKs. The Requester is represented by a Bech32 address on the Nyx blockchain.
|
||||
- [NymAPI](../../architecture/nyx/nym-api) instances working together on signature generation and spent credential validation, referred to as the **NymAPI Quorum**. Members of the Quorum are a subset of the Nyx chain Validator set (other tasks they perform include a multisig used for triggering reward payouts to the Network Infrastructure Node Operators and maintaining the global Bloom Filter for double-spend protection).
|
||||
- [NymAPI](../../architecture/nyx#nym-api) instances working together on signature generation and spent credential validation, referred to as the **NymAPI Quorum**. Members of the Quorum are a subset of the Nyx chain Validator set (other tasks they perform include a multisig used for triggering reward payouts to the Network Infrastructure Node Operators and maintaining the global Bloom Filter for double-spend protection).
|
||||
- **OrderAPI**: an API creating crypto/fiat to `NYM` swaps and then depositing the NYM tokens in a smart contract managed by the NymAPI Quroum for payment verification. Implementation details of the API will be released in the coming months.
|
||||
|
||||
Generation happens in 3 distinct stages:
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Mixnet Traffic Flow Overview
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
> Nym uses a source-routed decryption mixnet, with users obtaining the node’s public keys and contact information from the Nym blockchain. In source routing, the sender of a message chooses the route that the message will traverse before reaching its final destination.
|
||||
# Traffic Flow
|
||||
|
||||
> Nym uses a source-routed decryption mixnet ... [i]n source routing, the sender of a message chooses the route that the message will traverse before reaching its final destination.
|
||||
>
|
||||
> ...
|
||||
>
|
||||
@@ -8,58 +10,14 @@
|
||||
>
|
||||
> [Nym Whitepaper](https://nym.com/nym-whitepaper.pdf) §4
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Please note that the following information is only about how traffic flows through the Mixnet, which is the **only** method that Nym Clients use, and is defined as 'anonymous' mode in the NymVPN application. DVPN 'speedy' mode is different, and you can read about that [here](https://nymcom.vercel.app/blog/decentralized-vpns).
|
||||
</Callout>
|
||||
|
||||
The Nym mixnet re-orders encrypted, indistinguishable [Sphinx](cryptography/sphinx) packets as they travel through the network.
|
||||
|
||||
Traffic to send through the mixnet is broken up into uniformly-sized packets, encrypted in the Sphinx packet format according to the route the packet will take, and sent through the mixnet to be mixed among other real traffic and fake - but identical - cover traffic.
|
||||
Traffic to send through the mixnet is broken up into uniformly-sized packets, encrypted in the Sphinx packet format according to the route the packet will take, and sent through the mixnet to be mixed among other real traffic and fake - but identical - cover traffic. At each 'hop' (i.e. as a packet is forwarded from one node in the sequence to another) a layer of decryption is removed from the Sphinx packet, revealing the address of the next hop, and another Sphinx packet. The packet is then held by the node for a variable amount of time, before being forwarded on to the next node in the route.
|
||||
|
||||
At each 'hop' (i.e. as a packet is forwarded from one node in the sequence to another) a layer of decryption is removed from the Sphinx packet, revealing the address of the next hop, and another Sphinx packet. The packet is then held by the node for a variable amount of time, before being forwarded on to the next node in the route.
|
||||
|
||||
Traffic always travels through the nodes of the mixnet like such:
|
||||
|
||||
```mermaid
|
||||
---
|
||||
config:
|
||||
theme: neo-dark
|
||||
layout: elk
|
||||
---
|
||||
flowchart LR
|
||||
subgraph Local Machine[Local Machine]
|
||||
A[Application Logic]
|
||||
B[Nym Client]
|
||||
end
|
||||
A <-->|Bytes| B
|
||||
B <-->|Sphinx Packets| EG
|
||||
|
||||
subgraph Mixnet Nodes[Mixnet Nodes]
|
||||
EG[/Entry Gateway/]
|
||||
M{Mix Node Layer 1}
|
||||
M2{Mix Node Layer 2}
|
||||
M3{Mix Node Layer 3}
|
||||
ExG[\Exit Gateway\]
|
||||
end
|
||||
EG <-->|Sphinx Packets| M
|
||||
M <-->|Sphinx Packets| M2
|
||||
M2 <-->|Sphinx Packets| M3
|
||||
M3 <-->|Sphinx Packets| ExG
|
||||
|
||||
subgraph Remote App[Remote App]
|
||||
C[Application Logic]
|
||||
D[Nym Client]
|
||||
end
|
||||
D <-->|Sphinx Packets| ExG
|
||||
C <-->|Bytes| D
|
||||
```
|
||||
|
||||
From your Nym client, your traffic is sent as Sphinx packets to:
|
||||
* the gateway your client has registered with,
|
||||
* a mix node on layer 1 of the Mixnet,
|
||||
* a mix node on layer 2 of the Mixnet,
|
||||
* a mix node on layer 3 of the Mixnet,
|
||||
* the recipient's gateway, which forwards it finally to...
|
||||
* the recipient's Nym client, which communicates with an application.
|
||||
|
||||
As each node receives the packet, they are able to decrypt the packet, perform a validity check, and then pass the packet along (in the case of Mix Nodes, after a delay).
|
||||
|
||||
> If the recipient's Nym client is offline at the time then the packets will be held by the Gateway their Nym client has registered with until they come online.
|
||||
> How traffic moves through the Mixnet is one of the core mechanisms that provide the privacy properties of the network, but is also (aside from [SURBs](./traffic/anonymous-replies)) mostly abstracted away from developers.
|
||||
|
||||
Whatever is on the 'other side' of the mixnet from your client, all traffic will travel this way through the mixnet. If you are sending traffic to a service external to Nym (such as a chat application's servers) then your traffic will be sent from the recieving Nym client to an application that will proxy it 'out' of the mixnet to these servers, shielding your metadata from them. P2P (peer-to-peer) applications, unlike the majority of apps, might want to keep all of their traffic entirely 'within' the mixnet, as they don't have to necessarily make outbound network requests to application servers. They would simply have their local application code communicate with their Nym clients, and not forward traffic anywhere 'outside' of the mixnet.
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
"hops": {
|
||||
"display": "hidden"
|
||||
},
|
||||
"flow": "Step by Step Breakdown",
|
||||
"acks": "Acks & Retransmission",
|
||||
"addressing-system": "Addressing",
|
||||
"anonymous-replies": "Anonymous Replies",
|
||||
"follow-packet": "(Coming Soon) Follow A Packet"
|
||||
"anonymous-replies": "Anonymous Replies: SURBs"
|
||||
}
|
||||
|
||||
@@ -0,0 +1,232 @@
|
||||
# Packet Flow Breakdown
|
||||
## Sending Client → Entry Gateway
|
||||
Nym Clients, on startup, register with a particular node to use as an Entry Gateway. This partially defines their [Client Address](./addressing-system).
|
||||
|
||||
Once connected, Clients **are constantly sending traffic into the Mixnet**; as well as the packets that are sent from an application wanting to use the Mixnet, Clients send [cover traffic](../concepts/cover-traffic) at a constant rate defined by a Poisson process.
|
||||
|
||||
On accepting bytes from a locally running process, Nym Clients:
|
||||
- Send the data to the internal queue.
|
||||
- Packetise and encrypt the data as the payload of Sphinx packets. Encryption is done according to route. Routing is done on a per-packet basis.
|
||||
- Perform a Diffie Hellman Key Exchange with their Entry Gateway.
|
||||
- Open a Websocket connection with their Entry Gateway.
|
||||
- Slot Sphinx packets containing data payloads in between outgoing cover traffic packets and send these down the Websocket.
|
||||
|
||||
```mermaid
|
||||
---
|
||||
config:
|
||||
theme: neo-dark
|
||||
---
|
||||
sequenceDiagram
|
||||
box Local Machine
|
||||
participant AL as Application Logic
|
||||
participant NC as Nym Client
|
||||
end
|
||||
|
||||
box Mixnet Infrastructure
|
||||
participant EG as Entry Gateway
|
||||
end
|
||||
|
||||
EG->NC: Diffie Hellman Key Exchange
|
||||
|
||||
Note over NC,EG: Cover Traffic Stream
|
||||
loop Continuous Cover Traffic
|
||||
NC->>NC: Delay
|
||||
NC->>EG: Cover traffic
|
||||
end
|
||||
|
||||
Note over AL,EG: Mixed Traffic Stream
|
||||
loop Cover + Real Traffic Processing
|
||||
NC->>NC: Check internal queue + delay
|
||||
NC->>EG: Cover traffic
|
||||
opt Packets with Application Payload
|
||||
AL-->>NC: Send(bytes): add to internal queue
|
||||
NC->>NC: Check queue: bytes to send
|
||||
NC->>NC: Encrypt & packetise bytes
|
||||
NC->>EG: Real Packets
|
||||
NC->>NC: Check queue: more bytes
|
||||
NC->>NC: Encrypt & packetise bytes
|
||||
NC->>EG: Real Packets
|
||||
NC->>NC: Check queue: empty
|
||||
end
|
||||
NC->>NC: Delay
|
||||
NC->>EG: Cover traffic
|
||||
end
|
||||
|
||||
```
|
||||
|
||||
## Entry Gateway → Mix Nodes → Exit Gateway
|
||||
As packets move through the Mixnet, receiving nodes will:
|
||||
- Verify the MAC address of incoming Sphinx packets.
|
||||
- Forward the inner packet they have decrypted onto its next desination hop, via TCP.
|
||||
|
||||
Mix Nodes, as their name suggests, perform the 'packet mixing' by adding a randomised delay before forwarding on the packets, so they no longer travel FIFO through each layer of Mix Nodes.
|
||||
|
||||
```mermaid
|
||||
---
|
||||
config:
|
||||
theme: neo-dark
|
||||
---
|
||||
sequenceDiagram
|
||||
box Mixnet Infrastructure
|
||||
participant EG as Entry Gateway
|
||||
participant M1 as Mix Node Layer 1
|
||||
participant M2 as Mix Node Layer 2
|
||||
participant M3 as Mix Node Layer 3
|
||||
participant ExG as Exit Gateway
|
||||
end
|
||||
|
||||
Note over EG: Process packets
|
||||
EG->>EG: Decrypt outer encryption layer
|
||||
EG->>EG: Check MAC for tampering
|
||||
|
||||
Note over EG,M1: Layer 1 Transmission
|
||||
EG->>M1: Sphinx Packets
|
||||
Note over M1: Process packets
|
||||
M1->>M1: Decrypt outer encryption layer
|
||||
M1->>M1: Check MAC for tampering
|
||||
M1->>M1: Hold packet for variable time delay
|
||||
|
||||
Note over M1,M2: Layer 2 Transmission
|
||||
M1->>M2: Sphinx Packets
|
||||
Note over M2: Process packets
|
||||
M2->>M2: Decrypt outer encryption layer
|
||||
M2->>M2: Check MAC for tampering
|
||||
M2->>M2: Hold packet for variable time delay
|
||||
|
||||
Note over M2,M3: Layer 3 Transmission
|
||||
M2->>M3: Sphinx Packets
|
||||
Note over M3: Process packets
|
||||
M3->>M3: Decrypt outer encryption layer
|
||||
M3->>M3: Check MAC for tampering
|
||||
M3->>M3: Hold packet for variable time delay
|
||||
|
||||
Note over M3,ExG: Exit Gateway Transmission
|
||||
M3->>ExG: Sphinx Packets
|
||||
Note over ExG: Process packets
|
||||
ExG->>ExG: Decrypt outer encryption layer
|
||||
ExG->>ExG: Check MAC for tampering
|
||||
|
||||
```
|
||||
|
||||
## Exit Gateway → Receiving Client
|
||||
The final hop of Mixnet traffic involves:
|
||||
- The Exit Gateway for the packet route (the Entry Gateway that the receiving Nym Client registered with on startup) performing the decryption and MAC check.
|
||||
- The Exit Gateway forwards the Sphinx packet on to the Nym Client if it is online. If the Client is not online, the Gateway holds the packet for up to 24 hours.
|
||||
|
||||
The receiving Nym Client will then decrypt the final Sphinx packet layer and have access to the decrypted packet payload, and [SURB](./anonymous-replies) header information for anonymous replies.
|
||||
|
||||
```mermaid
|
||||
---
|
||||
config:
|
||||
theme: neo-dark
|
||||
---
|
||||
sequenceDiagram
|
||||
box Mixnet Infrastructure
|
||||
participant ExG as Exit Gateway
|
||||
end
|
||||
|
||||
box Remote Machine
|
||||
participant RC as Nym Client
|
||||
participant AR as Application Logic
|
||||
end
|
||||
|
||||
ExG->RC: Diffie Hellman Key Exchange
|
||||
ExG->>RC: Sphinx Packets
|
||||
Note over RC: Process packets
|
||||
RC->>RC: Decrypt outer encryption layer
|
||||
RC->>RC: Check MAC for tampering
|
||||
|
||||
RC->>AR: Bytes
|
||||
```
|
||||
|
||||
## Whole Flow
|
||||
|
||||
```mermaid
|
||||
---
|
||||
config:
|
||||
theme: neo-dark
|
||||
---
|
||||
sequenceDiagram
|
||||
box Local Machine
|
||||
participant AL as Application Logic
|
||||
participant NC as Nym Client
|
||||
end
|
||||
|
||||
box Mixnet Infrastructure
|
||||
participant EG as Entry Gateway
|
||||
participant M1 as Mix Node Layer 1
|
||||
participant M2 as Mix Node Layer 2
|
||||
participant M3 as Mix Node Layer 3
|
||||
participant ExG as Exit Gateway
|
||||
end
|
||||
|
||||
box Remote Machine
|
||||
participant RC as Nym Client
|
||||
participant AR as Application Logic
|
||||
end
|
||||
|
||||
EG->NC: Diffie Hellman Key Exchange
|
||||
|
||||
Note over NC,EG: Cover Traffic Stream
|
||||
loop Continuous Cover Traffic
|
||||
NC->>NC: Delay
|
||||
NC->>EG: Cover traffic
|
||||
end
|
||||
|
||||
Note over AL,EG: Mixed Traffic Stream
|
||||
loop Cover + Real Traffic Processing
|
||||
NC->>NC: Check internal queue + delay
|
||||
NC->>EG: Cover traffic
|
||||
opt Packets with Application Payload
|
||||
AL-->>NC: Send(bytes): add to internal queue
|
||||
NC->>NC: Check queue: bytes to send
|
||||
NC->>NC: Encrypt & packetise bytes
|
||||
NC->>EG: Real Packets
|
||||
NC->>NC: Check queue: more bytes
|
||||
NC->>NC: Encrypt & packetise bytes
|
||||
NC->>EG: Real Packets
|
||||
NC->>NC: Check queue: empty
|
||||
end
|
||||
NC->>NC: Delay
|
||||
NC->>EG: Cover traffic
|
||||
end
|
||||
|
||||
Note over EG: Process packets
|
||||
EG->>EG: Decrypt outer encryption layer
|
||||
EG->>EG: Check MAC for tampering
|
||||
|
||||
Note over EG,M1: Layer 1 Transmission
|
||||
EG->>M1: Sphinx Packets
|
||||
Note over M1: Process packets
|
||||
M1->>M1: Decrypt outer encryption layer
|
||||
M1->>M1: Check MAC for tampering
|
||||
M1->>M1: Hold packet for variable time delay
|
||||
|
||||
Note over M1,M2: Layer 2 Transmission
|
||||
M1->>M2: Sphinx Packets
|
||||
Note over M2: Process packets
|
||||
M2->>M2: Decrypt outer encryption layer
|
||||
M2->>M2: Check MAC for tampering
|
||||
M2->>M2: Hold packet for variable time delay
|
||||
|
||||
Note over M2,M3: Layer 3 Transmission
|
||||
M2->>M3: Sphinx Packets
|
||||
Note over M3: Process packets
|
||||
M3->>M3: Decrypt outer encryption layer
|
||||
M3->>M3: Check MAC for tampering
|
||||
M3->>M3: Hold packet for variable time delay
|
||||
|
||||
Note over M3,ExG: Exit Gateway Transmission
|
||||
M3->>ExG: Sphinx Packets
|
||||
Note over ExG: Process packets
|
||||
ExG->>ExG: Decrypt outer encryption layer
|
||||
ExG->>ExG: Check MAC for tampering
|
||||
|
||||
ExG->RC: Diffie Hellman Key Exchange
|
||||
ExG->>RC: Sphinx Packets
|
||||
Note over RC: Process packets
|
||||
RC->>RC: Decrypt outer encryption layer
|
||||
RC->>RC: Check MAC for tampering
|
||||
|
||||
RC->>AR: Bytes
|
||||
```
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 321 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
File diff suppressed because one or more lines are too long
Binary file not shown.
|
After Width: | Height: | Size: 2.8 MiB |
@@ -6,28 +6,33 @@ import { useRouter } from "next/router";
|
||||
|
||||
const config: DocsThemeConfig = {
|
||||
head: function useHead() {
|
||||
const config = useConfig()
|
||||
const { route } = useRouter()
|
||||
const url = process.env.NEXT_PUBLIC_SITE_URL
|
||||
const image = url + '/nym_logo.jpg'
|
||||
const config = useConfig();
|
||||
const { route } = useRouter();
|
||||
const url = process.env.NEXT_PUBLIC_SITE_URL;
|
||||
const image = url + "/nym_logo.jpg";
|
||||
|
||||
// Define descriptions for different "books"
|
||||
const bookDescriptions: Record<string, string> = {
|
||||
'/developers': "Nym's developer documentation covering core concepts of integrating with the Mixnet, interacting with the Nyx blockchain, an overview of the avaliable tools, and our SDK docs.",
|
||||
'/network': "Nym's network documentation covering network architecture, node types, tokenomics, and cryptography.",
|
||||
'/operators': "Nym's Operators guide containing information and setup guides for the various components of Nym network and Nyx blockchain validators.",
|
||||
'/apis': "Interactive APIs generated from the OpenAPI specs of various API endpoints offered by bits of Nym infrastructure run both by Nym and community operators for both Mainnet and the Sandbox testnet."
|
||||
}
|
||||
"/developers":
|
||||
"Nym's developer documentation covering core concepts of integrating with the Mixnet, interacting with the Nyx blockchain, an overview of the avaliable tools, and our SDK docs.",
|
||||
"/network":
|
||||
"Nym's network documentation covering network architecture, node types, tokenomics, and cryptography.",
|
||||
"/operators":
|
||||
"Nym's Operators guide containing information and setup guides for the various components of Nym network and Nyx blockchain validators.",
|
||||
"/apis":
|
||||
"Interactive APIs generated from the OpenAPI specs of various API endpoints offered by bits of Nym infrastructure run both by Nym and community operators for both Mainnet and the Sandbox testnet.",
|
||||
};
|
||||
|
||||
const defaultDescription = 'Nym is a privacy platform. It provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous access control using blinded, re-randomizable, decentralized credentials.'
|
||||
const defaultDescription =
|
||||
"Nym is a privacy platform. It provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous access control using blinded, re-randomizable, decentralized credentials.";
|
||||
|
||||
const topLevel = '/' + route.split('/')[1]
|
||||
const topLevel = "/" + route.split("/")[1];
|
||||
const description =
|
||||
config.frontMatter.description ||
|
||||
bookDescriptions[topLevel] ||
|
||||
defaultDescription
|
||||
defaultDescription;
|
||||
|
||||
const title = config.title + (route === '/' ? '' : ' - Nym docs')
|
||||
const title = config.title + (route === "/" ? "" : " - Nym docs");
|
||||
|
||||
return (
|
||||
<>
|
||||
@@ -53,7 +58,7 @@ const config: DocsThemeConfig = {
|
||||
|
||||
<meta name="apple-mobile-web-app-title" content="Nym docs" />
|
||||
</>
|
||||
)
|
||||
);
|
||||
},
|
||||
logo: <span>Nym Docs</span>,
|
||||
project: {
|
||||
@@ -65,6 +70,9 @@ const config: DocsThemeConfig = {
|
||||
text: Footer,
|
||||
},
|
||||
darkMode: true,
|
||||
nextThemes: {
|
||||
defaultTheme: "dark",
|
||||
},
|
||||
sidebar: {
|
||||
defaultMenuCollapseLevel: 1,
|
||||
autoCollapse: true,
|
||||
@@ -73,9 +81,8 @@ const config: DocsThemeConfig = {
|
||||
extraContent: <Matrix />,
|
||||
},
|
||||
toc: {
|
||||
float: false, // TODO would be nice to set this to false so the TOC is in the left sidebar but this doesn't seem to work with pages that are also the top of directories: fix
|
||||
// if we do this then we also have to uncomment the editLink and feedback objects below
|
||||
component: null, // try remove right-hand column
|
||||
float: false,
|
||||
component: null,
|
||||
},
|
||||
editLink: {
|
||||
component: null, // remove element
|
||||
|
||||
Reference in New Issue
Block a user