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

Add Lychee linkchecker for inter-doc links (#6438)

Browse Source 
* Add Lychee linkchecker for inter-doc links

* Fix path to linkcheckr CI

* Try fix path again

* Update lychee config

* Fix broken links

* Add Lychee usage info to readme
This commit is contained in:
mfahampshire
2026-02-10 10:59:17 +00:00
committed by GitHub
parent 49faa13855
commit 613d496133
34 changed files with 120 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/ci-docs-linkcheck.yml
+21
View File
@@ -0,0 +1,21 @@
name: ci-docs-linkcheck
on:
workflow_dispatch:
push:
paths:
- "documentation/docs/**"
- ".github/workflows/ci-docs-linkcheck.yml"
- "lychee.toml"
jobs:
linkcheck:
runs-on: arc-linux-latest
steps:
- uses: actions/checkout@v6
- name: Check links
uses: lycheeverse/lychee-action@v2
with:
args: ${{ github.workspace }}/documentation/docs/ --config ${{ github.workspace }}/lychee.toml --root-dir ${{ github.workspace }}/documentation/docs/pages/
fail: true
documentation/docs/README.md
+7 -1
View File
@@ -22,6 +22,12 @@ Our `prebuild` script relies on the following:
Otherwise make sure to have `node` installed.
### Link checking (optional)
We use [lychee](https://github.com/lycheeverse/lychee) to check for broken links. Install via your package manager or `cargo install lychee`, then run:
```sh
lychee documentation/docs/ --config lychee.toml --root-dir documentation/docs/pages/
```
### Serve Local (Hot Reload)
```sh
pnpm i
@@ -48,7 +54,7 @@ pnpm run build
> **Only run this script on branches where you want to push e.g. the build info of a binary to production docs**; it will build the monorepo binaries and use their command output for the produced markdown files.
## CI/CD
TODO
- **Link checking**: Runs on every push to `documentation/docs/` via `.github/workflows/ci-docs-linkcheck.yml`
## Licensing and copyright information
This is a monorepo and components that make up Nym as a system are licensed individually, so for accurate information, please check individual files.
documentation/docs/pages/apis/cosmos-sdk-nyx.mdx
+1 -1
View File
@@ -1,3 +1,3 @@
# Validator REST API
Since the [Nyx validators](../../operators/nodes/validator-setup) are built with the Cosmos SDK, they by default expose a [REST API](https://docs.cosmos.network/api) which can be used to query the state of the chain.
Since the [Nyx validators](/operators/nodes/validator-setup) are built with the Cosmos SDK, they by default expose a [REST API](https://docs.cosmos.network/api) which can be used to query the state of the chain.
documentation/docs/pages/apis/nym-api.mdx
+1 -1
View File
@@ -1,5 +1,5 @@
# NymAPI
The [NymAPI](../../operators/nodes/validator-setup/nym-api) is a sidecar binary operated by members of the Nym Validator set. Amongst other things, the API offers endpoints to query regarding circulating `NYM` supply, and global and ticketbook-specific [zk-nym](../../network/cryptography/zk-nym) data. This is all information contained in various smart contracts on the Nyx blockchain; the NymAPI caches this information periodically to make queries faster and more scalable.
The [NymAPI](/operators/nodes/validator-setup/nym-api) is a sidecar binary operated by members of the Nym Validator set. Amongst other things, the API offers endpoints to query regarding circulating `NYM` supply, and global and ticketbook-specific [zk-nym](/network/cryptography/zk-nym) data. This is all information contained in various smart contracts on the Nyx blockchain; the NymAPI caches this information periodically to make queries faster and more scalable.
The code for this service can be found [in our monorepo](https://github.com/nymtech/nym/tree/develop/nym-api).
documentation/docs/pages/developers/archive/nym-connect.md
+5 -5
View File
@@ -2,7 +2,7 @@
```admonish warning
Since the beginning of 2024 NymConnect is no longer maintained. Nym is developing a new client called [NymVPN](https://nymvpn.com), an application routing all users traffic thorugh the mixnet.
If users want to route their traffic through socks5 we advice to use maintained [Nym Socks5 Client](../clients/socks5/setup.md).
If users want to route their traffic through socks5 we advice to use maintained [Nym Socks5 Client](../clients/socks5/setup).
```
In case you want to run deprecated NymConnect, follow these steps:
@@ -27,7 +27,7 @@ Here are some examples of applications which will work behind Socks5 proxy (`nym
To download Electrum visit the [official webpage](https://electrum.org/#download). To connect to the Mixnet follow these steps:
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md))
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup))
2. Start your Electrum Bitcoin wallet
3. Go to: *Tools* -> *Network* -> *Proxy*
4. Set *Use proxy* to ✅, choose `SOCKS5` from the drop-down and add (copy-paste) the values from your NymConnect application
@@ -39,7 +39,7 @@ To download Electrum visit the [official webpage](https://electrum.org/#download
To download Monero wallet visit [getmonero.org](https://www.getmonero.org/downloads/). To connect to the Mixnet follow these steps:
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md))
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup))
2. Start your Monero wallet
3. Go to: *Settings* -> *Interface* -> *Socks5 proxy* -> Add values: IP address `127.0.0.1`, Port `1080` (the values copied from NymConnect)
5. Now your Monero wallet runs through the Mixnet and it will be connected only if your NymConnect or `nym-socks5-client` are connected.
@@ -49,7 +49,7 @@ To download Monero wallet visit [getmonero.org](https://www.getmonero.org/downlo
To download Element (chat client for Matrix) visit [element.io](https://element.io/download). To connect to the Mixnet follow these steps:
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md))
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup))
2. Start `element-desktop` with `--proxy-server` argument:
**Linux**
@@ -68,7 +68,7 @@ To make the start of Element over NymConnect simplier, you can add this command
### Telegram via NymConnect
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md))
1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup))
2. Start your Telegram chat application
3. Open the Telegram proxy settings.
- Linux: *Settings* -> *Advanced* -> *Connection type* -> *Use custom proxy*
documentation/docs/pages/developers/chain.md
+1 -1
View File
@@ -1,7 +1,7 @@
# Interacting with Nyx Chain and Smart Contracts
There are two options for interacting with the blockchain to send tokens or interact with deployed smart contracts:
* [`Nym-CLI`](../tools/nym-cli.md) tool
* [`Nym-CLI`](./tools/nym-cli) tool
* `nyxd` binary
## Nym-CLI tool (recommended in most cases)
documentation/docs/pages/developers/clients/socks5/setup.mdx
+1 -1
View File
@@ -28,7 +28,7 @@ Before you can use the client, you need to initalise a new instance of it, which
The `--id` in the example above is a local identifier so that you can name your clients and keep track of them on your local system; it is **never** transmitted over the network.
The `--use-reply-surbs` field denotes whether you wish to send [SURBs](../../network/concepts/anonymous-replies) along with your request. It defaults to `false`, we are explicitly setting it as `true`. It defaults to `false` for compatibility with versions of the pre-smoosh `nym-network-requester` binary which will soon be deprecated.
The `--use-reply-surbs` field denotes whether you wish to send [SURBs](/network/concepts/anonymous-replies) along with your request. It defaults to `false`, we are explicitly setting it as `true`. It defaults to `false` for compatibility with versions of the pre-smoosh `nym-network-requester` binary which will soon be deprecated.
The `--provider` field needs to be filled with the Nym address of an Exit Gateway that can make network requests on your behalf. You can select one from the [mixnet explorer](https://nym.com/explorer) by copying its `Client ID` and using this as the value of the `--provider` flag. Alternatively, you could use [Harbourmaster](https://harbourmaster.nymtech.net/).
documentation/docs/pages/developers/clients/socks5/usage.mdx
+1 -1
View File
@@ -44,7 +44,7 @@ When trying to connect your app, generally the proxy settings are found in `sett
Here is an example of setting the proxy connecting in Blockstream Green:
![Blockstream Green settings](/images/wallet-proxy-settings/blockstream-green.gif)
![Blockstream Green settings](/images/developers/blockstream-green.gif)
Most wallets and other applications will work basically the same way: find the network proxy settings, enter the proxy url (host: **localhost**, port: **1080**).
documentation/docs/pages/developers/clients/websocket/usage.md
+1 -1
View File
@@ -54,7 +54,7 @@ In some applications, e.g. where people are chatting with friends who they know,
**If that fits your security model, good. However, will probably be the case that you want to send anonymous replies using Single Use Reply Blocks (SURBs)**.
You can read more about SURBs [here](../../network/concepts/anonymous-replies) but in short they are ways for the receiver of this message to anonymously reply to you - the sender - **without them having to know your client address**.
You can read more about SURBs [here](/network/concepts/anonymous-replies) but in short they are ways for the receiver of this message to anonymously reply to you - the sender - **without them having to know your client address**.
Your client will send along a number of `replySurbs` to the recipient of the message. These are pre-addressed Sphinx packets that the recipient can write to the payload of (i.e. write response data to), but not view the final destination of. If the recipient is unable to fit the response data into the bucket of SURBs sent to it, it will use a SURB to request more SURBs be sent to it from your client.
documentation/docs/pages/developers/rust/mixnet/troubleshooting.mdx
+2 -2
View File
@@ -111,7 +111,7 @@ However, this is not true.
**This will only block until the message is put into client's internal queue**. Therefore in the above example, the client is being shut down before the message is _actually sent to the mixnet_; after being placed in the client's internal queue, there is still work to be done under the hood, such as route encrypting the message and placing it amongst the stream of cover traffic.
The simple solution? Make sure the program/client stays active, either by calling `sleep`, or listening out for new messages. As sending a one-shot message without listening out for a response is likely not what you'll be doing, then you will be then awaiting a response (see the [message helpers page](./message-helpers.md) for an example of this).
The simple solution? Make sure the program/client stays active, either by calling `sleep`, or listening out for new messages. As sending a one-shot message without listening out for a response is likely not what you'll be doing, then you will be then awaiting a response (see the [message helpers page](./message-helpers) for an example of this).
Furthermore, you should always **manually disconnect your client** with `client.disconnect().await` as seen in the code examples. This is important as your client is writing to a local DB and dealing with SURB storage.
@@ -122,7 +122,7 @@ You might however be receiving messages without data attached to them / empty pa
Whether the `data` of a SURB request being empty is a feature or a bug is to be decided - there is some discussion surrounding whether we can use SURB requests to send additional data to streamline the process of sending large replies across the mixnet.
You can find a few helper functions [here](./message-helpers.md) to help deal with this issue in the meantime.
You can find a few helper functions [here](./message-helpers) to help deal with this issue in the meantime.
> If you can think of a more succinct or different way of handling this do reach out - we're happy to hear other opinions
documentation/docs/pages/network/architecture/mixnet.mdx
+1 -1
View File
@@ -6,7 +6,7 @@ import { Callout } from 'nextra/components'
<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).
If you want to run a node, the setup and maintenance guides can be found in the [Operator Docs](/operators/introduction).
</Callout>
documentation/docs/pages/network/architecture/nyx.mdx
+3 -3
View File
@@ -6,7 +6,7 @@ import { Callout } from 'nextra/components'
If you want to interact with the chain please check the [interacting with Nyx](../../developers/chain) section of the developer docs.
If you want to run a Validator node, check the [Operator guides](../../../operators/nodes/validator-setup).
If you want to run a Validator node, check the [Operator guides](/operators/nodes/validator-setup).
</Callout>
@@ -14,7 +14,7 @@ Nyx is a Cosmos SDK blockchain. The blockchain plays a supporting but fundamenta
## Validators
<Callout type="info" emoji="ℹ️">
The validator setup and maintenance guide can be found in the [Operator Docs](../../../operators/nodes/validator-setup).
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.
@@ -23,7 +23,7 @@ Detailed info on Nyx Validators and token flow can be found in [Nym Reward Shari
## 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).
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:
documentation/docs/pages/network/cryptography/zk-nym.mdx
+1 -1
View File
@@ -2,7 +2,7 @@
The zk-nym scheme enables the creation and use of unlinkable, rerandomisable anonymous access credentials that are 'spent' with Gateways in order to anonymously prove that someone has paid for Mixnet access. This implementation incorporates elements of both the [Coconut Credential](https://arxiv.org/pdf/1802.07344) and [Offline Ecash](https://arxiv.org/pdf/2303.08221) schemes.
As outlined in the [overview](./zk-nym/zk-nym-overview.md) on the next page, zk-nyms allow for users to pay for Mixnet access in a manner that is **unlinkable to their payment account**; even with pseudonymous cryptocurrencies or fiat. This solves one of the fundamental privacy problems with the majority of VPNs and dVPNs in production today: the linkability of a user's session with their payment information, which can in the majority of cases be easily used to deanonymise them, either at the behest of an authority or by the service operators themselves.
As outlined in the [overview](./zk-nym/zk-nym-overview) on the next page, zk-nyms allow for users to pay for Mixnet access in a manner that is **unlinkable to their payment account**; even with pseudonymous cryptocurrencies or fiat. This solves one of the fundamental privacy problems with the majority of VPNs and dVPNs in production today: the linkability of a user's session with their payment information, which can in the majority of cases be easily used to deanonymise them, either at the behest of an authority or by the service operators themselves.
> The current zk-nym scheme is non-generic in that it is only used for gating Mixnet access. A generic scheme based on zk-nyms is being actively researched in order to facilitate more generic and customisable anonymous credentials for other applications and services.
documentation/docs/pages/network/cryptography/zk-nym/rerandomise.mdx
+1 -1
View File
@@ -5,7 +5,7 @@ import { Callout } from 'nextra/components'
Each ticket will not be valid for the entire amount of data that the ticketbook aggregated from the PSCs is; if the aggregated ticketbook is worth (e.g.) 10GB of Mixnet data, each ticket will be worth far less (e.g. 100MB). This amount will be globally uniform in order to avoid situations where differently sized tickets allow for patterns to emerge.
<Callout type="info" emoji="ℹ️">
The functionality included in the following code block examples were added to the [nym-cli tool](../tools/nym-cli.md) for illustrative purposes only: this is not necessarily how credentials will be accessed in the future.
The functionality included in the following code block examples were added to the [nym-cli tool](/developers/tools/nym-cli) for illustrative purposes only: this is not necessarily how credentials will be accessed in the future.
The numbers used in this high level overview are for illustration purposes only. The figures used in production will potentially vary. Note that individual ticket sizes will be uniform across the Network.
</Callout>
documentation/docs/pages/network/cryptography/zk-nym/unlinkability.mdx
+2 -2
View File
@@ -1,11 +1,11 @@
import { Callout } from 'nextra/components'
# Unlinkability
Each time a credential is requested by an ingress Gateway to prove that a client has purchased data to send through the Mixnet the Requester's device will produce a ticket. This is a rereandomised value that is able to be verified as being legitimate (in that it was created by a valid root ticketbook) but **not linked to any other tickets**, either previously generated or to be generated in the future. This feature also allows for a single ticketbook to allow access to be split across multiple ingress Gateways / connections and [incrementally spent](./rerandomise.md) over time.
Each time a credential is requested by an ingress Gateway to prove that a client has purchased data to send through the Mixnet the Requester's device will produce a ticket. This is a rereandomised value that is able to be verified as being legitimate (in that it was created by a valid root ticketbook) but **not linked to any other tickets**, either previously generated or to be generated in the future. This feature also allows for a single ticketbook to allow access to be split across multiple ingress Gateways / connections and [incrementally spent](./rerandomise) over time.
<Callout type="info" emoji="ℹ️">
The functionality included in the following code block examples were added to the [nym-cli tool](../tools/nym-cli.md) for illustrative purposes only: this is not necessarily how credentials will be accessed in the future.
The functionality included in the following code block examples were added to the [nym-cli tool](/developers/tools/nym-cli) for illustrative purposes only: this is not necessarily how credentials will be accessed in the future.
The numbers used in this high level overview are for illustration purposes only. The figures used in production will potentially vary. Note that individual zkNym sizes will be uniform across the Network.
documentation/docs/pages/network/cryptography/zk-nym/zk-nym-overview.mdx
+2 -2
View File
@@ -51,8 +51,8 @@ Once the Requester has received over the threshold number of PSCs they can assem
## Spend zk-nym to Access Mixnet
- Once the ticketbook has been aggregated from the PSCs returned from > threshold of Quorum members, smaller 'ticket' credentials can be generated from it, accounting for smaller chunks of bandwidth which can be 'spent' with ingress Gateways. This occurs entirely offline, on the device of the zk-nym Requester. See pages on the scheme's [unlinkability](unlinkability.md) and [rerandomisation and incremental spending](./rerandomise.md) features for further information on this.
- This ticket is later presented to the Quorum by the Gateway that collected it, which is used to calculate reward percentages given to Nym Network infrastructure operators by the Quorum, with payouts triggered by their multisig wallet. Both ingress Gateways and the Quorum use spent tickets when engaging in [double spending protection](./double-spend-prot.md).
- Once the ticketbook has been aggregated from the PSCs returned from > threshold of Quorum members, smaller 'ticket' credentials can be generated from it, accounting for smaller chunks of bandwidth which can be 'spent' with ingress Gateways. This occurs entirely offline, on the device of the zk-nym Requester. See pages on the scheme's [unlinkability](unlinkability) and [rerandomisation and incremental spending](./rerandomise) features for further information on this.
- This ticket is later presented to the Quorum by the Gateway that collected it, which is used to calculate reward percentages given to Nym Network infrastructure operators by the Quorum, with payouts triggered by their multisig wallet. Both ingress Gateways and the Quorum use spent tickets when engaging in [double spending protection](./double-spend-prot).
![](/images/network/use-zknym.png)
documentation/docs/pages/operators/archive/faq/smoosh-faq.mdx
+3 -3
View File
@@ -10,7 +10,7 @@ import { Callout } from 'nextra/components';
> -- Harry Halpin, Nym CEO
This page refer to the changes which are planned to take place over Q3 and Q4 2023. As this is a transition period in the beginning (Q3 2023) the [Mix Nodes FAQ page](mixnodes-faq.md) holds more answers to the current setup as project Smoosh refers to the eventual setup. As project Smoosh gets progressively implemented the answers on this page will become to be more relevant to the current state and eventually this FAQ page will be merged with the still relevant parts of the main Mix Nodes FAQ page.
This page refer to the changes which are planned to take place over Q3 and Q4 2023. As this is a transition period in the beginning (Q3 2023) the Mix Nodes FAQ page holds more answers to the current setup as project Smoosh refers to the eventual setup. As project Smoosh gets progressively implemented the answers on this page will become to be more relevant to the current state and eventually this FAQ page will be merged with the still relevant parts of the main Mix Nodes FAQ page.
If any questions are not answered or it's not clear for you in which stage project Smoosh is right now, please reach out in Node Operators [Matrix room](https://matrix.to/#/#operators:nymtech.chat).
@@ -22,7 +22,7 @@ Project Smoosh will have four steps, please follow the table below to track the
| **Step** | **Status** |
| :--- | :--- |
| **1.** Combine the `nym-gateway` and `nym-network-requester` into one binary | ✅ done |
| **2.** Create [Exit Gateway](../../legal/exit-gateway.md): Take the `nym-gateway` binary including `nym-network-requester` combined in \#1 and switch from [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) to a new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) | ✅ done |
| **2.** Create [Exit Gateway](/operators/community-counsel/exit-gateway): Take the `nym-gateway` binary including `nym-network-requester` combined in \#1 and switch from [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) to a new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) | ✅ done |
| **3.** Combine all the nodes in the Nym Mixnet into one binary, that is `nym-mixnode`, `nym-gateway` (entry and exit) and `nym-network-requester`. | ✅ done |
| **4.** Adjust reward scheme to incentivise and reward Exit Gateways as a part of `nym-node` binary, implementing [zkNym credentials](https://youtu.be/nLmdsZ1BsQg?t=1717). | 🛠️ in progress |
| **5.** Implement multiple node functionalities into one `nym-node` connected to one Nyx account. | 🛠️ in progress |
@@ -40,7 +40,7 @@ We are exploring two potential methods for implementing binary functionality in
### Where can I read more about the Exit Gateway setup?
We created an [entire page](../../legal/exit-gateway.md) about the technical and legal questions around Exit Gateway.
We created an [entire page](/operators/community-counsel/exit-gateway) about the technical and legal questions around Exit Gateway.
### What is the change from allow list to deny list?
documentation/docs/pages/operators/binaries/building-nym.mdx
+2 -2
View File
@@ -12,7 +12,7 @@ Nym has two main codebases:
- the [Nym platform](https://github.com/nymtech/nym), written in Rust. This contains all of our code _except_ for the validators.
- the [Nym validators](https://github.com/nymtech/nyxd), written in Go.
> This page details how to build the main Nym platform code. **If you want to build and run a validator, [go here](../nodes/validator-setup.md) instead.**
> This page details how to build the main Nym platform code. **If you want to build and run a validator, [go here](../nodes/validator-setup) instead.**
## Prerequisites
@@ -64,7 +64,7 @@ cargo build --release # build your binaries with **mainnet** configuration
Quite a bit of stuff gets built. The key working parts are:
* [Nym Node](../nodes/nym-node/nym-node.mdx): `nym-node`
* [Nym Node](../nodes/nym-node): `nym-node`
* [Validator](../nodes/validator-setup.mdx)
* [websocket client](../../developers/clients/websocket): `nym-client`
* [socks5 client](../../developers/clients/socks5): `nym-socks5-client`
documentation/docs/pages/operators/changelog.mdx
+26 -26
View File
@@ -72,7 +72,7 @@ cargo Profile: release
<Callout type="warning" emoji="⚠️">
**This release comes with breaking changes - please follow the [steps below](#oscypek-special-update) before upgrading!**
Secondly, the outcome of [NIP-7: Nym Exit Policy Update - Opening Ports for Steam, Discord & SSH](https://governator.nym.com/proposal/prop-281e9ec1-8e10-4e97-848c-311823e83f61), is added to the [Network tunnel manager (NTM)](https://github.com/nymtech/nym/blob/develop/scripts/nym-node-setup/network-tunnel-manager.sh) and operators are required to rerun the tool on their servers as [documented here](update-nym-exit-policy).
Secondly, the outcome of [NIP-7: Nym Exit Policy Update - Opening Ports for Steam, Discord & SSH](https://governator.nym.com/proposal/prop-281e9ec1-8e10-4e97-848c-311823e83f61), is added to the [Network tunnel manager (NTM)](https://github.com/nymtech/nym/blob/develop/scripts/nym-node-setup/network-tunnel-manager.sh) and operators are required to rerun the tool on their servers.
</ Callout>
#### `oscypek` special update
@@ -4080,7 +4080,7 @@ Here are the aims of these tests:
Meanwhile we started to research pricing of stronger servers with unlimited bandwidth and higher (and stable) port speed, to arrive to a better understanding of needed rewards and grants to bootstrap the network before NymVPN launch.
More info about testing and tools for performance monitoring can be found in [this chapter](testing/performance.md).
More info about testing and tools for performance monitoring can be found in [this chapter](performance-and-testing).
> We would like to call out to operators to join the efforts and reach out to us if they know of solid ISPs who offer reliable dedicated services for good price or may even be interested in partnership.
@@ -4641,11 +4641,11 @@ done
### Operators Guide, Tooling & Updates
- More explicit [setup for `nym-node`](nodes/setup.md#initialise--run) with a new [option explanation](nodes/setup.md#essential-parameters--variables), including syntax examples
- More explicit [setup for `nym-node`](nodes/nym-node/setup#initialise--run) with a new [option explanation](nodes/nym-node/setup#essential-parameters--variables), including syntax examples
- New [VPS networking configuration steps for Wireguard](nodes/configuration.md#routing-configuration)
- New [VPS networking configuration steps for Wireguard](nodes/nym-node/configuration#routing-configuration)
- Wireguard [builds from source](binaries/building-nym.md) together with `nym-node`, no need to specify with a feature flag anymore
- Wireguard [builds from source](binaries/building-nym) together with `nym-node`, no need to specify with a feature flag anymore
- Wireguard peers stay connected for longer time, re-connections are also faster
@@ -4684,12 +4684,12 @@ Every `nym-node` should be upgraded to the latest version! Operators can test us
**`nym-node`**
- Make sure to fill in basic description info, into the file located at `.nym/nym-nodes/<ID>/data/description.toml` (all nodes)
- Configure wireguard routing with new [`network_tunnel_manager.sh`](https://github.com/nymtech/nym/blob/develop/scripts/network_tunnel_manager.sh) following [these steps](nodes/configuration.md#routing-configuration) (Gateways only for the time being)
- Configure wireguard routing with new [`network_tunnel_manager.sh`](https://github.com/nymtech/nym/blob/develop/scripts/network_tunnel_manager.sh) following [these steps](nodes/nym-node/configuration#routing-configuration) (Gateways only for the time being)
- Enable Wireguard with `--wireguard-enabled true` flag included in your run command (Gateways only for the time being)
- Note: On some VPS this setup may not be enough to get the correct results as some ISPs have their own security groups setup below the individual VPS. In that case a ticket to ISP will have to be issued to open the needed settings. We are working on a template for such ticket.
- Setup [reverse proxy and WSS](nodes/proxy-configuration.md) on `nym-node` (Gateways only for the time being)
- Setup [reverse proxy and WSS](nodes/nym-node/configuration/proxy-configuration) on `nym-node` (Gateways only for the time being)
- Don't forget to restart your node - or (preferably using [systemd automation](nodes/nym-node/configuration.mdx#systemd)) reload daemon and restart the service
- Optional: Use [`nym-gateway-probe`](testing/gateway-probe.html) and [NymVPN CLI](https://nymtech.net/developers/nymvpn/cli.html) to test your own Gateway
- Optional: Use [`nym-gateway-probe`](performance-and-testing/gateway-probe) and [NymVPN CLI](https://nymtech.net/developers/nymvpn/cli.html) to test your own Gateway
- Optional: Run the script below to measure ping speed of your Gateway and share your results in [Nym Operators channel](https://matrix.to/#/#operators:nymtech.chat)
<AccordionTemplate name='The script to measure Gateway ping results'>
@@ -4878,7 +4878,7 @@ sudo -E ./nym-vpn-cli -c ../qa.env run --entry-gateway-id $entry_gateway --exit-
### Operators Guide updates
* [WireGuard tunnel configuration guide](nodes/configuration.md#routing-configuration) for `nym-node` (currently Gateways functionalities). For simplicity we made a detailed step by step guide to upgrade an existing `nym-node` to the latest version and configure your VPS routing for WireGuard. Open by clicking on the example block below.
* [WireGuard tunnel configuration guide](nodes/nym-node/configuration#routing-configuration) for `nym-node` (currently Gateways functionalities). For simplicity we made a detailed step by step guide to upgrade an existing `nym-node` to the latest version and configure your VPS routing for WireGuard. Open by clicking on the example block below.
<AccordionTemplate name="Upgrading with wireguard">
**Prerequisites**
@@ -4943,7 +4943,7 @@ chmod u+x network_tunnel_manager.sh
**Step 3: Update the Nym Node Service File**
1. Modify your [`nym-node` service file](nodes/configuration.md#systemd) to enable WireGuard. Open the file (usually located at `/etc/systemd/system/nym-node.service`) and update the `[Service]` section as follows:
1. Modify your [`nym-node` service file](nodes/nym-node/configuration#systemd) to enable WireGuard. Open the file (usually located at `/etc/systemd/system/nym-node.service`) and update the `[Service]` section as follows:
```ini
[Service]
@@ -4989,7 +4989,7 @@ Finally, run the following command to initiate our favorite routing test - run t
- **Note:** Wireguard will return only IPv4 joke, not IPv6. WG IPv6 is under development. Running IPR joke through the mixnet with `./network_tunnel_manager.sh joke_through_the_mixnet` should work with both IPv4 and IPv6!
</AccordionTemplate>
* [Change `--wireguard-enabled` flag to `true`](nodes/setup.md#-initialise--run): With a proper [routing configuration](nodes/configuration.md#routing-configuration) `nym-nodes` running as Gateways can now enable WG. See the example below:
* [Change `--wireguard-enabled` flag to `true`](nodes/nym-node/setup#initialise--run): With a proper [routing configuration](nodes/nym-node/configuration#routing-configuration) `nym-nodes` running as Gateways can now enable WG. See the example below:
<AccordionTemplate name="Run node with wireguard enabled">
For Exit Gateway:
@@ -5350,8 +5350,8 @@ bind_address = '0.0.0.0:9000'
### Operators Guide updates
- [Node description guide](nodes/configuration.md#node-description): Steps to add self-description to `nym-node` and query this information from any node.
- [Web Secure Socket (WSS) guide and reverse proxy update](nodes/proxy-configuration.md), PR [here](https://github.com/nymtech/nym/pull/4694): A guide to setup `nym-node` in a secure fashion, using WSS via Nginx and Certbot. Landing page (reversed proxy) is updated and simplified.
- [Node description guide](nodes/nym-node/configuration#node-description): Steps to add self-description to `nym-node` and query this information from any node.
- [Web Secure Socket (WSS) guide and reverse proxy update](nodes/nym-node/configuration/proxy-configuration), PR [here](https://github.com/nymtech/nym/pull/4694): A guide to setup `nym-node` in a secure fashion, using WSS via Nginx and Certbot. Landing page (reversed proxy) is updated and simplified.
---
@@ -5551,16 +5551,16 @@ warning: /home/alice/src/nym/nym/common/dkg/Cargo.toml: `default-features` is ig
### Operators Guide updates
- [New Release Cycle](release-cycle.md) introduced: a transparent release flow, including:
- [New Release Cycle](release-cycle) introduced: a transparent release flow, including:
- New environments
- Stable testnet
- [Testnet token faucet](https://nymtech.net/operators/sandbox.html#sandbox-token-faucet)
- Flow [chart](release-cycle.md#release-flow)
- [Sandbox testnet](sandbox.md) guide: teaching Nym node operators how to run their nodes in Nym Sandbox testnet environment.
- [Terms & Conditions flag](nodes/setup.md#terms--conditions)
- Flow [chart](release-cycle#release-flow)
- [Sandbox testnet](sandbox) guide: teaching Nym node operators how to run their nodes in Nym Sandbox testnet environment.
- [Terms & Conditions flag](nodes/nym-node/setup#terms--conditions)
- Node API Check CLI
- [Pruning VPS `syslog` scripts](troubleshooting/vps-isp.md#pruning-logs)
- [Black-xit: Exiting the blacklist](troubleshooting/nodes.md#my-gateway-is-blacklisted)
- [Pruning VPS `syslog` scripts](troubleshooting/vps-isp#pruning-logs)
- [Black-xit: Exiting the blacklist](troubleshooting/nodes#my-gateway-is-blacklisted)
---
@@ -5712,9 +5712,9 @@ called Result::unwrap() on an Err value: ClientCoreError(ValidatorClientError(Ny
### Operators Guide updates
- [`nym-gateway-probe`](testing/gateway-probe.md): A CLI tool to check in-real-time networking status of any Gateway locally.
- [Where to host your `nym-node`?](legal/isp-list.md): A list of Internet Service Providers (ISPs) by Nym Operators community. We invite all operators to add their experiences with different ISPs to strengthen the community knowledge and Nym mixnet performance.
- Make sure you run `nym-node` with `--wireguard-enabled false` and add a location description to your `config.toml`, both documented in [`nym-node` setup manual](nodes/setup.md#mode-exit-gateway).
- [`nym-gateway-probe`](performance-and-testing/gateway-probe): A CLI tool to check in-real-time networking status of any Gateway locally.
- [Where to host your `nym-node`?](community-counsel/isp-list): A list of Internet Service Providers (ISPs) by Nym Operators community. We invite all operators to add their experiences with different ISPs to strengthen the community knowledge and Nym mixnet performance.
- Make sure you run `nym-node` with `--wireguard-enabled false` and add a location description to your `config.toml`, both documented in [`nym-node` setup manual](nodes/nym-node/setup#mode-exit-gateway).
---
@@ -5728,8 +5728,8 @@ called Result::unwrap() on an Err value: ClientCoreError(ValidatorClientError(Ny
- Nym wallet changes:
- Adding `nym-node` command to bonding screens
- Fixed the delegation issues with fixing RPC
- [Network configuration](nodes/configuration.md#connectivity-test-and-configuration) section updates, in particular for `--mode mixnode` operators
- [VPS IPv6 troubleshooting](troubleshooting/vps-isp.md#ipv6-troubleshooting) updates
- [Network configuration](nodes/nym-node/configuration#connectivity-test-and-configuration) section updates, in particular for `--mode mixnode` operators
- [VPS IPv6 troubleshooting](troubleshooting/vps-isp#ipv6-troubleshooting) updates
---
@@ -5740,8 +5740,8 @@ called Result::unwrap() on an Err value: ClientCoreError(ValidatorClientError(Ny
- [`nym-node`](nodes/nym-node.mdx) initial release
- New tool for monitoring Gateways performance [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net)
- New versioning `1.1.0+nymnode` mainly for internal migration testing, not essential for operational use. We aim to correct this in a future release to ensure mixnodes feature correctly in the main API
- New [VPS specs & configuration](nodes/vps-setup.md) page
- New [configuration page](nodes/configuration.md) with [connectivity setup guide](nodes/configuration.md#connectivity-test-and-configuration) - a new requirement for `exit-gateway`
- New [VPS specs & configuration](nodes/preliminary-steps/vps-setup) page
- New [configuration page](nodes/nym-node/configuration) with [connectivity setup guide](nodes/nym-node/configuration#connectivity-test-and-configuration) - a new requirement for `exit-gateway`
- API endpoints redirection: Nym-mixnode and nym-gateway endpoints will eventually be deprecated; due to this, their endpoints will be redirected to new routes once the `nym-node` has been migrated and is running
**API endpoints redirection**
documentation/docs/pages/operators/community-counsel.mdx
+2 -2
View File
@@ -10,8 +10,8 @@ import { MyTab } from 'components/generic-tabs.tsx';
**The entire content of this section is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/).**
</Callout>
Running an Exit Gateway is a commitment and as such is exposed to various challenges. Besides different legal regulations typical difficulties may be dealing with VPS or ISP providers. Our strength lies in decentralised community of squads and individuals supporting each other. Sharing examples of [landing pages](landing-pages.md), templates for communication and FAQs is a great way to empower other operators sharing the mission of liberating internet. Below is a simple way how to create a pull request directly to Nym Operator Guide docs.
Running an Exit Gateway is a commitment and as such is exposed to various challenges. Besides different legal regulations typical difficulties may be dealing with VPS or ISP providers. Our strength lies in decentralised community of squads and individuals supporting each other. Sharing examples of [landing pages](community-counsel/landing-pages), templates for communication and FAQs is a great way to empower other operators sharing the mission of liberating internet. Below is a simple way how to create a pull request directly to Nym Operator Guide docs.
## How to add content
Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](add-content.md).
Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](community-counsel/add-content).
documentation/docs/pages/operators/community-counsel/isp-list.mdx
+1 -1
View File
@@ -10,7 +10,7 @@ This ISP list is fully managed by Nym operator community and it serves as a spac
Please share any experiences running a node like policies, complains, legal issues and solutions, discrepancy between offers and reality (bandwidth, IP range, locations) or anything regarding pricing or customer support.
If you came across any legal findings, please share them in our [list of jurisdictions](jurisdictions.md).
If you came across any legal findings, please share them in our [list of jurisdictions](jurisdictions).
While we trust that Nym node operators are honest, we would like to ask everyone to do your own research.
documentation/docs/pages/operators/community-counsel/legal.mdx
+1 -1
View File
@@ -24,7 +24,7 @@ Write a message to your provider telling them about your intention to run a `nym
</AccordionTemplate>
#### Join Operators Legal Forum
This [Matrix channel]((https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org&via=matrix.su4ka.icu)) is the best place to ask questions and share your experience with others. You can share screen prints of abuse reports and ask for support.
This [Matrix channel](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org&via=matrix.su4ka.icu) is the best place to ask questions and share your experience with others. You can share screen prints of abuse reports and ask for support.
#### Join Operators Legal Clinic
Do you have any questions directed for lawyers? Come and chat with Nym COO Alexis Roussel, every Wednesday 14:30 UTC for 60min in our [Operator Legal Forum channel on Matrix](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org&via=matrix.su4ka.icu).
documentation/docs/pages/operators/introduction.mdx
+1 -1
View File
@@ -35,7 +35,7 @@ If you want to explore kickstart options and examples, learn how to integrate wi
**Node setup and usage guides:**
* [Nym Node](nodes/nym-node/nym-node.mdx)
* [Nym Node](nodes/nym-node)
* [Nymvisor](nodes/maintenance/nymvisor-upgrade.mdx)
* [Validators](nodes/validator-setup.mdx)
* [Nym API Setup](nodes/validator-setup/nym-api.mdx)
documentation/docs/pages/operators/misc/toc.md
+1 -1
View File
@@ -6,4 +6,4 @@ There has been a long ongoing discussion whether and how to apply Terms and Cond
Accepting T&Cs is done via an explicit flag `--accept-operator-terms-and-conditions` added to `nym-node run` command.
More information on how to setup your node or check whether any node has T&C accepted can be found in [`nym-node` setup guide](nodes/setup.md#terms--conditions).
More information on how to setup your node or check whether any node has T&C accepted can be found in [`nym-node` setup guide](/operators/nodes/nym-node/setup#terms--conditions).
documentation/docs/pages/operators/nodes/maintenance.mdx
+1 -1
View File
@@ -448,7 +448,7 @@ scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:/etc/systemd/system/nym-node.
Local node identifier, denoted as `<ID>` accross the documentation (not the identity key) is a name chosen by operators which defines where the nodes configuration data will be stored, where the ID determines the path to `~/.nym/nym-nodes/<ID>/`. This ID is never shared on the network.
When running a [`nym-node`](nym-node/nym-node.mdx), a local identifier specified with a flag `--ID <ID>` is no longer necessary. Nodes without a specified ID will be assigned a default ID `default-nym-node`. This streamlines node management, particularly for operators handling multiple nodes via ansible and other automation scripts, as all data is stored at `~/.nym/nym-nodes/default-nym-node`.
When running a [`nym-node`](nym-node), a local identifier specified with a flag `--ID <ID>` is no longer necessary. Nodes without a specified ID will be assigned a default ID `default-nym-node`. This streamlines node management, particularly for operators handling multiple nodes via ansible and other automation scripts, as all data is stored at `~/.nym/nym-nodes/default-nym-node`.
If you already operate a `nym-node` and wish to change the local ID to `default-nym-node` or anything else, follow the steps below to do so.
documentation/docs/pages/operators/nodes/maintenance/manual-upgrade.mdx
+1 -1
View File
@@ -8,7 +8,7 @@ import CliUpdate from 'components/operators/snippets/update-cli-steps.mdx'
# Manual Node Upgrade
This page explains how to upgrade [`nym-node`](#nym-node-upgrade) or [`validator`](#validator-upgrade) to the latest version in a few steps. If you prefer to automate the process, try to setup your flow with [Nymvisor](nymvisor-upgrade.md).
This page explains how to upgrade [`nym-node`](#nym-node-upgrade) or [`validator`](#validator-upgrade) to the latest version in a few steps. If you prefer to automate the process, try to setup your flow with [Nymvisor](nymvisor-upgrade).
<VarInfo />
documentation/docs/pages/operators/nodes/maintenance/nymvisor-upgrade/nymvisor-configuration.mdx
+1 -1
View File
@@ -10,7 +10,7 @@ import { Steps } from 'nextra/components';
## Nymvisor Automation with `systemd`
This section contains guide how to setup `systemd` automation for Nymvisor. If you are looking for other chapters, visit these pages: [VPS setup](../../../preliminrary-steps/vps-setup.mdx), advanced terminal tools like [tmux and nohup setup](../../nym-node/configuration.mdx#vps-setup-and-automation), [`nym-node` automation](../../nym-node/configuration.mdx#systemd) or [`validator` automation](../../validator-setup/nyx-configuration#automation).
This section contains guide how to setup `systemd` automation for Nymvisor. If you are looking for other chapters, visit these pages: [VPS setup](../../preliminary-steps/vps-setup), advanced terminal tools like [tmux and nohup setup](../../nym-node/configuration.mdx#vps-setup-and-automation), [`nym-node` automation](../../nym-node/configuration.mdx#systemd) or [`validator` automation](../../validator-setup/nyx-configuration#automation).
<Callout type="info" emoji="ℹ️">
Since you're planning to run your node via a Nymvisor instance, as well as creating a Nymvisor `.service` file, you will also want to **stop any previous node automation process you already have running**.
documentation/docs/pages/operators/nodes/nym-node/setup.mdx
+2 -2
View File
@@ -133,7 +133,7 @@ curl -X 'GET' \
#### Essential Parameters & Variables
Running a `nym-node` in a `mixnode` mode requires less configuration than a full `exit-gateway` setup, we recommend operators to still follow through with all documented [configuration](configuration.md). Before you scroll down to syntax examples for the mode of your choice please familiarise yourself with the essential [paramters and variables](../../variables.mdx) convention we use in the guide.
Running a `nym-node` in a `mixnode` mode requires less configuration than a full `exit-gateway` setup, we recommend operators to still follow through with all documented [configuration](configuration). Before you scroll down to syntax examples for the mode of your choice please familiarise yourself with the essential [paramters and variables](../../variables) convention we use in the guide.
<Callout>
To prevent over-flooding of our documentation we cannot provide with every single command syntax as there is a large combination of possibilities. Please read the [variables and parameters page](../../variables.mdx), use the explanation in `--help` option and common sence.
@@ -172,7 +172,7 @@ From `2024.14-crunch` release (`nym-node v1.2.0`) onward, `nym-node` binary does
Furthermore, giving that legacy nodes had been deprecated for several months, Nym cannot promise 100% serialisation for operators migrating from long outdated versions. If you are about to migrate, start with [`nym-node v1.1.0`](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.3-eclipse) and keep upgrading version by version all the way to the latest one.
</Callout>
Operators who are about to migrate their nodes need to configure their [VPS](vps-setup.md) and setup `nym-node` which can be downloaded as a [pre-built binary](../binaries/pre-built-binaries.md) or compiled from [source](../binaries/building-nym.md).
Operators who are about to migrate their nodes need to configure their [VPS](../preliminary-steps/vps-setup) and setup `nym-node` which can be downloaded as a [pre-built binary](../../binaries/pre-built-binaries) or compiled from [source](../../binaries/building-nym).
To migrate a `nym-mixnode` or a `nym-gateway` to `nym-node` use, the `migrate` command with `--config-file` flag pointing to the original `config.toml` file, with a conditional argument defining which type of node this configuration belongs to. The exact steps are below.
documentation/docs/pages/operators/nodes/preliminary-steps.mdx
+1 -1
View File
@@ -1,6 +1,6 @@
# Preliminary Steps
> The `nym-node` binary was built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first.
> The `nym-node` binary was built in the [building nym](../binaries/building-nym) section. If you haven't yet built Nym and want to run the code, go there first.
There are a couple of steps that need completing before starting to set up your `nym-node`:
documentation/docs/pages/operators/sandbox.mdx
+1 -1
View File
@@ -56,7 +56,7 @@ curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/env
</Steps>
<Callout>
1. If you [built Nym from source](../binaries/building-nym.md), you already have `sandbox.env` as a part of the monorepo (`nym/envs/sandbox.env`). Giving that you are likely to run `nym-node` from `nym/target/release`, the flag will look like this `--config-env-file ../../envs/sandbox.env`
1. If you [built Nym from source](binaries/building-nym), you already have `sandbox.env` as a part of the monorepo (`nym/envs/sandbox.env`). Giving that you are likely to run `nym-node` from `nym/target/release`, the flag will look like this `--config-env-file ../../envs/sandbox.env`
2. You can export the path to `sandbox.env` to your environmental variables:
```sh
documentation/docs/pages/operators/tokenomics.mdx
+1 -1
View File
@@ -21,7 +21,7 @@ import { AccordionTemplate } from 'components/accordion-template.tsx';
<TimeNow />
Nym Network is composed of two main elements, the Mixnet represented by [Nym Nodes](nodes/nym-node/nym-node.mdx) routing and mixing the data packets, and Nyx blockchain distributted accros [validator set](tokenomics/validator-rewards.mdx), using smart contracts (based on [cosmwasm](https://cosmwasm.com/)) to monitor and reward Nym Nodes by querying API endpoints and distributing NYM token to operators according to work done by their nodes. All Nym nodes and validators are run by decentralised community of operators.
Nym Network is composed of two main elements, the Mixnet represented by [Nym Nodes](nodes/nym-node) routing and mixing the data packets, and Nyx blockchain distributted accros [validator set](tokenomics/validator-rewards.mdx), using smart contracts (based on [cosmwasm](https://cosmwasm.com/)) to monitor and reward Nym Nodes by querying API endpoints and distributing NYM token to operators according to work done by their nodes. All Nym nodes and validators are run by decentralised community of operators.
* Nym tokenomics are based on the research paper [*Reward Sharing for Mixnets*](https://nym.com/nym-cryptoecon-paper.pdf)
* For a more comprehensive overview, token live data and graphs, visit a community managed dashboard [*explorer.nym.spectredao.net/token*](https://explorer.nym.spectredao.net/dashboard)
documentation/docs/pages/operators/tokenomics/mixnet-rewards.mdx
+3 -3
View File
@@ -61,8 +61,8 @@ Nodes bonded with vesting tokens are [not allowed to join rewarded set](https://
This is a quick summary, to understand the logic behind fundamentals like [rewarded set selection](#rewarded-set-selection), [node performance](#mixnet-node-performance-calculation), [stake saturation](#stake-saturation), or [rewards calculation](#rewards-calculation), please read the chapters below.
* **The current reward system is called [*Naive rewarding*](#naive-rewarding) - an intermediate step - where the operators of `nym-node` get rewarded from [Mixmining pool](https://validator.nymtech.net/api/v1/epoch/reward_params), which emits <span style={{display: 'inline-block'}}><EpochRewardBudget /></span> NYM per hour**
* **Only nodes selected to [rewarded set](../tokenomics.mdx#active-set) of Mixnet receive rewards**
* The [rewarded set](../tokenomics.mdx#active-set) of the Mixnet is currently **240 nodes in total and it's selected for each new epoch (60 min)**, from all the nodes registered (bonded) in the network
* **Only nodes selected to [rewarded set](../tokenomics#rewarded-set) of Mixnet receive rewards**
* The [rewarded set](../tokenomics#rewarded-set) of the Mixnet is currently **240 nodes in total and it's selected for each new epoch (60 min)**, from all the nodes registered (bonded) in the network
* Each node gets the same proportion of work factor because of the *naive* distribution of work
* In the [final model](#roadmap), nodes will get rewarded based on their layer position and the work they do (collected user tickets), where the work factor distribution per layer will be according to a [decision made by the operators](https://forum.nymtech.net/t/poll-what-should-be-the-split-of-mixmining-rewards-among-the-layers-of-the-nym-mixnet/407) as [listed below](#nym-network-rewarded-set-distribution)
* If a node is selected to the rewarded set, it will be rewarded in the end of the epoch, based on this reward calculation formula:
@@ -146,7 +146,7 @@ In reality there is a an additional value called **&alpha;**, giving a premium t
| **Network layer** | **1** | **2** |
| :-- | :---: | :---: |
| Node functionality in layer | Entry Gateway | Exit Gateway |
| Naive rewarding: Nodes in [active set](tokenomics.mdx#active-set) | only Mixnet mode | only Mixnet mode |
| Naive rewarding: Nodes in [active set](../tokenomics#rewarded-set) | only Mixnet mode | only Mixnet mode |
| Naive rewarding\*: Maximum work fraction per node | only Mixnet mode | only Mixnet mode |
| Final model\*\*: Layer multiplier | 0.33 | 0.67 |
documentation/docs/pages/operators/troubleshooting/nodes.mdx
+3 -3
View File
@@ -31,7 +31,7 @@ We have scripts which automatically include the Git commit hash and Git tag in t
What to do?
* Follow the instructions in the Binaries section to [build nym from source](../binaries/building-nym.mdx) or [download precompiled binaries](../binaries/pre-build-binaries.mdx)
* Follow the instructions in the Binaries section to [build nym from source](../binaries/building-nym.mdx) or [download precompiled binaries](../binaries/pre-built-binaries.mdx)
* To upgrade, follow the [upgrade instructions](../nodes/maintenance/manual-upgrade.mdx)
## General Node Config
@@ -343,7 +343,7 @@ In case your Gateway appeared on the [blacklist](https://validator.nymtech.net/a
**What to do**
Begin with a sanity check by opening [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net) and check your node there. To see IPv4 and IPv6 routing in real time (harbourmaster can have a cache up to 90 min), run [Gateway Probe CLI](../testing/gateway-probe.mdx).
Begin with a sanity check by opening [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net) and check your node there. To see IPv4 and IPv6 routing in real time (harbourmaster can have a cache up to 90 min), run [Gateway Probe CLI](../performance-and-testing/gateway-probe.mdx).
Then follow these steps:
@@ -412,7 +412,7 @@ https://<HOSTNAME>/api/v1/swagger/#/
###### 2. Configure IPv4 and IPv6 tables and rules
In case you haven't lately, follow the steps in the node [configuration](../nodes/nym-node/configuration.mdx) chapter [connectivity test and configurastion](../nodes/nym-nodes/configuration.mdx#connectivity-test-and-configuration).
In case you haven't lately, follow the steps in the node [configuration](../nodes/nym-node/configuration.mdx) chapter [connectivity test and configuration](../nodes/nym-node/configuration.mdx#connectivity-test-and-configuration).
###### 3. Test connectivity
lychee.toml
+18
View File
@@ -0,0 +1,18 @@
# This is a pre-commit linkchecker for the docs site
#
# Lychee is explicit with links, whereas NextJS resolves links w/out extensions to md(x)
fallback_extensions = ["mdx", "md"]
# Root directory for resolving absolute paths (pages for content)
# Note: root_dir must be passed via CLI with absolute path in CI
# root_dir = "documentation/docs/pages/"
# Remap /images to public/images for NextJS static assets
# Lychee resolves /images to pages/images, but Next.js serves from public/images
remap = ["pages/images public/images"]
# Exclude component snippets (TODO: verify which are still in use)
exclude_path = ["components/"]
# Only check local file links (skip external URLs for pre-commit speed)
scheme = ["file"]