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

[DOCs/operators]: Release notes, new specs, legal pages (#5419)

Browse Source 
* add legal support notes

* write dev release notes

* create new legal page and add templates

* remove node_api_check to backup

* templates page

* update specs

* update backup and restore node

* PR ready for review

* address review comment

* last tweaks - PR finished

* last tweaks - PR finished
This commit is contained in:
import this
2025-02-05 15:19:56 +00:00
committed by GitHub
parent 21e3c1538d
commit 606e29ebb0
17 changed files with 901 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/backup-pages/node-api-check.mdx
+166
View File
@@ -0,0 +1,166 @@
import { Tabs } from 'nextra/components';
import { Callout } from 'nextra/components';
import { VarInfo } from 'components/variable-info.tsx';
import { Steps } from 'nextra/components';
import { MyTab } from 'components/generic-tabs.tsx';
import NodeApiCheckHelp from 'components/outputs/command-outputs/node-api-check-help.md';
import NodeApiCheckQueryHelp from 'components/outputs/command-outputs/node-api-check-query-help.md'
# Node API Check
<Callout type="warning" emoji="⚠️">
CLI tool `node_api_check.py`, helping operators to collect all API values about their nodes locally, is not up to date with the API changes introduced with `v2024.13-magura` release version. Please treat it as unstable before we fix it.
</Callout>
<VarInfo />
Operating a `nym-node` is not a *"set and forget"* endeavor, it takes some work. To diagnose node network performance through querying APIs, is a good knowledge to have. These are the main places to look for API endpoints regarding `nym-node`:
- [`openapi.json`](https://validator.nymtech.net/api/v1/openapi.json): a list of all endpoints
- [Swagger UI page](https://validator.nymtech.net/api/swagger/index.html)
Besides that, node operators can check out their node performance, connectivity and much more on [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net/).
### Basic API usage
For information about available endpoints and their status, you can refer to:
```sh
# for http
http://<PUBLIC_IP>:8080/api/v1/swagger/#/
# or
http://<PUBLIC_IP>/api/v1/swagger/#/
# for reversed proxy/WSS
https://<HOSTNAME>/api/v1/swagger/#/
```
For example to determine which mode your node is running, you can check `:8080/api/v1/roles` endpoint:
```sh
# for http
http://<PUBLIC_IP>:8080/api/v1/roles
# or
http://<PUBLIC_IP>/api/v1/roles
# for reversed proxy/WSS
https://<HOSTNAME>/api/v1/roles
```
## `node_api_check.py`
To make this a bit easier, we made a CLI tool querying all available API endpoints based on node `Identity Key` (further denoted as `<ID_KEY>`) called `node_api_check.py`. To diagnose your node performance, whether by yourself or by sharing an output in our [operator channel](https://matrix.to/#/#operators:nymtech.chat), this tool provides you with a quick overview of live data. We recommend to run this checker alongside [`nym_gateway_probe`](gateway-probe.md) to triage both performance and an actual routing.
Besides querying any bonded node APIs, `nym_api_check.py` has a function counting all existing nodes in provided version.
### Setup
#### Pre-requsities
<Steps>
###### 1. Install and configure Python3
- Start with installing Python3:
```sh
sudo apt install python3
```
- Make sure Python3 is your default Python version:
```sh
update-alternatives --install /usr/bin/python python /usr/bin/python3 1
```
- Verify:
```sh
python --version
# should return higher than 3
```
- Install Python modules `tabulate`, `pandas` and `argparse` either using [`pip`](https://python.land/virtual-environments/installing-packages-with-pip) or if you installed Python3 system-wide you can install modules directly:
<div>
<Tabs items={[
<strong>Using <code>pip</code></strong>,
<strong>System-wide Python installation</strong>,
]} defaultIndex="1">
<MyTab>
```sh
pip install tabulate pandas argparse
```
</MyTab>
<MyTab>
```sh
sudo apt install python3-tabulate python3-pandas python3-argparse -y
```
</MyTab>
</Tabs>
</div>
###### 2. Install `node_api_check.py` and make executable
To run the program you neet to have [`node_api_check.py`](https://github.com/nymtech/nym/tree/develop/scripts/node_api_check.py) and [`api_endpoints.json`](https://github.com/nymtech/nym/tree/develop/scripts/api_endpoints.json).
- If you [compiled from source](../../binaries/building-nym.mdx), you already have both of these files. Note that the latest version of this program may be on `develop` branch.
- If you prefer to download them individually, do it by opening terminal in your desired location and running:
```sh
wget https://raw.githubusercontent.com/nymtech/nym/tree/develop/node_api_check.py
wget https://raw.githubusercontent.com/nymtech/nym/tree/develop/api_endpoints.json
```
- Make executable:
```sh
chmod u+x node_api_check.py
```
</Steps>
Now you are ready to check your node.
### Usage & Commands
- Run the program with `--help` flag to see the available commands:
```sh
./node_api_check.py --help
```
- Command Output:
<NodeApiCheckHelp />
#### `query_stats`
When you want to see all the options connected to any command, add a `--help` flag after the command of your choice. Command `query_stats` is the most useful one of this program.
```sh
./node_api_check query_stats --help
```
- Command output:
<NodeApiCheckQueryHelp/ >
The most common usage may be `./node_api_check.py query_stats <ID_KEY>` where `<ID_KEY>` is required, substitute it with node Identity Key.
**Optional arguments**
| Flag | Shortcut | Description |
| :--- | :--- | :--- |
| `--markdown` | `-m` | returns output in markdown format |
| `--no_routing_history` | None | returns output without routing history which can be lengthy |
| `--no_verloc_metrics` | None | returns output without verloc measurement which can be lengthy |
| `--output` | `-o` | exports output to a file, possible to add a target path |
#### `version_count`
<Callout>
To see a quick overview of `nym-node` version distribution in numbers and graph, visit [Nym Harbourmaster](https://harbourmaster.nymtech.net).
</Callout>
Another command is `version_count` where at least one `nym-node` version is required. In case of multiple version count, separate the versions with space. We recommend to run this command with `--markdown` flag for a nicer output. This is an example where we want to look up how many registered nodes are on versions `1.1.0`, `1.1.1`, `1.1.2` and `1.1.3`:
```sh
./node_api_check version_count 1.1.0 1.1.1 1.1.2 1.1.3 --markdown
```
documentation/docs/components/operators/snippets/nym-node-specs.mdx
+27 -11
View File
@@ -11,22 +11,38 @@ Tor community created a very helpful table called [*Good Bad ISPs*](https://comm
<div>
<Tabs items={[
<code>nym-node</code>,
<><code>nym-node</code> - dedicated server</>,
<><code>nym-node</code> - VPS</>,
<code>validator</code>,
]} defaultIndex="0">
<MyTab>
#### `nym-node`
Before we conclude the testing with exact results, these are the rough specs:
#### `nym-node` - dedicated server
If you are about to start a new Nym Node, look for a server with this specification:
| **Hardware** | **Minimum Specification** |
| :--- | ---: |
| CPU Cores | 4 |
| Memory | 8 GB RAM |
| Storage | 80 GB |
| Connectivity | IPv4, IPv6, TCP/IP, UDP |
| Bandwidth | > 1Tb |
| Port speed | 1Gbps |
| **Hardware** | **Minimum Specification** |
| :--- | ---: |
| Type of server | Dedicated or bare metal |
| CPU Cores | 4 |
| Memory | 8-16 GB RAM |
| Storage | 50 GB (preferably 80 GB) |
| Connectivity | IPv4, IPv6, TCP/IP, UDP |
| Bandwidth | Unmetered if possible, or \> 20Tb |
| Port speed | 1Gbps |
</MyTab>
<MyTab>
#### `nym-node` - VPS
If you are about to start a new Nym Node, look for a server with this specification:
| **Hardware** | **Minimum Specification** |
| :--- | ---: |
| Type of server | VPS |
| CPU Cores | 8 |
| Memory | 16-32 GB RAM |
| Storage | 50 GB (preferably 80 GB) |
| Connectivity | IPv4, IPv6, TCP/IP, UDP |
| Bandwidth | Unmetered if possible, or \> 40Tb |
| Port speed | 10Gbps |
</MyTab>
<MyTab>
#### Nyx validator
documentation/docs/components/operators/templates/dmca_response.md
+37
View File
@@ -0,0 +1,37 @@
```
Thank you for forwarding me the notice you received from <COPYRIGHT_CLAIMANT> regarding <CONTENT>. I would like to assure you that I am not hosting the claimed infringing materials, and furthermore, the Digital Millennium Copyright Act's ("DMCA") safe harbors likely protect you from liability arising from this complaint. The notice is likely based upon misunderstandings about the law and about some of the software I run.
As you know, the DMCA creates four "safe harbors" for service providers to protect them from copyright liability for the acts of their users, when the ISPs fulfill certain requirements. (17 U.S.C. 512)
The DMCA's requirements vary depending on the ISP's role. You may be familiar with the "notice and takedown" provisions of section 512(c) of the DMCA; however, those do not apply when an ISP merely acts as a conduit.
Instead, the "conduit" safe harbor of section 512(a) of the DMCA has different and less burdensome eligibility requirements, as the D.C. Circuit Court of Appeals held in RIAA v. Verizon (see https://scholar.google.com/scholar_case?case=15815830240179540527) and the Eighth Circuit Court of Appeals confirmed in RIAA v. Charter (see https://scholar.google.com/scholar_case?case=11547531128234336420).
Under DMCA 512(a), service providers like you are typically protected from damages for copyright infringement claims if you also maintain "a policy that provides for termination in appropriate circumstances of subscribers and account holders of the service provider's system or network who are repeat infringers."
If you have and implement such a policy, and you otherwise qualify for the safe harbor, you should be free from fear of copyright damages.
The copyright notice you received was likely triggered by a program I run called Nym. Nym is a network software that helps users to enhance their privacy, security, and safety online. It does not host any content. Rather, it is part of a network of nodes on the Internet that simply pass packets among themselves before sending them to their destinations, just as any Internet intermediary does.
The difference is that Nym tunnels the connections such that no hop can learn both the source and destination of the packets, giving users protection from nefarious snooping on network traffic. The result is that, unlike most other Internet traffic, the final IP address that the recipient receives is not the IP address of the sender. Nym protects users against hazards such as harassment, spam, and identity theft.
Nym was conceived during the EU-funded project 'Panoramix' R&D project (Horizon 2020 programme) with the goal of protecting communication privacy by building a comprehensive mixnet infrastructure. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Grant Agreement No 653497, "Privacy and Accountability in Networks via Optimized Randomized Mix-nets (Panoramix)”. (For more on Nym, see https://www.nym.com/, For more on Panoramix, see https://panoramix.me/ ). Nym has continued this work by building a decentralized routing, authentication and payment protocol. Nym will enable developers to build their own sustainable privacy-enhanced services on top of its platform.
I hope, as an organization committed to protecting the privacy of its customers, you'll agree that this is a valuable technology.
While the Nym node that I run may appear to be the source of material that is alleged to be copyright-infringing, I do not host that material.
I do not select the material transmitted through the Nym node that I run, and I have no practical means of either identifying the source of such material or preventing its transmission. I do nothing to encourage or promote the use of the Nym network for copyright infringement.
For these reasons, I am not an infringer of copyright in any materials that are transmitted through the Nym node that I run, either directly or under a theory of contributory or vicarious liability.
Therefore, you should continue to be protected under the DMCA 512(a) safe harbor without taking any further action.
Thank you for working with me on this matter. As a loyal subscriber, I appreciate your notifying me of this issue and hope that the protections of DMCA 512 put any concerns you may have to rest.
If not, please contact me with any further questions.
Very truly yours,
Your customer, <YOUR_NAME/PSEUDONYM>
```
documentation/docs/components/operators/templates/provider_introduction.md
+15
View File
@@ -0,0 +1,15 @@
```
I am reaching out to introduce myself. I am about to spin up a machine with you to run what is called a “nym node” - think of it as somewhat similar to a Tor exit node. You can always recognize a nym node by our domain names: nym-exit
Nym node runners are a decentralized community all over the world. We provide secure internet traffic routing services and privacy protection to ordinary people and businesses via the Nym platform and NymVPN app.
The Nym traffic pattern is somewhat unique, as we route traffic using the “sphinx” packet format (similar to Tor 's onion encryption), which makes all traffic look uniform. I wanted to introduce myself and the machines I am running just so that this unique traffic pattern doesn’t raise any flags or issues with you!
We have the highest security standards, which also means I simply relay traffic and do not know the end-destination nor its content. I can not be selective about the material transmitted through the Nym node that I run, and I have no practical means of either identifying the source of such material or preventing its transmission. More information can be found at https://nym.com.
Feel free to ask any questions.
Many thanks,
<YOUR_NAME/PSEUDONYM>
```
documentation/docs/components/outputs/api-scraping-outputs/nyx-outputs/circulating-supply.md
+1 -1
View File
@@ -1 +1 @@
805_903_308
807_251_217
documentation/docs/components/outputs/api-scraping-outputs/nyx-outputs/stake-saturation.md
+1 -1
View File
@@ -1 +1 @@
1_022_821
1_025_628
documentation/docs/components/outputs/api-scraping-outputs/nyx-outputs/staking-target.md
+1 -1
View File
@@ -1 +1 @@
402_951_654
403_625_608
documentation/docs/components/outputs/api-scraping-outputs/nyx-outputs/token-table.md
+4 -4
View File
@@ -1,7 +1,7 @@
| **Item** | **Description** | **Amount in NYM** |
|:-------------------|:------------------------------------------------------|--------------------:|
| Total Supply | Maximum amount of NYM token in existence | 1_000_000_000 |
| Mixmining Reserve | Tokens releasing for operators rewards | 194_096_191 |
| Vesting Tokens | Tokens locked outside of cicrulation for future claim | 500 |
| Circulating Supply | Amount of unlocked tokens | 805_903_308 |
| Stake Saturation | Optimal size of node self-bond + delegation | 1_022_821 |
| Mixmining Reserve | Tokens releasing for operators rewards | 192_748_782 |
| Vesting Tokens | Tokens locked outside of cicrulation for future claim | 0 |
| Circulating Supply | Amount of unlocked tokens | 807_251_217 |
| Stake Saturation | Optimal size of node self-bond + delegation | 1_025_628 |
documentation/docs/components/outputs/api-scraping-outputs/time-now.md
+1 -1
View File
@@ -1 +1 @@
Thursday, January 23rd 2025, 10:41:32 UTC
Monday, February 3rd 2025, 13:47:19 UTC
documentation/docs/pages/operators/changelog.mdx
+409
View File
@@ -1,9 +1,13 @@
import { Callout } from 'nextra/components';
import { Tabs } from 'nextra/components';
import { MyTab } from 'components/generic-tabs.tsx';
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
import { VarInfo } from 'components/variable-info.tsx';
import { AccordionTemplate } from 'components/accordion-template.tsx';
import { Steps } from 'nextra/components';
import AbuseResponse from 'components/operators/templates/dmca_response.md';
import OperatorIntroduction from 'components/operators/templates/provider_introduction.md';
export const TestingSteps = () => (
<div>
@@ -29,6 +33,11 @@ export const TunnelManagerCommands = () => (
</div>
);
export const LoadEndpointInfo = () => (
<div>
Developer notes behind <code>/load</code> endpoint
</div>
);
# Changelog
@@ -38,6 +47,406 @@ This page displays a full list of all the changes during our release cycle from
<VarInfo />
## `v2025.2-hu`
- [Release Binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2025.2-hu)
- [`nym-node`](nodes/nym-node.mdx) version `1.4.0`
```
nym-node
Binary Name: nym-node
Build Timestamp: 2025-02-04T09:35:42.399220545Z
Build Version: 1.4.0
Commit SHA: 4c2bf3642e8eec0d55c7753e14429d73ac2d0e99
Commit Date: 2025-02-04T10:29:48.000000000+01:00
Commit Branch: HEAD
rustc Version: 1.84.1
rustc Channel: stable
cargo Profile: release
```
### Operators Updates & Tools
<Callout type="info">
From `nym-node v1.3.0` operators can technically choose multiple functionalities for their `nym-node` binary (flagged as `--mode`).
**However, the clients are yet to be developed to be able to make a proper selection for multi-mode nodes!**
**WE ASK OPERATORS TO ASSIGN ONLY ONE FUNCTIONALITY TO `--mode` OPTION PER NODE. PLEASE SELECT ONE MODE ARGUMENT OUT OF: `mixnode` or `entry-gateway` or `exit-gateway`!**
</Callout>
- Updated maintenance guides to [backup](nodes/maintenance#backup-a-node), [restore](nodes/maintenance#restoring-a-node) and [move](nodes/maintenance#moving-a-node) a node, containing a new and important commands to backup and restore `clients.sqlite` database.
- [New explanation of `nym-node` functionalities](nodes/nym-node/setup#functionality-mode) describing how Gateways get selected in Mixnet mode and Wireguard mode.
<Callout type="warning">
Wireguard nodes route data directly to the open internet. Therefore it exposes IP of operators server (VPS) to abuse complains. Before you decide to run a node with active wireguard routing, please read our [Community Counsel pages](community-counsel/exit-gateway) containing more information and some legal content.
**Wireguard mode has no exit policy right now - we are working on the implementation.**
</Callout>
#### Legal support
We have been notified that a handful of nodes have been taken down by abuse reports. We created new pages with [legal suggestions](community-counsel/legal) and email [templates](community-counsel/templates). Here are some useful points on legal support:
- Here is the first version of a response template tailored for Nym operators.
<AccordionTemplate name="Email template: responding to DMCA take-down notices">
<AbuseResponse />
</AccordionTemplate>
- We are starting Operators Legal Clinic with Alexis Roussel, every Wednesday, 14:30 UTC (60 min) in our [Operator Legal Forum channel on Matrix](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org&via=matrix.su4ka.icu). Come and share your findigs and questions with the rest of the operators.
- Join [Operator Legal Forum channel](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org&via=matrix.su4ka.icu) and share as much as possible (like screen prints, provider, location etc).
- Join [Community legal counsel](https://nym.com/docs/operators/community-counsel) - our collective knowledge hub. Add your findings by opening a [Pull Request](https://nym.com/docs/operators/add-content)
- While we are working on a new list of more friendly providers, consider to move away from these provides as soon as possible:
- Servinga / VPS2day (AS39378)
- Frantech / Ponynet / BuyVM (AS53667)
- OVH SAS / OVHcloud (AS16276)
- Online S.A.S. / Scaleway (AS12876)
- Hetzner Online GmbH (AS24940)
- IONOS SE (AS8560)
- Psychz Networks (AS40676)
- 1337 Services GmbH / RDP.sh (AS210558)
- Backup your nodes to have access to `.nym` directory locally. Follow [node](nodes/maintenance#backup-a-node) and [proxy configuration](nodes/maintenance#backup-proxy-configuration) backup guides to be able to [restore your node](nodes/maintenance#restoring-a-node) later on on another machine, without losing your delegation.
- We would like to ask operators who use reverse proxy and a domain (required for Gateways) to start using a common convention starting with `nym-exit` for their nodes URL. The entire address should have this new format:
```
nym-exit.<CUSTOM>.<DOMAIN>.<TLD>
```
For example:
```
# for squads running multiple nodes a format can look like this:
nym-exit.ch-node1.mysquad.org
# or like this
nym-exit.3-jamaica.mysquad.org
# for operators having one node per location, the format can look like this:
nym-exit.brazil.mysquad.org
# or if operators decide to not have any custom, they can simply have this format:
nym-exit.mysquad.org
```
**The `NYM-EXIT` part in the beginning is what's important.**
- When registering a domain, check [Top Level Domain (TLD)](https://www.techopedia.com/definition/1348/top-level-domain-tld) terms and conditions. For example `.icu` is a no go. Having a wrong TLD may lead to your domain being taken away from you when facing a DMCA report.
- Write a message to your provider and introduce your intention to run a Nym Node on their service
<AccordionTemplate name="Email template: Introduce yourself to your VPS provider">
<OperatorIntroduction />
</AccordionTemplate>
- New page with [templates for VPS provider](community-counsel/templates)
#### Delegation Program
**If you are interested to sign up to delegation program que, message Merve on Element for the time being as we are working on CRM upgrade. We review nodes dynamically and delegate to new ones once a month.** New operators interested to join DP must follow the rules specified [here](https://delegations.explorenym.net/), run one of two latest binary version and have [Terms & Conditions](nodes/nym-node/setup#terms--conditions) accepted.
Note: Due to the token price we allow operators to have Operators cost 1000 NYM, the profit margin maximum remains 20%.
**Delegation and undelegation in January**
Delegated to all these nodes:
<AccordionTemplate name="New delegated nodes">
```
AMnDNd1Xgw7Em9R5vehP7r12ZNWUZ3jmitDHya6gpvGR
DLkKyYcA5feq43rqZdx6nJBNZvQsdX7kb2f1f6ED4cs2
26ZmTxTVBKHZg8MTKwypHkXZVJhDC7QHuv3BdsyRyTuk
5ZWdDN9pQ18vYkYYs5ZERh4P4JLtMiijscZ6FvwSfVxR
3uBgUJR393acoCRysu6SiLsximiwAMM85QFxq9WD8puC
5rXcNe2a44vXisK3uqLHCzpzvEwcnsijDMU7hg4fcYk8
nuMerN7ahqsptK8zDUZhnxMyDqePza8vWDf8k171EEs
86cNnnRxNpGdEtSX9UP1GpT6xrNvNuxFdHNkZcK7pAJg
9ngFADaYpT54F9i8iYFZLYR7SB7hrubsPArwpqe1RXQb
FQBbq1crAkCrjVBnEN85VqgZgGRMLJV65NJk8bPADdw
FUH3E3dghXjC9hdt3jeAhSsxwozsw1yzBXkoaFqkL4ci
5wF5wN7T2UuSsiUcQyL77NwdnXwAXxFttpZ1dR1nu4kR
4pVq4QSCcq4zNCnBNCfyugPjVhVyGDCBDSW5rghg8oZS
8XW1WWN1PuuAYz2TXQ9iWRekMFEJXjdEq4asMyE2qCCN
CxgjcTTAnRJzDxMbqtX73vEbWwLQmVoW8zS8RZEicgfT
7fwyXd4Cmh92d4piEPHmdFm1Wz1QCFQDf6bnDGNT3M6P
```
</AccordionTemplate>
Undelegated from 8 nodes for not meeting the rules (being offline):
<AccordionTemplate name="Undelegated nodes">
```
# Gateways
DLxLKsd3LTnfudSSmHanPaZACsh1x4MGEzfJS4jQibir
DiciBkjHovXzTDE2EFJKPNj3TGw2oQjr7HPSas2YQPiQ
ADjpymCgjFsE5m7YvnZFxLMscg85dCUUesR5g8yN3Mzz
C9dEABjtFRMD1x4ZnbqnsELGJgutT73bPCfYzqBe7sHB
# Mixnodes
2FGgY5zWq6JP1BvpnLPbedWRYYAZELFCT9rMybNhnxpo
4nKkwPSbkbtkw3yrRKQVAVdviNgFgcNskgcSGdT2Sucy
DjY3T7n6VoHGcETMnmtZKmUU7NZP6AhCs8CoRsSSbViC
FAKhiQ8nW5sAWAxks1WB8u1MAWsapToCSE3KmF9LuGRQ
```
</AccordionTemplate>
Undelegated due to high saturation:
```
5omopSZy59UyNPpx9P97vjBnN6PwPw9x5MVUx5kuNaXt
```
#### Service Grant Program v2
Aside from delegating on top of nodes, Nym runs a Service Grant Program (SGP) to support Exit Gateway operators before they will be rewarded by collecting [zk-nym tickets](../network/cryptography/zk-nym) from users subscription. Operators included in SGP are long term active community members with the highest requirements on the technical setup and upgrading pace. We are about to start a second iteration of SGP very soon (SGPv2). The final slots and locations are yet to be concluded. Priority to participate in SGPv2 will be given to the current operators in SGP. Based on the number of slots, we will then determine how many more operators can sign up.
##### Rules of SGPv2
<Callout type="info">
**We will share more info soon in the channels. The rules are not set in stone and could potentially be altered or updated in the future! Do *not* purchase new servers neither migrate your nodes just yet.**
</Callout>
As we finalising last details of *"Project Smoosh"*, where one binary - `nym-node` - can run as an `entry-gateway`, `mixnode` or `exit-gateway` in Mixnet mode as well as `entry-gateway` or `exit-gateway` in Wireguard mode, we plan to step up the game. SGPv2 grants will be higher if operators can meet new requirements.
**Minimum Specs & Requirements**
These are minimum requirements to become a part of SGPv2. We aim to have nodes on dedicated servers, with exceptions for much stronger VPS to meet the needed criteria while sharing server with other users.
<div>
<Tabs items={[
<><code>nym-node</code> - dedicated server</>,
<><code>nym-node</code> - VPS</>,
]} defaultIndex="0">
<MyTab>
#### `nym-node` - dedicated server
| **Hardware** | **Minimum Specification** |
| :--- | ---: |
| Type of server | Dedicated or bare metal |
| CPU Cores | 4 |
| Memory | 8-16 GB RAM |
| Storage | 50 GB (preferably 80 GB) |
| Connectivity | IPv4, IPv6, TCP/IP, UDP |
| Bandwidth | Unmetered if possible, or {" >"} 20Tb |
| Port speed | 1Gbps |
- Exit Gateways only
- [Terms & Conditions](nodes/nym-node/setup#terms--conditions) accepted
- Nodes are [bonded](nodes/nym-node/bonding#migrate-to-nym-node-in-mixnet-smart-contract) as `nym-node` not as a legacy node
- Timely upgrades without direct message notifications: Only Latest version, and the two preceding are accepted
- Dedicated (or bare metal) machine is to ensure that the numbers above are *dedicated* for `nym-node` operation
- Unmetered bandwidth is to ensure smooth user experience without data allowance limitation. 20Tb is a minimum for locations where unlimited bandwidth is not an option.
- 1Gbps is an expected speed of Nym network in order to meet expectations of NymVPN users
- Squads operating more than 2 nodes are expected to run larger servers and divide them for multiple nodes. We will share a how-to guide soon.
- Operators run [reverse proxy](nodes/nym-node/configuration) with landing page URL starting with `nym-exit` and [Web Secure Socket](nodes/nym-node/configuration)
- Operators must write their providers upfront that they will run a Nym Exit Gateway on their servers, using [this template](community-counsel/templates#introduction-to-server-provider)
- If a node remains offline for more than 5 days for any reason, including abuse reports, and the operator doesn't resolve it neither doesn't communicate the blockers, they will be removed from the program.
</MyTab>
<MyTab>
#### `nym-node` - VPS
| **Hardware** | **Minimum Specification** |
| :--- | ---: |
| Type of server | VPS |
| CPU Cores | 8 |
| Memory | 16-32 GB RAM |
| Storage | 50 GB (preferably 80 GB) |
| Connectivity | IPv4, IPv6, TCP/IP, UDP |
| Bandwidth | Unmetered if possible, or {" >"} 40Tb |
| Port speed | 10Gbps |
- Exit Gateways only
- [Terms & Conditions](nodes/nym-node/setup#terms--conditions) accepted
- Nodes are [bonded](nodes/nym-node/bonding#migrate-to-nym-node-in-mixnet-smart-contract) as `nym-node` not as a legacy node
- Timely upgrades without direct message notifications: Only Latest version, and the two preceding are accepted
- Stronger specs for VPS are to ensure that the `nym-node` operation will remain solid even when sharing a server with other users
- Unmetered bandwidth is to ensure smooth user experience without data allowance limitation. 40Tb is a minimum for locations where unlimited bandwidth is not an option.
- 10Gbps is to ensure that the 1Gbps expected speed of Nym network is met even when sharing a server with other users
- Operators run [reverse proxy](nodes/nym-node/configuration) with landing page URL starting with `nym-exit` and [Web Secure Socket](nodes/nym-node/configuration)
- Operators must write their providers upfront that they will run a Nym Exit Gateway on their servers, using [this template](community-counsel/templates#introduction-to-server-provider)
- If a node remains offline for more than 5 days for any reason, including abuse reports, and the operator doesn't resolve it neither doesn't communicate the blockers, they will be removed from the program.
</MyTab>
</Tabs>
</div>
**Operators interested in joining SGPv2 can start by searching for servers that meet the above criteria, where they may eventually migrate their nodes, and then share their findings by submitting a form which will be shared shortly. We will be first reaching to the current participants of Service Grant Program. Everything will be announced, sending DMs to devrel will not speed up the process!**
### Features
- [build(deps): bump criterion from `0.4.0` to `0.5.1`](https://github.com/nymtech/nym/pull/4911): Bumps [criterion](https://github.com/bheisler/criterion.rs) from `0.4.0` to `0.5.1`.
- [NS API: add mixnet scraper](https://github.com/nymtech/nym/pull/5200)
- [build(deps): bump http from `1.1.0` to `1.2.0`](https://github.com/nymtech/nym/pull/5228): Bumps [http](https://github.com/hyperium/http) from `1.1.0` to `1.2.0`.
- [`http-api-client`: deduplicate code](https://github.com/nymtech/nym/pull/5267): After adding PATCH support in [\#5260](https://github.com/nymtech/nym/pull/5260), it's now time to de-duplicate some of the code
- [Add windows to CI builds](https://github.com/nymtech/nym/pull/5269)
- [nym topology revamp](https://github.com/nymtech/nym/pull/5271): This PR changes the internals of the `NymTopology` to blur the lines between explicit mixnodes and gateways so that what used to be considered a "mixnode" could be a valid egress point of the network. `NymTopology` is no longer divided into `BTreeMap<MixLayer, Vec<mix::Node>>` and `Vec<gateway::Node>`. instead there's information about the current rewarded set (to support future VRF work) and a simple map of `HashMap<NodeId, RoutingNode>`. The new features are mostly controlled via 2 new flags/config values:
- `use_extended_topology` that tells the client to retrieve **all** network nodes rather than the ones that got assigned "active" mixnode role (or support being a gateway)
- `ignore_egress_epoch_role` that tells the client it's fine to construct egress packets to nodes that are **not** assigned entry or exit gateway role
- [Nyx Chain Watcher](https://github.com/nymtech/nym/pull/5274)
- [Include `IPINFO_API_TOKEN` in nightly CI](https://github.com/nymtech/nym/pull/5285)
- [Move tun constants to network defaults](https://github.com/nymtech/nym/pull/5286):
<AccordionTemplate name={<TestingSteps/>}>
1. **Regression Testing**:
- Verified no issues arose when running tests for the affected files.
- Tested TUN behaviour with new nym-nodes in the hu branch.
**Results**:
- **No bugs detected**.
- Tunnels are functioning as expected, with traffic routing and IP generation working seamlessly.
</AccordionTemplate>
- [Add dependabot assignes for the root cargo ecosystem](https://github.com/nymtech/nym/pull/5297)
- [build(deps): bump the patch-updates group across 1 directory with 35 updates](https://github.com/nymtech/nym/pull/5310): Bumps the `patch-updates` group with 33 updates
- [Periodically remove stale gateway messages](https://github.com/nymtech/nym/pull/5312): This PR introduces a simple task that removes gateway messages that haven't been retrieved in (by default) 24h.
<AccordionTemplate name={<TestingSteps/>}>
**Automation Script for Data Cleanup Validation**
Test Objective: Validate that the stale message cleanup mechanism in the database correctly removes records older than the configured threshold (24 hours).
Test Setup:
1. Environment:
* SQLite database
* Bash script: used to insert data.
Steps Performed:
1. Ran the insert_data.sh script to populate the database with test data:
* Recent records inserted successfully.
2. Verified the database content post-insertion: sqlite3 clients.sqlite "SELECT * FROM message_store;"
3. Confirmed that all 20 records (10 recent + 10 stale) were present.
4. Allowed the system to run for 24 hours to trigger the cleanup mechanism.
5. Queried the database again after 24 hours: sqlite3 gateway_storage.db "SELECT * FROM message_store;"
6.
Expected Result:
* All stale records (older than 24 hours) should be removed.
* Recent records should remain in the database.
Actual Result:
* Query after 24 hours showed only the 10 recent records.
* All 10 stale records were successfully removed.
</AccordionTemplate>
- [Use expect in geodata test to give error message on failure](https://github.com/nymtech/nym/pull/5314): Keep hitting this error on CI, from what I think is network hickup. But it's hard to tell form the log since the error is swallowed. Explicitly unwrap the result so we get a more detailed error output.
<AccordionTemplate name={<TestingSteps/>}>
**Quick Code Review**
**Summary**
1. **CI Workflow**: Adjusted paths to optimise build triggers, avoiding unnecessary CI runs while ensuring coverage for key directories
2. **Geolocation Test**: Improved error handling by replacing assertions with `.expect` for clearer debugging in API regression tests
**Conclusion**
Regression testing confirms everything works as intended. **Approved**.
</AccordionTemplate>
- [`CancellationToken`-based shutdowns](https://github.com/nymtech/nym/pull/5325): This PR introduces scaffolding for using `CancellationToken` and `TaskTracker` for our graceful shutdowns rather than the existing `TaskClient` and `TaskManager`.
- [Introduce `/load` endpoint for self-reported quantised Nym Node load](https://github.com/nymtech/nym/pull/5326): This PR introduces a new `/load` endpoint on a `NymNode` to return its current load. It returns the following data:
```rust
pub struct NodeLoad {
pub total: Load,
pub machine: Load,
pub network: Load,
}
```
Where `Load` is quantised into the following buckets / tiers:
```rust
pub enum Load {
Negligible, // 0 - 0.1
Low, // 0.1 - 0.3
Medium, // 0.3 - 0.6
High, // 0.6 - 0.8
VeryHigh, // 0.8 - 0.95
AtCapacity, // >= 0.95
}
```
<AccordionTemplate name={<LoadEndpointInfo/>}>
The actual values for`NodeLoad` are determined as follows:
- For network we approximate current rx/tx rates on all `eth` interfaces and scale them to the range of 0-1Gbps (for this initial iteration we assume the maximum network speed is 1Gbps which would be treated as fully saturated). So for example, if the node is sending at 0.5Gbps, it would get a `Load` of 0.5 and thus value of `Load::Medium`, 0.9Gbps would get `Load` of 0.9 and value of `Load::VeryHigh`, etc. we take the bigger value between rx and tx
- For machine load there's a bit more logic in there:
- Firstly we determine what I call a "base load" of the machine. we do this by taking the average load from the last 5min (via `getloadavg`) and dividing it by the number of CPUs in the machine. For example if the average load of the machine in the last 5min was `1.23` and it has 2 CPUs, then it's `Load` would be `Load::High` (`1.23 / 2 = 0.615`)
- However, whilst CPU utilisation is one of the most important factors, it does not tell the whole story. I tried to also take memory/swap utilisation into consideration (whilst not making it the main factor)
- Thus we calculate two additional auxiliary `Load` values, for memory usage and swap usage, i.e.: `used_memory / total_memory` and `used_swap / total_swap` respectively.
- Then we check whether either of the `MemoryLoad` or `SwapLoad` is bigger than the current base `Load` of the machine we have determined, if so, it's increased by one tier / bucket. For example, say the current machine load is `Load::Low`, but the memory usage is at 90% (`Load::VeryHigh`). that would result in the reported `Load` being bumped up to `Load::Medium` instead. The same logic applies with swap load, **however, only if the total swap > 1GB**. this is to prevent weird edge cases where the machine has hardly any swap.
- Finally, the `.total` `Load` uses the same "tier bumping" behaviour using the `.total` and `.network` loads, i.e. `if network > machine`, then `total = machine + 1`. for example if `machine` `Load` is `Load::Low`, but `network` `Load` is `Load::Medium`, then the `total` `Load` is set to `Load::Medium` instead.
</AccordionTemplate>
- [Bump the `patch-updates` group with 8 updates](https://github.com/nymtech/nym/pull/5336)
- [Bump `tempfile` from `3.14.0` to `3.15.0`](https://github.com/nymtech/nym/pull/5337)
- [Bump `ts-rs` from `10.0.0` to `10.1.0`](https://github.com/nymtech/nym/pull/5338)
- [Updated `cosmrs` and `tendermint-rpc` to their most recent versions](https://github.com/nymtech/nym/pull/5339)
- [Bump mikefarah/yq from `4.44.6` to `4.45.1`](https://github.com/nymtech/nym/pull/5342)
- [Update `indexed_db_futures`](https://github.com/nymtech/nym/pull/5347): Updates the `indexed_db_futures` dependency to stop relying on the fork.
- [Refresh wasm sdk](https://github.com/nymtech/nym/pull/5353): This PR refreshes the wasm clients to make them usable in the current network
- [Client gateway selection](https://github.com/nymtech/nym/pull/5358): Changed how gateway is selected.
- For init the target gateway can't support mixing
- For egress, unless `ignore_epoch_roles` is specified, the gateway can't be currently assigned to a mixing layer. But it can be standby or inactive
- [Exposed `NymApiClient` method for obtaining node performance history](https://github.com/nymtech/nym/pull/5360)
- [Bind to `[::]` on `nym-node` for both IP versions](https://github.com/nymtech/nym/pull/5361)
<AccordionTemplate name={<TestingSteps/>}>
**IPv4 Configuration and Migration Testing**
Testing Steps:
- Initiated and ran a nym-node with version 1.3.1 on an IPv4-only machine, then updated it to the new 'hu', 1.4.0 version.
- Initiated and ran a new nym-node with 'hu', 1.4.0 always on a machine with only IPv4.
- Initiated and ran a new nym-node with 'hu', 1.4.0 on a machine with both IPv4 and IPv6 for regression testing.
Results:
- No functional issues during version updates.
- Logged message on all versions: "no registered client for destination: ff02::2"
Status: Pass
</ AccordionTemplate>
- [Remove empty ephemeral keys](https://github.com/nymtech/nym/pull/5376)
- [Handle ecash network errors differently](https://github.com/nymtech/nym/pull/5378): For errors that could be caused by network problems, we should mark the ticket as still pending, not as bad. This won't fix the underlying problem, but should not assume anymore that the client is the culprit and penalise its bandwidth quota.
- [Make client ignore dual mode nodes by default](https://github.com/nymtech/nym/pull/5388)
<AccordionTemplate name={<TestingSteps/>}>
**Testing Steps:**
- Ensured a client is able to select a node which aside from a gateway, can also act as a mixnode
- Verified 'ignore_epoch_roles' is the default mode
- _note; this is most likely not going to be a permanent solution_
**Results:**
- Clients and topology are behaving correctly
Status: Pass
</ AccordionTemplate>
- [Update version of chain watcher and validator rewarder](https://github.com/nymtech/nym/pull/5394)
### Bugfix
- [Remove unnecessary arguments for nym-api swagger endpoints](https://github.com/nymtech/nym/pull/5272)
- [Fixed sql migration for adding default message timestamp](https://github.com/nymtech/nym/pull/5374)
- [Terminate mixnet socket listener on shutdown](https://github.com/nymtech/nym/pull/5389)
- [Correctly handle ingore epoch roles flag](https://github.com/nymtech/nym/pull/5390)
## `v2025.1-reeses`
- [Release Binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2025.1-reeses)
documentation/docs/pages/operators/community-counsel/_meta.json
+2
View File
@@ -1,5 +1,7 @@
{
"exit-gateway": "Exit Gateway",
"legal": "Legal Counsel",
"templates": "Templates",
"jurisdictions": "Jurisdictions",
"isp-list": "ISP List",
"landing-pages": "Landing Pages",
documentation/docs/pages/operators/community-counsel/legal.mdx
+84
View File
@@ -0,0 +1,84 @@
import { Callout } from 'nextra/components';
import { Tabs } from 'nextra/components';
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
import { VarInfo } from 'components/variable-info.tsx';
import { AccordionTemplate } from 'components/accordion-template.tsx';
import { Steps } from 'nextra/components';
import AbuseResponse from 'components/operators/templates/dmca_response.md';
import OperatorIntroduction from 'components/operators/templates/provider_introduction.md';
# Community Counsel: General Legal Considerations
**This page contains some tips & tricks to support operators running Exit Gateway (`nym-node` in mode `exit-gateway`) gathered by the operators community. Have a look on the points below to strengthen your legal protection.**
<VarInfo />
## Useful Suggestions
#### Introduce Nym Node to your provider
Write a message to your provider telling them about your intention to run a `nym-node` on their infrastructure. You can use this template for it.
<br/>
<AccordionTemplate name="Email template: Introduce yourself to your VPS provider">
<OperatorIntroduction />
</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.
#### 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).
#### Use a friendly provider
Nym operators community shares their experience with different ISPs on [this page](isp). At the same time, consider to move away from these provides:
- Servinga / VPS2day (AS39378)
- Frantech / Ponynet / BuyVM (AS53667)
- OVH SAS / OVHcloud (AS16276)
- Online S.A.S. / Scaleway (AS12876)
- Hetzner Online GmbH (AS24940)
- IONOS SE (AS8560)
- Psychz Networks (AS40676)
- 1337 Services GmbH / RDP.sh (AS210558)
#### Backup your nodes
Your only way to restore your node is when you have an access to `.nym` directory locally. Follow [node](../nodes/maintenance#backup-a-node) and [proxy configuration](../nodes/maintenance#backup-proxy-configuration) backup guides to be able to [restore your node](../nodes/maintenance#restoring-a-node) on another machine later on, without losing your delegation.
#### Use `nym-exit` prefix on your landing page URL
We would like to ask operators to use [reverse proxy](../nodes/nym-node/configuration/proxy-configuration) with a [landing page](landing-pages). When assigning a domain please use a common convention with `nym-exit` in the beginning of the the page URL as this will create a reputation and reference. The entire address should have this new format:
```
nym-exit.<CUSTOM>.<DOMAIN>.<TLD>
```
For example:
```
# for squads running multiple nodes a format can look like this:
nym-exit.ch-node1.mysquad.org
# or like this
nym-exit.3-jamaica.mysquad.org
# for operators having one node per location, the format can look like this:
nym-exit.brazil.mysquad.org
# or if operators decide to not have any custom, they can simply have this format:
nym-exit.mysquad.org
```
**The `NYM-EXIT` part in the beginning is what's important.**
#### Chose the right TLD
When registering a domain, check [Top Level Domain (TLD)](https://www.techopedia.com/definition/1348/top-level-domain-tld) terms and conditions. For example `.icu` is a no go. Having a wrong TLD may lead to your domain being taken away from you when facing a DMCA report.
#### Respond to abuse reports
Make sure to read notifications from your account provider and if you receive an abuse report, respond to it in time. Here is a template explaining the essential legal background of Nym Node Exit Gateway. Don't forget to adjust the variables.
<br/>
<AccordionTemplate name="Email template: responding to DMCA take-down notices">
<AbuseResponse />
</AccordionTemplate>
#### Help us to improve these pages
Add your findings by opening a [Pull Request](add-content).
documentation/docs/pages/operators/community-counsel/templates.mdx
+23
View File
@@ -0,0 +1,23 @@
import { Callout } from 'nextra/components';
import { Tabs } from 'nextra/components';
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
import { VarInfo } from 'components/variable-info.tsx';
import { AccordionTemplate } from 'components/accordion-template.tsx';
import { Steps } from 'nextra/components';
import AbuseResponse from 'components/operators/templates/dmca_response.md';
import OperatorIntroduction from 'components/operators/templates/provider_introduction.md';
# Templates for Providers
Communication with your provider is an essential part of legal defense, as more often than not, terminating a server is based on the lack of knowledge about Nym Node and it's legal bases. Use the following templates to introduce your intention to run a Nym Node or as a response to abuse report.
<VarInfo/ >
## Email Templates
### Introduction to server provider
<OperatorIntroduction />
### DMCA abuse report response
<AbuseResponse />
documentation/docs/pages/operators/nodes.mdx
+1 -3
View File
@@ -35,9 +35,7 @@ Accepting T&Cs is done via a flag `--accept-operator-terms-and-conditions` added
This is a summary of all needed steps for node operators to setup and configure a `nym-node` and register it to Nym Network:
1. **Start with [Preliminary Steps](nodes/preliminary-steps.mdx), preparing:**
- [VPS](nodes/preliminary-steps/vps-setup.mdx)
- [Nym wallet](nodes/preliminary-steps/wallet-preparation)
1. **Start with [Preliminary Steps](nodes/preliminary-steps.mdx), preparing [VPS](nodes/preliminary-steps/vps-setup.mdx) and [Nym wallet](nodes/preliminary-steps/wallet-preparation)**
2. **[Setup](nodes/nym-node/setup.mdx) the node**
documentation/docs/pages/operators/nodes/maintenance.mdx
+102 -7
View File
@@ -126,13 +126,32 @@ mkdir -pv <PATH_TO_TARGET_DIRECTORY>
# mkdir -pv $HOME/backup/my_nym_node/.nym
```
###### 2. Copy configuration folder `.nym` from your VPS to your newly created backup directory
###### 2. Backup `clients.sqlite` database
- Install `sqlite3`
```sh
apt install sqlite3
```
- Open sqlite CLI shell inside `clients.sqlite` database
```sh
sqlite3 ~/.nym/nym-nodes/default-nym-node/data/clients.sqlite
```
- Create backup called `clients_backup.sqlite`
```sh
.backup .nym/nym-nodes/default-nym-node/data/clients_backup.sqlite
```
- Exit sqlite CLI shell
```sh
.exit
```
###### 3. Copy configuration folder `.nym` from your VPS to your newly created backup directory
```sh
scp -r <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:~/.nym/nym-nodes/<ID> <PATH_TO_TARGET_DIRECTORY>
```
###### 3. Verify the success of the backup
###### 4. Verify the success of the backup
The `scp` command should print logs, an operator can see directly whether it was successful or if it encountered any error. However, double check that all your needed configuration is in the backup target directory.
@@ -227,7 +246,33 @@ The `scp` command should print logs, an operator can see directly whether it was
* Run a command `echo "$(curl -4 https://ifconfig.me)"` to see your public IPv4
* Edit config file located at `~/.nym/nym-nodes/<ID>/config/config.toml` correct IP - it's the field under the header `[host]`, called `public_ips = [<PUBLIC_IPS>,]`
* Add your new location field `location = <LOCATION>`, (formats like: 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided).
* Try to run the node and see if everything works.
###### 5. Restore `clients.sqlite` database
- Install `sqlite3`
```sh
apt install sqlite3
```
- Open sqlite CLI shell inside `clients.sqlite` database
```sh
sqlite3 ~/.nym/nym-nodes/default-nym-node/data/clients.sqlite
```
- Restore your backup called `clients_backup.sqlite`
```sh
.restore .nym/nym-nodes/default-nym-node/data/clients_backup.sqlite
```
- Exit sqlite CLI shell
```sh
.exit
```
- Check integrity
```sh
sqlite3 ~/.nym/nym-nodes/default-nym-node/data/clients.sqlite "PRAGMA integrity_check;"
```
The result should return `ok` if the database is intact.
###### 6. Test & validate your setup
* Dry run the node and see if everything works.
* Setup the [systemd](nym-node/configuration.mdx#systemd) automation (don't forget to add the [terms and conditions flag](nym-node/setup.mdx#terms--conditions)) to `ExecStart` command, reload the daemon and run the service.
###### 4. Change the node smart contract info via the wallet interface
@@ -313,21 +358,71 @@ mkdir ~/.nym
#in case no `nym-node` was initialized previously
mkdir ~/.nym/nym-nodes
```
###### 2. Backup `clients.sqlite` database
###### 2. Move the node data and keys to the new machine
- Stop your node
```sh
service nym-node stop
```
- Install `sqlite3`
```sh
apt install sqlite3
```
- Open sqlite CLI shell inside `clients.sqlite` database
```sh
sqlite3 ~/.nym/nym-nodes/default-nym-node/data/clients.sqlite
```
- Create backup called `clients_backup.sqlite`
```sh
.backup .nym/nym-nodes/default-nym-node/data/clients_backup.sqlite
```
- Exit sqlite CLI shell
```sh
.exit
```
###### 3. Move the node data and keys to the new machine
* Open your **local terminal** (as that one's ssh key is authorized in both of the VPS) and run:
```sh
scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:~/.nym/nym-nodes <TARGET_USER_NAME>@<TARGET_HOST_ADDRESS>:~/.nym/nym-nodes/
```
###### 3. Open new/target VPS terminal and configure the node
###### 4. Open new/target VPS terminal and configure the node
* Edit `~/.nym/nym-nodes/<ID>/config/config.toml` config with the new listening address IP - it's the one under the header `[host]`, called `public_ips = [<PUBLIC_IPS>,]` and add your new location (field `location = <LOCATION>`, formats like: 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided). You can see your IP by running a command `echo "$(curl -4 https://ifconfig.me)"`.
* Try to run the node and see if everything works.
* Setup the [systemd](nym-node/configuration.mdx#systemd) automation (don't forget to add the [terms and conditions flag](nym-node/setup.mdx#terms--conditions)) to `ExecStart` command, reload the daemon and run the service. If you want to use the exact same service config file, you can also copy it from one VPS to another following the same logic by opening your **local terminal** (as that one's ssh key is authorized in both of the VPS) and running:
###### 5. Restore `clients.sqlite` database
- Install `sqlite3`
```sh
apt install sqlite3
```
- Open sqlite CLI shell inside `clients.sqlite` database
```sh
sqlite3 ~/.nym/nym-nodes/default-nym-node/data/clients.sqlite
```
- Restore your backup called `clients_backup.sqlite`
```sh
.restore .nym/nym-nodes/default-nym-node/data/clients_backup.sqlite
```
- Exit sqlite CLI shell
```sh
.exit
```
- Check integrity
```sh
sqlite3 ~/.nym/nym-nodes/default-nym-node/data/clients.sqlite "PRAGMA integrity_check;"
```
The result should return `ok` if the database is intact.
###### 6. Test & validate your setup
* Dry run the node and see if everything works.
* Setup the [systemd](nym-node/configuration.mdx#systemd) automation (don't forget to add the [terms and conditions flag](nym-node/setup.mdx#terms--conditions)) to `ExecStart` command, reload the daemon and run the service.
* If you want to use the exact same service config file, you can also copy it from one VPS to another following the same logic by opening your **local terminal** (as that one's ssh key is authorized in both of the VPS) and running:
```sh
scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:/etc/systemd/system/nym-node.service <TARGET_USER_NAME>@<TARGET_HOST_ADDRESS>:/etc/systemd/system/nym-node.service
```
documentation/docs/pages/operators/nodes/nym-node/setup.mdx
+26 -12
View File
@@ -20,12 +20,12 @@ This documentation page provides a guide on how to set up and run a [NYM NODE](.
```sh
nym-node
Binary Name: nym-node
Build Timestamp: 2025-01-16T11:54:17.079662337Z
Build Version: 1.3.1
Commit SHA: 5ab164d229f85bd2dd27ec6e38292c281df2f678
Commit Date: 2025-01-16T12:51:53.000000000+01:00
Build Timestamp: 2025-02-04T09:35:42.399220545Z
Build Version: 1.4.0
Commit SHA: 4c2bf3642e8eec0d55c7753e14429d73ac2d0e99
Commit Date: 2025-02-04T10:29:48.000000000+01:00
Commit Branch: HEAD
rustc Version: 1.84.0
rustc Version: 1.84.1
rustc Channel: stable
cargo Profile: release
```
@@ -39,21 +39,35 @@ cargo Profile: release
<Callout type="info">
From `nym-node v1.3.0` operators can choose multiple functionalities for their `nym-node` binary (flagged as `--mode`).
**However, the clients are yet to be developed to be able to make a proper selection for multi-mode nodes and therefore we ask operators to sign only one functionality to `--mode` option at a time. Please chose out of: `mixnode` or `entry-gateway` or `exit-gateway`.**
We are developing a design where operators can enable multiple modes, and let the Nym API to position the node according the network's needs in the beginning of each epoch.
**However, the clients are yet to be developed to be able to make a proper selection for multi-mode nodes and therefore we ask operators to assign only one functionality to `--mode` option at a time. Please chose out of: `mixnode` or `entry-gateway` or `exit-gateway`. Chosing multiple at once will make your node non-routable!**
</Callout>
Nym Node has three functionalities in the network: `entry-gateway`, `mixnode` and `exit-gateway`.
### Mixnet Routing
- **Entry Gateway (`--mode entry-gateway`)**: A the node to which local client connects. It checks the bandwidth allowance, using [zk-nyms](../../../network/cryptography/zk-nym) and either sends [Sphinx packets](../../../network/cryptography/sphinx) through the mixnet or directly to Exit Gateway in case of dVPN (2-hop) routing. This node also recieves replies and sends them back to users local client.
***Mixnet mode (5-hop) is the full anonymising option of NymVPN. Read more about the Mixnet architecture [here](http://localhost:3000/docs/network/architecture)***
- **Mixnode (`--mode mixnode`)**: Nodes organized in three layers, randmoly selected every epoch (60 minutes), mixing Sphinx packets, adding a slight latency to defend users agains time correlation attacks and sending them further to the next layer or to the Exit Gateway
Nym Node has three functionalities in the Mixnet: `entry-gateway`, `mixnode` and `exit-gateway`. These are selected with a flag `--mode <MODE>` alongside `nym-node` command `run` .
- **Entry Gateway (`--mode entry-gateway`)**: A node to which clients connect. It checks the bandwidth allowance, using [zk-nyms](../../../network/cryptography/zk-nym) and either sends [Sphinx packets](../../../network/cryptography/sphinx) through the mixnet or directly to Exit Gateway in case of dVPN (2-hop) routing. This node also receives replies and sends them back to users local client.
- **Mixnode (`--mode mixnode`)**: Nodes organized in three layers, randomly selected every epoch (60 minutes), mixing Sphinx packets, adding a slight latency to defend users agains time correlation attacks and sending them further to the next layer or to the Exit Gateway
- **Exit Gateway (`--mode exit-gateway`)**: The final node in the mixnet. It puts all packets together and using inbuilt Network requester and IP packet router, it sends traffic to the open internet. This node also recieves replies and sends them back to the user client.
<Callout type="warning">
Exit Gateway is the only node routing data directly to the open internet. Therefore it exposes IP of operators server (VPS) to abuse complains. Before you decide to run an Exit Gateway, please read our [Community Counsel pages](../../community-counsel/exit-gateway) containing more information and some legal content.
Exit Gateway is the only mode routing data directly to the open internet. Therefore it exposes IP of operators server (VPS) to abuse complains. Before you decide to run an Exit Gateway, please read our [Community Counsel pages](../../community-counsel/exit-gateway) containing more information and some legal content.
</Callout>
### dVPN Routing
***dVPN routing (2-hop) is the Fast option of NymVPN. It runs a wireguard tunnel inside another wireguard tunnel. dVPN uses 2 Gateway layers (entry and exit) and no Mixnode layers. If an operator announces and [correctly configure](configuration#connectivity-test-and-configuration) their node to route wireguard, the node can be chosen as entry or exit by any client at any time.***
To activate wireguard routing, operators need to add `--wireguard-enabled true` alongside `nym-node` command `run`.
<Callout type="warning">
Wireguard nodes route data directly to the open internet. Therefore it exposes IP of operators server (VPS) to abuse complains. Before you decide to run a node with active wireguard routing, please read our [Community Counsel pages](../../community-counsel/exit-gateway) containing more information and some legal content.
**Wireguard mode has no exit policy right now - we are working on the implementation.**
</Callout>
Everything essential for each mode exists on `nym-node` by default. For instance, if you run a Mixnode, you'll find that a NR (Network Requester) and IPR (IP Packet Router) addresses exist, but they will be ignored in `mixnode` mode.
documentation/docs/pages/operators/tokenomics/mixnet-rewards.mdx
+1 -1
View File
@@ -146,7 +146,7 @@ Besides these values, the API is also looking whether the node is bonded in Mixn
**The node score is calculated with this formula:**
<Callout type="info" emoji="📌">
> **active_set_selection_probability = total_stake \* ( config_score \* node_performance ) ^ 20 )**
> **active_set_selection_probability = total_stake \* (( config_score \* node_performance ) ^ 20 )**
</Callout>
Note that the score helps prioritize some nodes over others. If all available nodes have the same score, then the selection is done uniformly at random. By raising the config and performance components to 20, values of these parameters that are below one incur a heavy penalization for the node’s selection chances.