Merge branch 'feature/mixnode-sandbox-cycles' of https://github.com/nymtech/nym into feature/mixnode-sandbox-cycles

remove noise

.github/workflows/build-upload-binaries.yml

@@ -1,16 +1,10 @@
-name: build-upload-binaries
+name: ci-build-upload-binaries
 
 on:
   workflow_dispatch:
-    inputs:
-      add_tokio_unstable:
-        description: 'True to add RUSTFLAGS="--cfg tokio_unstable"'
-        required: true
-        default: false
-        type: boolean
-
-env:
-  NETWORK: mainnet
+  pull_request:
+    paths:
+      - 'mixnode/**'
 
 jobs:
   publish-nym:
@@ -22,40 +16,49 @@ jobs:
     runs-on: ${{ matrix.platform }}
     env:
       CARGO_TERM_COLOR: always
+      RUSTFLAGS: "--cfg tokio_unstable"
+
     steps:
       - uses: actions/checkout@v3
 
-      - name: Install Dependencies (Linux)
-        run: sudo apt-get update && sudo apt-get -y install libwebkit2gtk-4.0-dev build-essential curl wget libssl-dev libgtk-3-dev libudev-dev squashfs-tools
-        continue-on-error: true
-
-      - name: Sets env vars for tokio if set in manual dispatch inputs
+      - name: Prepare build output directory
+        shell: bash
+        env:
+          OUTPUT_DIR: ci-builds/${{ github.ref_name }}
         run: |
-          echo 'RUSTFLAGS="--cfg tokio_unstable"' >> $GITHUB_ENV
-        if: github.event_name == 'workflow_dispatch' && inputs.add_tokio_unstable == true
+          rm -rf ci-builds || true
+          mkdir -p $OUTPUT_DIR
+          echo $OUTPUT_DIR
+
+      - name: Install Dependencies (Linux)
+        run: sudo apt update && sudo apt install libudev-dev
 
       - name: Install Rust stable
         uses: actions-rs/toolchain@v1
         with:
           toolchain: stable
 
-      - name: Build all binaries
+      - name: Build mixnode binary
         uses: actions-rs/cargo@v1
         with:
           command: build
-          args: --workspace --release
+          args: --release --features cpucycles --package nym-mixnode
 
-      - name: Upload Artifact
-        uses: actions/upload-artifact@v3
-        with:
-          name: nym-binaries-artifacts
-          path: |
-            target/release/nym-client
-            target/release/nym-gateway
-            target/release/nym-mixnode
-            target/release/nym-socks5-client
-            target/release/nym-api
-            target/release/nym-network-requester
-            target/release/nym-network-statistics
-            target/release/nym-cli
-          retention-days: 30
+      - name: Prepare build output
+        shell: bash
+        env:
+          OUTPUT_DIR: ci-builds/${{ github.ref_name }}
+        run: |
+          cp target/release/nym-mixnode $OUTPUT_DIR
+
+      - name: Deploy branch to CI www
+        continue-on-error: true
+        uses: easingthemes/ssh-deploy@main
+        env:
+          SSH_PRIVATE_KEY: ${{ secrets.CI_WWW_SSH_PRIVATE_KEY }}
+          ARGS: "-avzr"
+          SOURCE: "ci-builds/"
+          REMOTE_HOST: ${{ secrets.CI_WWW_REMOTE_HOST }}
+          REMOTE_USER: ${{ secrets.CI_WWW_REMOTE_USER }}
+          TARGET: ${{ secrets.CI_WWW_REMOTE_TARGET }}/builds/
+          EXCLUDE: "/dist/, /node_modules/"

documentation/operators/src/nodes/maintenance.md

@@ -25,14 +25,14 @@ These steps are for an operator who is setting up a [Gateway](gateway-setup.md)
 
 1. New flags will need to be added to the `init` and `run` command. The `--host` option should be replaced with these flags:
 
-- `--listening-address`: The IP address which is used for receiving sphinx packets and listening to client data.
-- `--public-ips`: A comma separated list of IP’s that are announced to the `nym-api`. In the most cases `--public-ips` **is the address used for bonding.**
+- `--listening-address`: The IP address which is used for receiving sphinx packets and listening to client data. 
+- `--public-ips`: A comma separated list of IP’s that are announced to the `nym-api`. In the most cases `--public-ips` **is the address used for bonding.** 
 
 ```sh
 --listening-address 0.0.0.0 --public-ips "$(curl -4 https://ifconfig.me)"
 ```
 
-- `--hostname` (optional): This flag is required if the operator wishes to run WSS. It can be something like `mainnet-gateway2.nymtech.net`.
+- `--hostname` (optional): This flag is required if the operator wishes to run WSS. It can be something like `mainnet-gateway2.nymtech.net`. 
 
 2. Make sure to enable all necessary [ports](maintenance.md#configure-your-firewall) on the Gateway:
 
@@ -42,7 +42,7 @@ sudo ufw allow 1789,1790,8000,9000,9001,22/tcp, 9001/tcp
 
 The Gateway will then be accessible on something like: *http://85.159.211.99:8080/api/v1/swagger/index.html*
 
-Are you seeing something like: *this node attempted to announce an invalid public address: 0.0.0.0.*?
+Are you seeing something like: *this node attempted to announce an invalid public address: 0.0.0.0.*? 
 
 Please modify `[host.public_ips]` section of your config file stored as `~/.nym/gateways/<ID>/config/config.toml`.
 
@@ -92,7 +92,7 @@ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo
 apt update
 apt install caddy
 
-systemctl enable caddy.service
+systemctl enable caddy.service 
 
 cd /etc/caddy
 
@@ -102,7 +102,7 @@ if [ -f Caddyfile ]; then
     rm -f Caddyfile
 fi
 
-cat  <<EOF >> Caddyfile
+cat  <<EOF >> Caddyfile 
 ${host}:${port_value} {
 	@websockets {
 		header Connection *Upgrade*
@@ -191,9 +191,9 @@ nohup ./<NODE> run --id <YOUR_ID> # where `<YOUR_ID>` is the id you set during t
 
 #### tmux
 
-One way is to use `tmux` shell on top of your current VPS terminal. Tmux is a terminal multiplexer, it allows you to create several terminal windows and panes from a single terminal. Processes started in `tmux` keep running after closing the terminal as long as the given `tmux` window was not terminated.
+One way is to use `tmux` shell on top of your current VPS terminal. Tmux is a terminal multiplexer, it allows you to create several terminal windows and panes from a single terminal. Processes started in `tmux` keep running after closing the terminal as long as the given `tmux` window was not terminated.  
 
-Use the following command to get `tmux`.
+Use the following command to get `tmux`.  
 
 Platform|Install Command
 ---|---
@@ -204,15 +204,15 @@ RHEL or CentOS|`yum install tmux`
 macOS (using Homebrew|`brew install tmux`
 macOS (using MacPorts)|`port install tmux`
 openSUSE|`zypper install tmux`
-
-In case it didn't work for your distribution, see how to build `tmux` from [version control](https://github.com/tmux/tmux#from-version-control).
+  
+In case it didn't work for your distribution, see how to build `tmux` from [version control](https://github.com/tmux/tmux#from-version-control).  
 
 **Running tmux**
 
 Now you have installed tmux on your VPS, let's run a Mix Node on tmux, which allows you to detach your terminal and let your `<NODE>` run on its own on the VPS.
 
 * Pause your `<NODE>`
-* Start tmux with the command
+* Start tmux with the command 
 ```sh
 tmux
 ```
@@ -230,7 +230,7 @@ tmux attach-session
 
 #### systemd
 
-To automate with `systemd` use this init service file and follow the steps below.
+To automate with `systemd` use this init service file and follow the steps below. 
 
 ##### For Mix Node
 
@@ -327,18 +327,18 @@ Change the `<PATH>` in `ExecStart` to point at your `<NODE>` binary (`nym-mixnod
 
 Example: If you have built nym in the `$HOME` directory on your server, your username is `jetpanther`, and node `<ID>` is `puma`, then the `ExecStart` line (command) in the script located in `/etc/systemd/system/nym-mixnode.service` for Nym Mixnode might look like this:
 
-`ExecStart=/home/jetpanther/nym/target/release/nym-mixnode run --id puma`.
+`ExecStart=/home/jetpanther/nym/target/release/nym-mixnode run --id puma`. 
 
 Basically, you want the full `/<PATH>/<TO>/nym-mixnode run --id <WHATEVER-YOUR-NODE-ID-IS>`. If you are unsure about your `/<PATH>/<TO>/<NODE>`, then `cd` to your directory where you run your `<NODE>` from and run `pwd` command which returns the full path for you.
 
 Once done, save the script and follow these steps:
 
 ```sh
-systemctl daemon-reload
+systemctl daemon-reload 
 # to pickup the new unit file
 ```
 
-Enable the newly created service:
+Enable the newly created service: 
 
 ```sh
 # for Mix Node
@@ -350,7 +350,7 @@ systemctl enable nym-gateway.service
 # for Network Requester
 systemctl enable nym-network-requester.service
 
-# for Nymvisor
+# for Nymvisor 
 systemctl enable nymvisor.service
 ```
 
@@ -367,7 +367,7 @@ service nym-gateway start
 service nym-network-requester.service
 
 # for Nymvisor
-service nymvisor.service start
+service nymvisor.service start 
 ```
 
 This will cause your `<NODE>` to start at system boot time. If you restart your machine, your `<NODE>` will come back up automatically.
@@ -427,7 +427,7 @@ systemctl start nymd    # to actually start the service
 journalctl -f -u nymd # to monitor system logs showing the service start
 ```
 
-##### For Nym API
+##### For Nym API 
 
 Below is a `systemd` unit file to place at `/etc/systemd/system/nym-api.service` to automate your API instance:
 
@@ -535,7 +535,7 @@ In case you chose tmux option for Mix Node automation, see your `ulimit` list by
 ulimit -a
 
 # watch for the output line -n
--n: file descriptors          1024
+-n: file descriptors          1024      
 ```
 
 You can change it either by running a command:
@@ -582,14 +582,14 @@ scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:~/.nym/mixnodes/<YOUR_ID> <TA
 ```
 * Re-run init (remember that init doesn't overwrite existing keys) to generate a config with the new listening address etc.
 * Change the node smart contract info via the wallet interface. Otherwise the keys will point to the old IP address in the smart contract, and the node will not be able to be connected, and it will fail up-time checks.
-* Re-run the node from the new location.
+* Re-run the node from the new location. 
 
 
 ## Virtual IPs and hosting via Google & AWS
 
 For true internet decentralization we encourage operators to use diverse VPS providers instead of the largest companies offering such services. If for some reasons you have already running AWS or Google and want to setup a `<NODE>` there, please read the following.
 
-On some services (AWS, Google, etc) the machine's available bind address is not the same as the public IP address. In this case, bind `--host` to the local machine address returned by `$(curl -4 https://ifconfig.me)`, but that may not the public IP address to bond your `<NODE>` in the wallet.
+On some services (AWS, Google, etc) the machine's available bind address is not the same as the public IP address. In this case, bind `--host` to the local machine address returned by `$(curl -4 https://ifconfig.me)`, but that may not the public IP address to bond your `<NODE>` in the wallet. 
 
 You can run `ifconfig` command. For example, on a Google machine, you may see the following output:
 
@@ -601,7 +601,7 @@ ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1460
 
 The `ens4` interface has the IP `10.126.5.7`. But this isn't the public IP of the machine, it's the IP of the machine on Google's internal network. Google uses virtual routing, so the public IP of this machine is something else, maybe `36.68.243.18`.
 
-To find the right IP configuration, contact your VPS provider for support to find the right public IP and use it to bond your `<NODE>` with the `nym-api` via Nym wallet.
+To find the right IP configuration, contact your VPS provider for support to find the right public IP and use it to bond your `<NODE>` with the `nym-api` via Nym wallet. 
 
 On self-hosted machine it's a bit more tricky. In that case as an operator you must be sure that your ISP allows for public IPv4 and IPv6 and then it may be a bit of playing around to find the right configuration. One way may be to bind your binary with the `--host` flag to local address `127.0.0.1` and run `echo "$(curl -4 https://ifconfig.me)"` to get a public address which you use to bond your Mix Node to `nym-api` via Nym wallet.
 
@@ -650,7 +650,7 @@ Query Response:
 
 ### Validator: Installing and configuring nginx for HTTPS
 #### Setup
-[Nginx](https://www.nginx.com/resources/glossary/nginx) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security.
+[Nginx](https://www.nginx.com/resources/glossary/nginx/#:~:text=NGINX%20is%20open%20source%20software,%2C%20media%20streaming%2C%20and%20more.&text=In%20addition%20to%20its%20HTTP,%2C%20TCP%2C%20and%20UDP%20servers.) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security.
 
 Install `nginx` and allow the 'Nginx Full' rule in your firewall:
 
@@ -678,16 +678,15 @@ Which should return:
            └─2380 nginx: worker process
 ```
 
-#### Full Node Configuration
+#### Configuration
 
-Proxying various full node services through port 80 can then be done by creating a file with the following at `/etc/nginx/sites-enabled/nyxd-webrequests.conf`:
+Proxying your validator's port `26657` to nginx port `80` can then be done by creating a file with the following at `/etc/nginx/conf.d/validator.conf`:
 
 ```sh
-### To expose RPC server
 server {
   listen 80;
   listen [::]:80;
-  server_name "<rpc.nyx.yourdomain.tld>";
+  server_name "domain_name";
 
   location / {
     proxy_pass http://127.0.0.1:26657;
@@ -696,58 +695,20 @@ server {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
 }
-
-### To expose Cosmos API server
-server {
-  server_name "<api.nyx.yourdomain.tld>";
-  location / {
-    proxy_pass http://127.0.0.1:1317;
-    proxy_set_header X-Forwarded-For $remote_addr;
-    proxy_set_header Host $http_host;
-    proxy_set_header Upgrade websocket;
-    proxy_set_header Connection Upgrade;
-  }
-}
-
-### To expose GRPC endpoint
-server {
-  server_name "<grpc.nyx.yourdomain.tld>";
-  location / {
-    grpc_pass 127.0.0.1:9090;
-  }
-}
-```
-
-#### nym-api Configuration
-
-```sh
-### To expose nym-api webserver
-server {
-  listen 80;
-  listen [::]:80;
-  server_name "<nym-api.nyx.yourdomain.tld>";
-
-  location / {
-    proxy_pass http://127.0.0.1:8000;
-    proxy_set_header X-Real-IP $remote_addr;
-    proxy_set_header Host $host;
-    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-  }
-}
 ```
 
 Followed by:
 
 ```sh
 sudo apt install certbot nginx python3
-certbot --nginx -m <you@yourdomain.com> --agree-tos
+certbot --nginx -d nym-validator.yourdomain.com -m you@yourdomain.com --agree-tos --noninteractive --redirect
 ```
 
 ```admonish caution title=""
 If using a VPS running Ubuntu 20: replace `certbot nginx python3` with `python3-certbot-nginx`
 ```
 
-These commands will get you an https encrypted nginx proxy in front of the various endpoints.
+These commands will get you an https encrypted nginx proxy in front of the API.
 
 ### Configuring Prometheus metrics (optional)
 
@@ -834,3 +795,6 @@ All validator-specific port configuration can be found in `$HOME/.nymd/config/co
 | 1317         | REST API server endpoint             |
 | 26656        | Listen for incoming peer connections |
 | 26660        | Listen for Prometheus connections    |
+
+  
+  

documentation/operators/src/nodes/nym-api.md

@@ -1,48 +1,33 @@
 # Nym API Setup
 
-[//]: # (> The nym-api 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. You can build just the API with `cargo build --release --bin nym-api`.)
+[//]: # (> The Nym API 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. You can build just the API with `cargo build --release --bin nym-api`.)
+[//]: # ()
 
-> The `nym-api` binary will be released in the immediate future - we're releasing this document beforehand so that Validators have information as soon as possible and get an idea of what to expect. This doc will be expanded over time as we release the API binary itself as well as start enabling functionality.  
-> 
-> You can build the API with `cargo build --release --bin nym-api`.
+> The `nym-api` binary should be coming out in the next release - we're releasing this document beforehand so that Validators have information as soon as possible and get an idea of what to expect. This doc will be expanded over time as we release the API binary itself as well as start enabling functionality.  
 
 > Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets.
 
 ## What is the Nym API?
-The Nym API is a binary that will be operated by the Nyx validator set. This binary can be run in several different modes, and has two main bits of functionality:
-* network monitoring (calculating the routing score of Mixnet nodes)
+The Nym API is a binary that will be operated by the Nyx Blockchain Validator set. This binary can be run in several different modes, and has two main bits of functionality: 
+* network monitoring (calculating the routing score of Mixnet nodes) 
 * generation and validation of [zk-Nyms](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a), our implementation of the Coconut Selective Disclosure Credential Scheme.
 
-This is important for both the proper decentralisation of the network uptime calculation and, more pressingly, enabling the NymVPN to utilise privacy preserving payments.
+This is important for both the proper decentralisation of the network uptime calculation and, more pressingly, enabling the NymVPN to utilise privacy preserving payments. 
 
-The process of enabling these different aspects of the system will take time. At the moment, Nym API operators will only have to run the binary in a minimal 'caching' mode in order to get used to maintaining an additional process running alongside a full node.
+The process of enabling these different aspects of the system will take time. Operators of the Nym API binary for the moment will only have to run the binary in a minimal 'caching' mode in order to get used to maintaining an additional process running alongside their Validator. 
 
-```admonish warning
-It is highly recommended to run `nym-api` alongside a full node since you will be exposing HTTP port(s) to the Internet. We also observed degradation in p2p and block signing operations when `nym-api` was run alongside a signing validator.
-```
+### Rewards 
+Operators of Nym API instances will be rewarded for performing the extra work of taking part in credential generation. These rewards will be calculated **separately** from rewards for block production. 
 
-### Rewards
-Operators of Nym API will be rewarded for performing the extra work of taking part in credential generation. These rewards will be calculated **separately** from rewards for block production.
+Rewards for credential signing will be calculated hourly, with API operators receiving a proportional amount of the reward pool (333NYM per hour / 237600NYM per month) according to the % of credentials they have signed. 
 
-Rewards for credential signing will be calculated hourly, with API operators receiving a proportional amount of the reward pool (333NYM per hour / 237,600 NYM per month), proportional to the percentage of credentials they have signed.
-
-### (Coming Soon) Machine Specs
-We are working on load testing currently in order to get good specs for a full node + Nym API setup. Bear in mind that credential signing is primarily CPU-bound.
+### (Coming Soon) Machine Specs 
+We are working on load testing currently in order to get good specs for a Validator + Nym API setup. Bear in mind that credential signing is primarily CPU-bound. 
 
 ### (Coming Soon) Credential Generation
-Validators that take part in the DKG ceremony will become part of the 'quorum' generating and verifying zk-Nym credentials. These will initially be used for private proof of payment for NymVPN (see our blogposts [here](https://blog.nymtech.net/nymvpn-an-invitation-for-privacy-experts-and-enthusiasts-63644139d09d) and [here](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a) for more on this), and in the future will be expanded into more general usecases such as [offline ecash](https://arxiv.org/abs/2303.08221). 
+Validators that take part in the DKG ceremony (more details on this soon) will become part of the quorum generating and verifying zk-Nym credentials. These will initially be used for private proof of payment for NymVPN (see our blogposts [here](https://blog.nymtech.net/nymvpn-an-invitation-for-privacy-experts-and-enthusiasts-63644139d09d) and [here](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a) for more on this), and in the future will be expanded into more general usecases such as [offline ecash](https://arxiv.org/abs/2303.08221). 
 
-The DKG ceremony will be used to create a subset of existing validators - referred to as the quorum. As outlined above, they will be the ones taking part in the generation and verification of zk-Nym credentials. The size of the 'minimum viable quorum' is 10 - we are aiming for a larger number than this for the initial quorum in order to have some redundancy in the case of a Validator dropping or going offline. 
-
-We will be releasing more detailed step-by-step documentation for involved validators nearer to the ceremony itself, but at a high level it will involve:
-* the deployment and initialisation of [`group`](https://github.com/nymtech/nym/tree/develop/contracts/multisig/cw4-group) and [`multisig`](https://github.com/nymtech/nym/tree/develop/contracts/multisig) contracts by Nym. Validators that are members of the `group` contract are the only ones that will be able to take part in the ceremony. 
-* the deployment and initialisation of an instance of the [DKG contract](https://github.com/nymtech/nym/tree/develop/contracts/coconut-dkg) by Nym.  
-* Validators will update their `nym-api` configs with the address of the deployed contracts. They will also stop running their API instance in caching only mode, instead switching over run with the `--enabled-credentials-mode`.
-* From the perspective of operators, this is all they have to do. Under the hood, each `nym-api` instance will then take part in several rounds of key submission, verification, and derivation. This will continue until quorum is acheived. More information on this will be released closer to the time of the ceremony. 
-
-**We will be communicating individually with members of the existing Validator set who have expressed interest in joining the quorum concerning the timing and specifics of the ceremony**. 
-
-## Current version 
+## Current version
 ```
 <!-- cmdrun ../../../../target/release/nym-api --version | grep "Build Version" | cut -b 21-26  -->
 ```
@@ -69,31 +54,31 @@ You can also check the various arguments required for individual commands with:
 ./nym-api <COMMAND> --help
 ```
 
-### Initialising your Nym API Instance
-Initialise your API instance with:
+### Initialising your Nym API Instance 
+Initialise your API instance with: 
 
 ```
 ./nym-api init
 ```
 
-You can optionally pass a local identifier for this instance with the `--id` flag. Otherwise the ID of your instance defaults to `default`.
+You can optionally pass a local identifier for this instance with the `--id` flag. Otherwise the ID of your instance defaults to `default`. 
 
-### Running your Nym API Instance
-The API binary currently defaults to running in caching mode. You can run your API with:
+### Running your Nym API Instance 
+The API binary currently defaults to running in caching mode. You can run your API with: 
 
 ```
 ./nym-api run
 ```
 
-By default the API will be trying to query a running `nyxd` process (either a validator or RPC node) on `localhost:26657`. This value can be modified either via the `--nyxd-validator ` flag on `run`:
+By default the API will be trying to query a running `nyxd` process (either a validator or RPC node) on `localhost:26657`. This value can be modified either via the `--nyxd-validator ` flag on `run`: 
 
 ```
-./nym-api run --nyxd-validator https://rpc.nymtech.net:443
+./nym-api run --nyxd-validator https://rpc.nymtech.net:443 
 ```
 
 > You can also change the value of `local_validator` in the config file found by default in `$HOME/.nym/nym-api/<ID>/config/config.toml`.
 
-This process is quite noisy, but informative:
+This process is quite noisy, but informative: 
 
 ~~~admonish example collapsible=true title="Console output"
 ```
@@ -175,8 +160,5 @@ Starting nym api...
 ```
 ~~~
 
-## Automation
+## Automation 
 You will most likely want to automate your validator restarting if your server reboots. Checkout the [maintenance page](./maintenance.md) for an example `service` file.
-
-## Exposing web endpoint using HTTPS
-It is recommended to expose the webserver over HTTPS by using a webserver like Nginx. An example configuration for configuring Nginx is listed [on the maintenance page](maintenance.md#nym-api-configuration)

documentation/operators/src/nodes/validator-setup.md

@@ -216,7 +216,7 @@ You can use the following command to download them for the correct network:
 wget  -O $HOME/.nyxd/config/genesis.json https://nymtech.net/genesis/genesis.json
 
 # Sandbox testnet
-curl https://rpc.sandbox.nymtech.net/snapshots/genesis.json | jq '.result.genesis' > $HOME/.nyxd/config/genesis.json
+wget -O $HOME/.nyxd/config/genesis.json https://rpc.sandbox.nymtech.net/snapshots/genesis.json | jq '.result.genesis'
 ```
 
 ### `config.toml` configuration
@@ -254,7 +254,7 @@ And if you wish to add a human-readable moniker to your node:
 Finally, if you plan on using [Cockpit](https://cockpit-project.org/documentation.html) on your server, change the `grpc` port from `9090` as this is the port used by Cockpit.
 
 ### `app.toml` configuration
-In the file `$HOME/.nyxd/config/app.toml`, set the following values:
+In the file `$HOME/nyxd/config/app.toml`, set the following values:
 
 ```
 # Mainnet
@@ -264,6 +264,7 @@ minimum-gas-prices = "0.025unym,0.025unyx"
 ```
 # Sandbox Testnet
 minimum-gas-prices = "0.025unym,0.025unyx"
+enable = true` in the `[api]` section to get the API server running
 ```
 
 ### Setting up your validator's admin user
@@ -303,31 +304,6 @@ File at /path/to/genesis.json is a valid genesis file
 
 > If this test did not pass, check that you have replaced the contents of `/<PATH-TO>/.nyxd/config/genesis.json` with that of the correct genesis file.
 
-### Setting up nyxd as full node (non-signing)
-
-```admonish danger title=""
-Skip this section if you're planning to run a validator node to join network consensus. To ensure security & maximum availability of validators, do not expose additional services to the Internet
-```
-
-Unlike signing validators, full nodes do not propose / sign blocks. A full node is typically used for indexing blocks produced on the chain and for exposing web interfaces such as RPC, API and gRPC endpoints required for external applications/services to interact with the blockchain.
-
-By default, API server is disabled and RPC/gRPC servers listen to the loopback address only. In a production setup, it is recommended to use a webserver such as Nginx or caddy to proxy requests to the endpoints as required.
-
-To enable Cosmos REST API, you can enable it in `$HOME/.nyxd/config/app.toml` like :
-
-```
-[api]
-
-# Enable defines if the API server should be enabled. Toggle this to `true`
-enable = true
-
-# Swagger defines if swagger documentation should automatically be registered.
-# You can also expose swagger documentation by toggling the below configuration to true
-swagger = true
-```
-
-For more information on enabling access to various endpoints via Nginx, refer to the [example configuration here](./maintenance.md#setup)
-
 ### Open firewall ports
 
 Before starting the validator, we will need to open the firewall ports:
@@ -343,9 +319,6 @@ sudo ufw enable
 # 22 : Default SSH port
 sudo ufw allow 26656,26660,22
 
-## !! FOR FULL NODES ONLY !! - exposing Nginx for serving web requests
-sudo ufw allow 80,443
-
 # to check everything worked
 sudo ufw status
 ```
@@ -385,8 +358,10 @@ lz4 -c -d nyxd-sandbox-snapshot-data.tar.lz4 | tar -x -C $HOME/.nyxd
 You can then restart `nyxd` - it should start syncing from a block > 2000000.
 
 ### Joining Consensus
-```admonish info title=""
-You can skip this section if you are planning to run a full-node. This step will make your node a signing validator which joins network consensus
+```admonish caution title=""
+When joining consensus, make sure that you do not disrupt (or worse - halt) the network by coming in with a disproportionately large amount of staked tokens.
+
+Please initially stake a small amount of tokens compared to existing validators, then delegate to yourself in tranches over time.
 ```
 
 Once your validator has synced and you have received tokens, you can join consensus and produce blocks.
@@ -498,15 +473,11 @@ To upgrade your validator, follow the steps on the [maintenance page](./maintena
 
 #### Common reasons for your validator being jailed
 
-Your validator will be jailed if your node:
- - misses _`x`_ amount of blocks in _`y`_ interval, where _`x`_ and _`y`_ are parameters set by chain governance
- - performs double signing (two conflicting signatures on the same block using the same key)
+The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.
 
-Double signing is a serious infraction. If a node double signs, all the delegators to the node (including self-delegation) will be slashed by 5%. Additionally, the node will be permanently jailed and removed from consensus (called _tombstoning_)
+Running the command `df -H` will return the size of the various partitions of your VPS.
 
-One of the most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.
-
-Running the command `df -H` will return the size of the various partitions of your VPS. If the partition with blockchain data is almost full, try pruning the blockchain data or expanding the storage size.
+If the `/dev/sda` partition is almost full, try pruning some of the `.gz` syslog archives and restart your validator process.
 
 ### Day 2 operations with your validator
 

mixnode/Cargo.toml

@@ -35,6 +35,7 @@ serde_json = { workspace = true }
 sysinfo = "0.27.7"
 tokio = { workspace = true, features = ["rt-multi-thread", "net", "signal"] }
 tokio-util = { workspace = true, features = ["codec"] }
+console-subscriber = { version = "0.2", optional = true }
 toml = "0.5.8"
 url = { workspace = true, features = ["serde"] }
 cfg-if = "1.0.0"
@@ -83,6 +84,9 @@ cpucycles = [
     "nym-bin-common/tracing",
 ]
 
+# build with RUSTFLAGS="--cfg tokio_unstable"
+tokio-console = ["console-subscriber", "tokio/tracing"]
+
 [package.metadata.deb]
 name = "nym-mixnode"
 maintainer-scripts = "debian"

mixnode/src/main.rs

@@ -4,7 +4,7 @@
 use ::nym_config::defaults::setup_env;
 use clap::{crate_name, crate_version, Parser};
 use lazy_static::lazy_static;
-use log::info;
+use log::{error, info};
 use nym_bin_common::bin_info;
 
 #[allow(unused_imports)]
@@ -53,6 +53,12 @@ fn test_function() {
 
 #[tokio::main]
 async fn main() -> anyhow::Result<()> {
+    cfg_if::cfg_if! {
+        if #[cfg(feature = "tokio-console")] {
+            console_subscriber::init();
+        }
+    }
+
     let args = Cli::parse();
     setup_env(args.config_env_file.as_ref());
 

nym-vpn/ui/src-tauri/src/commands/node_location.rs

@@ -1,10 +1,10 @@
+use once_cell::sync::Lazy;
 use serde::{Deserialize, Serialize};
 use tauri::State;
 use tracing::{debug, instrument};
 use ts_rs::TS;
 
 use crate::{
-    country::DEFAULT_NODE_LOCATION,
     error::{CmdError, CmdErrorSource},
     states::{app::Country, SharedAppData, SharedAppState},
 };
@@ -15,6 +15,11 @@ pub enum NodeType {
     Exit,
 }
 
+static DEFAULT_NODE_LOCATION: Lazy<Country> = Lazy::new(|| Country {
+    code: "DE".to_string(),
+    name: "Germany".to_string(),
+});
+
 #[instrument(skip(app_state, data_state))]
 #[tauri::command]
 pub async fn set_node_location(

nym-vpn/ui/src-tauri/src/country.rs

@@ -6,29 +6,20 @@ use crate::states::app::Country;
 pub static COUNTRIES: Lazy<Vec<Country>> = Lazy::new(|| {
     vec![
         Country {
-            name: "France".to_string(),
-            code: "FR".to_string(),
+            name: "Ireland".to_string(),
+            code: "IE".to_string(),
         },
         Country {
             name: "Germany".to_string(),
             code: "DE".to_string(),
         },
-        Country {
-            name: "Ireland".to_string(),
-            code: "IE".to_string(),
-        },
         Country {
             name: "Japan".to_string(),
             code: "JP".to_string(),
         },
         Country {
-            name: "United Kingdom".to_string(),
+            name: "Great Britain".to_string(),
             code: "GB".to_string(),
         },
     ]
 });
-
-pub static DEFAULT_NODE_LOCATION: Lazy<Country> = Lazy::new(|| Country {
-    code: "FR".to_string(),
-    name: "France".to_string(),
-});

nym-vpn/ui/src/pages/location/QuickConnect.tsx

@@ -20,7 +20,7 @@ export default function QuickConnect({ onClick }: QuickConnectProps) {
       }
     >
       <span className="font-icon text-2xl px-4 cursor-pointer">bolt</span>
-      <div className="cursor-pointer">{`${QuickConnectPrefix} (${defaultNodeLocation.name})`}</div>
+      <div className="cursor-pointer">{`${QuickConnectPrefix} ${defaultNodeLocation.name}`}</div>
     </div>
   );
 }

nym-vpn/ui/src/ui/TopBar.tsx

@@ -1,7 +1,7 @@
 import { useEffect, useMemo, useState } from 'react';
 import { useLocation, useNavigate } from 'react-router-dom';
 import { useTranslation } from 'react-i18next';
-import { routes } from '../constants';
+import { AppName, routes } from '../constants';
 import { Routes } from '../types';
 
 type NavLocation = {
@@ -22,7 +22,7 @@ export default function TopBar() {
   const { t } = useTranslation();
 
   const [currentNavLocation, setCurrentNavLocation] = useState<NavLocation>({
-    title: '',
+    title: AppName,
     rightIcon: 'settings',
     handleRightNav: () => {
       navigate(routes.settings);
@@ -32,7 +32,7 @@ export default function TopBar() {
   const navBarData = useMemo<NavBarData>(() => {
     return {
       '/': {
-        title: '',
+        title: AppName,
         rightIcon: 'settings',
         handleRightNav: () => {
           navigate(routes.settings);