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

temp commit

Browse Source
This commit is contained in:
mx
2023-04-13 09:51:53 +02:00
committed by Jon Häggblad
parent 974ac0691c
commit 9bbe4a96d0
5 changed files with 91 additions and 410 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/docs/src/clients/socks5-client.md
+14 -58
View File
@@ -67,46 +67,11 @@ You can check that your binaries are properly compiled with:
./nym-socks5-client --help
```
```admonish example collapsible=true title="Console output"
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(socks5 proxy - version {{platform_release_version}})
nym-socks5-client {{platform_release_version}}
Nymtech
A SOCKS5 localhost proxy that converts incoming messages to Sphinx and sends them to a Nym address
USAGE:
nym-socks5-client [OPTIONS] <SUBCOMMAND>
OPTIONS:
--config-env-file <CONFIG_ENV_FILE>
Path pointing to an env file that configures the client
-h, --help
Print help information
-V, --version
Print version information
SUBCOMMANDS:
completions Generate shell completions
generate-fig-spec Generate Fig specification
help Print this message or the help of the given subcommand(s)
init Initialise a Nym client. Do this first!
run Run the Nym client with provided configuration client optionally
overriding set parameters
upgrade Try to upgrade the client
~~~admonish example collapsible=true title="Console output"
```
# <!-- cmdrun ../../../../target/release/nym-socks5-client --help -->
```
~~~
You can check the necessary parameters for the available commands by running:
@@ -115,14 +80,19 @@ You can check the necessary parameters for the available commands by running:
```
### Initialising a new client instance
Before you can use the client, you need to initalise a new instance of it, which can be done with the following command:
```
./nym-socks5-client init --id <id> --provider <provider>
./nym-socks5-client init --id docs-example --provider Entztfv6Uaz2hpYHQJ6JKoaCTpDL5dja18SuQWVJAmmx.Cvhn9rBJw5Ay9wgHcbgCnVg89MPSV5s2muPV2YF1BXYu@Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf
```
The `--id` in the example above is a local identifier so that you can name your clients; it is **never** transmitted over the network.
~~~admonish example collapsible=true title="Console output"
```
# <!-- cmdrun ../../../../target/release/nym-socks5-client init --id docs-example --provider Entztfv6Uaz2hpYHQJ6JKoaCTpDL5dja18SuQWVJAmmx.Cvhn9rBJw5Ay9wgHcbgCnVg89MPSV5s2muPV2YF1BXYu@Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf -->
```
~~~
The `--id` in the example above is a local identifier so that you can name your clients and keep track of them on your local system; it is **never** transmitted over the network.
The `--provider` field needs to be filled with the Nym address of a Network Requester that can make network requests on your behalf. If you don't want to [run your own](../nodes/network-requester-setup.md) you can select one from the [mixnet explorer](https://explorer.nymtech.net/network-components/service-providers) by copying its `Client ID` and using this as the value of the `--provider` flag. Alternatively, you could use [this list](https://harbourmaster.nymtech.net/).
@@ -145,27 +115,13 @@ However, there are several options for choosing a gateway, if you do not want on
You can run the initalised client by doing this:
```
./nym-socks5-client run --id <id>
./nym-socks5-client run --id docs-example
```
~~~admonish example collapsible=true title="Console output"
```
2022-04-27T16:15:45.843Z INFO nym_socks5_client::client > Starting nym client
2022-04-27T16:15:45.889Z INFO nym_socks5_client::client > Obtaining initial network topology
2022-04-27T16:15:51.470Z INFO nym_socks5_client::client > Starting topology refresher...
2022-04-27T16:15:51.470Z INFO nym_socks5_client::client > Starting received messages buffer controller...
2022-04-27T16:15:51.648Z INFO gateway_client::client > Claiming more bandwidth for your tokens. This will use 1 token(s) from your wallet. Stop the process now if you don't want that to happen.
2022-04-27T16:15:51.648Z WARN gateway_client::client > Not enough bandwidth. Trying to get more bandwidth, this might take a while
2022-04-27T16:15:51.648Z INFO gateway_client::client > The client is running in disabled credentials mode - attempting to claim bandwidth without a credential
2022-04-27T16:15:51.706Z INFO nym_socks5_client::client > Starting mix traffic controller...
2022-04-27T16:15:51.706Z INFO nym_socks5_client::client > Starting real traffic stream...
2022-04-27T16:15:51.706Z INFO nym_socks5_client::client > Starting loop cover traffic stream...
2022-04-27T16:15:51.707Z INFO nym_socks5_client::client > Starting socks5 listener...
2022-04-27T16:15:51.707Z INFO nym_socks5_client::socks::server > Listening on 127.0.0.1:1080
2022-04-27T16:15:51.707Z INFO nym_socks5_client::client> Client startup finished!
2022-04-27T16:15:51.707Z INFO nym_socks5_client::client> The address of this client is: BFKhbyNsSVwbsGSLwHDkfwH5mwZqZYpnpNjjV7Xo25Xc.EFWd1geWspzyVeinwXrY5fCBMRtAKV1QmK1CNFhAA8VG@BNjYZPxzcJwczXHHgBxCAyVJKxN6LPteDRrKapxWmexv
2022-04-27T16:15:51.707Z INFO nym_socks5_client::socks::server > Serving Connections...
# <!-- cmdrun ../../../../target/release/nym-socks5-client run --id docs-example -->
```
~~~
documentation/docs/src/clients/websocket-client.md
+34 -37
View File
@@ -1,12 +1,10 @@
# Websocket Client
# Websocket Client
> The Nym Websocket Client was built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code on this page, go there first.
## Client setup
## Client setup
### Viewing command help
You can check that your binaries are properly compiled with:
```
@@ -24,7 +22,7 @@ You can check that your binaries are properly compiled with:
(client - version {{platform_release_version}})
nym-client {{platform_release_version}}
Nymtech
Implementation of the Nym Client
@@ -55,25 +53,25 @@ You can check that your binaries are properly compiled with:
```
~~~
The two most important commands you will issue to the client are:
The two most important commands you will issue to the client are:
* `init` - initalise a new client instance.
* `run` - run a mixnet client process.
* `init` - initalise a new client instance.
* `run` - run a mixnet client process.
You can check the necessary parameters for the available commands by running:
```
./nym-client <command> --help
./nym-client <command> --help
```
### Initialising your client
### Initialising your client
Before you can use the client, you need to initalise a new instance of it. Each instance of the client has its own public/private keypair, and connects to its own gateway node. Taken together, these 3 things (public/private keypair + gateway node identity key) make up an app's identity.
Initialising a new client instance can be done with the following command:
```
./nym-client init --id <client_id>
./nym-client init --id <client_id>
```
~~~admonish example collapsible=true title="Console output"
@@ -94,23 +92,23 @@ Initialising a new client instance can be done with the following command:
The `--id` in the example above is a local identifier so that you can name your clients; it is **never** transmitted over the network.
There is an optional `--gateway` flag that you can use if you want to use a specific gateway. The supplied argument is the `Identity Key` of the gateway you wish to use, which can be found on the [mainnet Network Explorer](https://explorer.nymtech.net/network-components/gateways) or [Sandbox Testnet Explorer](https://sandbox-explorer.nymtech.net/network-components/gateways) depending on which network you are on.
There is an optional `--gateway` flag that you can use if you want to use a specific gateway. The supplied argument is the `Identity Key` of the gateway you wish to use, which can be found on the [mainnet Network Explorer](https://explorer.nymtech.net/network-components/gateways) or [Sandbox Testnet Explorer](https://sandbox-explorer.nymtech.net/network-components/gateways) depending on which network you are on.
Not passing this argument will randomly select a gateway for your client.
#### Choosing a Gateway
By default - as in the example above - your client will choose a random gateway to connect to.
#### Choosing a Gateway
By default - as in the example above - your client will choose a random gateway to connect to.
However, there are several options for choosing a gateway, if you do not want one that is randomly assigned to your client:
* If you wish to connect to a specific gateway, you can specify this with the `--gateway` flag when running `init`.
* You can also choose a gateway based on its location relative to your client. This can be done by appending the `--latency-based-routing` flag to your `init` command. This command means that to select a gateway, your client will:
* If you wish to connect to a specific gateway, you can specify this with the `--gateway` flag when running `init`.
* You can also choose a gateway based on its location relative to your client. This can be done by appending the `--latency-based-routing` flag to your `init` command. This command means that to select a gateway, your client will:
* fetch a list of all availiable gateways
* send few ping messages to all of them, and measure response times.
* create a weighted distribution to randomly choose one, favouring ones with lower latency.
* send few ping messages to all of them, and measure response times.
* create a weighted distribution to randomly choose one, favouring ones with lower latency.
> Note this doesn't mean that your client will pick the closest gateway to you, but it will be far more likely to connect to gateway with a 20ms ping rather than 200ms
### Configuring your client
### Configuring your client
When you initalise a client instance, a configuration directory will be generated and stored in `$HOME_DIR/.nym/clients/<client-name>/`.
```
@@ -126,12 +124,12 @@ The `config.toml` file contains client configuration options, while the two `pem
The generated files contain the client name, public/private keypairs, and gateway address. The name `<client_id>` in the example above is just a local identifier so that you can name your clients.
#### Configuring your client for Docker
By default, the native client listens to host `127.0.0.1`. However this can be an issue if you wish to run a client in a Dockerized environment, where it can be convenenient to listen on a different host such as `0.0.0.0`.
#### Configuring your client for Docker
By default, the native client listens to host `127.0.0.1`. However this can be an issue if you wish to run a client in a Dockerized environment, where it can be convenenient to listen on a different host such as `0.0.0.0`.
You can set this via the `--host` flag during either the `init` or `run` commands.
You can set this via the `--host` flag during either the `init` or `run` commands.
Alternatively, a custom host can be set in the `config.toml` file under the `socket` section. If you do this, remember to restart your client process.
Alternatively, a custom host can be set in the `config.toml` file under the `socket` section. If you do this, remember to restart your client process.
### Running your client
@@ -145,16 +143,16 @@ When you run the client, it immediately starts generating (fake) cover traffic a
When the client is first started, it will reach out to the Nym network's validators, and get a list of available Nym nodes (gateways, mixnodes, and validators). We call this list of nodes the network _topology_. The client does this so that it knows how to connect, register itself with the network, and know which mixnodes it can route Sphinx packets through.
## Using your client
## Using your client
### Connecting to the local websocket
The Nym native client exposes a websocket interface that your code connects to. To program your app, choose a websocket library for whatever language you're using. The **default** websocket port is `1977`, you can override that in the client config if you want.
The Nym monorepo includes websocket client example code for Rust, Go, Javacript, and Python, all of which can be found [here](https://github.com/nymtech/nym/tree/release/{{platform_release_version}}/clients/native/examples)
> Rust users can run the examples with `cargo run --example <rust_file>.rs`, as the examples are not organised in the same way as the other examples, due to already being inside a Cargo project.
> Rust users can run the examples with `cargo run --example <rust_file>.rs`, as the examples are not organised in the same way as the other examples, due to already being inside a Cargo project.
All of these code examples will do the following:
All of these code examples will do the following:
* connect to a running websocket client on port `1977`
* format a message to send in either JSON or Binary format. Nym messages have defined JSON formats.
* send the message into the websocket. The native client packages the message into a Sphinx packet and sends it to the mixnet
@@ -163,7 +161,7 @@ All of these code examples will do the following:
By varying the message content, you can easily build sophisticated service provider apps. For example, instead of printing the response received from the mixnet, your service provider might take some action on behalf of the user - perhaps initiating a network request, a blockchain transaction, or writing to a local data store.
> You can find an example of building both frontend and service provider code with the websocket client in the [Simple Service Provider Tutorial](https://nymtech.net/developers/tutorials/simple-service-provider.html) in the Developer Portal.
> You can find an example of building both frontend and service provider code with the websocket client in the [Simple Service Provider Tutorial](https://nymtech.net/developers/tutorials/simple-service-provider.html) in the Developer Portal.
### Message Types
There are a small number of messages that your application sends up the websocket to interact with the native client, as follows.
@@ -192,15 +190,15 @@ In some applications, e.g. where people are chatting with friends who they know,
}
```
If that fits your security model, good. However, it may be the case that you want to send **anonymous replies using Single Use Reply Blocks (SURBs)**.
If that fits your security model, good. However, it may be the case that you want to send **anonymous replies using Single Use Reply Blocks (SURBs)**.
You can read more about SURBs [here](../architecture/traffic-flow.md#private-replies-using-surbs) but in short they are ways for the receiver of this message to anonymously reply to you - the sender - without them having to know your nym address.
You can read more about SURBs [here](../architecture/traffic-flow.md#private-replies-using-surbs) but in short they are ways for the receiver of this message to anonymously reply to you - the sender - without them having to know your nym address.
Your client will send along a number of `replySurbs` to the recipient of the message. These are pre-addressed Sphinx packets that the recipient can write to, but not view the address. If the recipient is unable to fit the response data into the bucket of SURBs sent to it, it will use a SURB to request more SURBs be sent to it.
Your client will send along a number of `replySurbs` to the recipient of the message. These are pre-addressed Sphinx packets that the recipient can write to, but not view the address. If the recipient is unable to fit the response data into the bucket of SURBs sent to it, it will use a SURB to request more SURBs be sent to it.
```json
{
"type": "sendAnonymous",
"type": "sendAnonymous",
"message": "something you want to keep secret"
"recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm"
"replySurbs": 100 // however many reply SURBs to send along with your message
@@ -211,8 +209,8 @@ Each bucket of replySURBs, when received as part of an incoming message, has a u
```json
{
"type": "reply",
"message": "reply you also want to keep secret",
"type": "reply",
"message": "reply you also want to keep secret",
"senderTag": "the sender tag you parsed from the incoming message"
}
```
@@ -220,9 +218,9 @@ Each bucket of replySURBs, when received as part of an incoming message, has a u
#### Sending binary data
You can also send bytes instead of JSON. For that you have to send a binary websocket frame containing a binary encoded
Nym [`ClientRequest`](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs#L25) containing the same information.
Nym [`ClientRequest`](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs#L25) containing the same information.
As a response the `native-client` will send a `ServerResponse` to be decoded.
As a response the `native-client` will send a `ServerResponse` to be decoded.
You can find examples of sending and receiving binary data in the Rust, Python and Go [code examples](https://github.com/nymtech/nym/tree/release/{{platform_release_version}}/clients/native/examples), and an example project from the Nym community [BTC-BC](https://github.com/sgeisler/btcbc-rs/): Bitcoin transaction transmission via Nym, a client and service provider written in Rust.
@@ -253,4 +251,3 @@ Errors from the app's client, or from the gateway, will be sent down the websock
"message": "string message"
}
```
documentation/docs/src/nodes/gateway-setup.md
+9 -24
View File
@@ -31,7 +31,6 @@ We currently have these _rough_ specs for VPS hardware:
- RAM: Memory requirements depend on the amount of users your Gateway will be serving at any one time. If you're just going to be using it yourself, then minimal RAM is fine. **If you're running your Gateway as part of a Service Grant, get something with at least 4GB RAM.**
- Disks: much like the amount of RAM your Gateway could use, the amount of disk space required will vary with the amount of users your Gateway is serving. **If you're running your Gateway as part of a Service Grant, get something with at least 40GB storage.**
## Gateway setup
Now that you have built the codebase, set up your wallet, and have a VPS with the `nym-gateway` binary, you can set up your gateway with the instructions below.
@@ -70,9 +69,15 @@ To check available configuration options use:
The following command returns a gateway on your current IP with the `id` of `supergateway`:
```
./nym-gateway init --id supergateway --host $(curl ifconfig.me) --wallet-address <WALLET_ADDRESS> --enabled-statistics true
./nym-gateway init --id supergateway --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq
```
~~~admonish example collapsible=true title="Console output"
```
<!-- cmdrun ../../../../target/release/nym-gateway init --id supergateway --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq -->
```
~~~
The `$(curl ifconfig.me)` command above returns your IP automatically using an external service. Alternatively, you can enter your IP manually wish. If you do this, remember to enter your IP **without** any port information.
### Bonding your gateway
@@ -94,7 +99,7 @@ You can bond your gateway via the Desktop wallet.
|_| |_|\__, |_| |_| |_|
|___/
(nym-gateway - version 1.1.13)
(nym-gateway - version {{platform_release_version}})
>>> attempting to sign 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a
@@ -129,28 +134,8 @@ The `run` command starts the gateway:
```
~~~admonish example collapsible=true title="Console output"
```
Starting gateway supergateway...
To bond your gateway you will need to install the Nym wallet, go to https://nymtech.net/get-involved and select the Download button.
Select the correct version and install it to your machine. You will need to provide the following:
Identity Key: 6jWSJZsQ888jwzi1CBfkHefiDdUEjgwfeMfJU4RNhDuk
Sphinx Key: HbqYJwjmtzDi4WzGp7ehj8Ns394sRvJnxtanX28upon
Host: 62.240.134.46 (bind address: 62.240.134.46)
Version: 1.1.
Mix Port: 1789, Clients port: 9000
Data store is at: "/home/mx/.nym/gateways/supergateway/data/db.sqlite"
2022-04-27T16:04:33.831Z INFO nym_gateway::node > Starting nym gateway!
2022-04-27T16:04:34.268Z INFO nym_gateway::node > Starting mix packet forwarder...
2022-04-27T16:04:34.269Z INFO nym_gateway::node > Starting mix socket listener...
2022-04-27T16:04:34.269Z INFO nym_gateway::node::mixnet_handling::receiver::listener > Running mix listener on "62.240.134.46:1789"
2022-04-27T16:04:34.269Z INFO nym_gateway::node
> Starting client [web]socket listener...
2022-04-27T16:04:34.269Z INFO nym_gateway::node > Finished nym gateway startup procedure - it should now be able to receive mix and client traffic!
<!-- cmdrun ../../../../target/release/nym-gateway run --id supergateway -->
```
~~~
documentation/docs/src/nodes/mix-node-setup.md
+15 -158
View File
@@ -57,45 +57,7 @@ Which should return a list of all avaliable commands.
~~~admonish example collapsible=true title="Console output"
```
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(mixnode - version {{mix_node_release_version}})
nym-mixnode {{mix_node_release_version}}
Nymtech
Implementation of a Loopix-based Mixnode
USAGE:
nym-mixnode [OPTIONS] <SUBCOMMAND>
OPTIONS:
--config-env-file <CONFIG_ENV_FILE>
Path pointing to an env file that configures the mixnode
-h, --help
Print help information
-V, --version
Print version information
SUBCOMMANDS:
completions Generate shell completions
describe Describe your mixnode and tell people why they should delegate state to you
generate-fig-spec Generate Fig specification
help Print this message or the help of the given subcommand(s)
init Initialise the mixnode
node-details Show details of this mixnode
run Starts the mixnode
sign Sign text to prove ownership of this mixnode
upgrade Try to upgrade the mixnode
nym-mixnode {{mix_node_release_version}}
Nymtech
<!-- cmdrun ../../../../target/release/nym-mixnode --help -->
```
~~~
@@ -115,58 +77,22 @@ To check available configuration options for initializing your node use:
~~~admonish example collapsible=true title="Console output"
```
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(mixnode - version {{mix_node_release_version}})
nym-mixnode-init
Initialise the mixnode
USAGE:
nym-mixnode init [OPTIONS] --id <ID> --host <HOST> --wallet-address <WALLET_ADDRESS>
OPTIONS:
--announce-host <ANNOUNCE_HOST>
The custom host that will be reported to the directory server
-h, --help
Print help information
--host <HOST>
The host on which the mixnode will be running
--http-api-port <HTTP_API_PORT>
The port on which the mixnode will be listening for http requests
--id <ID>
Id of the mixnode we want to create config for
--mix-port <MIX_PORT>
The port on which the mixnode will be listening for mix packets
--validators <VALIDATORS>
Comma separated list of rest endpoints of the validators
--verloc-port <VERLOC_PORT>
The port on which the mixnode will be listening for verloc packets
--wallet-address <WALLET_ADDRESS>
The wallet address you will use to bond this mixnode, e.g.
nymt1z9egw0knv47nmur0p8vk4rcx59h9gg4zuxrrr9
<!-- cmdrun ../../../../target/release/nym-mixnode init --help -->
```
~~~
Initalise your mixnode with the following command, replacing the value of `--id` with the moniker you wish to give your mixnode, and the `--wallet-address` with the Nym address you created earlier. Your `--host` must be publicly routable on the internet in order to mix packets, and can be either an Ipv4 or IPv6 address. The `$(curl ifconfig.me)` command returns your IP automatically using an external service. If you enter your IP address manually, enter it **without** any port information.
```
./nym-mixnode init --id winston-smithnode --host $(curl ifconfig.me) --wallet-address <wallet-address>
./nym-mixnode init --id winston-smithnode --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq
```
~~~admonish example collapsible=true title="Console output"
```
<!-- cmdrun ../../../../target/release/nym-mixnode init --id winston-smithnode --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq -->
```
~~~
> The `init` command will refuse to destroy existing mix node keys.
During the `init` process you will have the option to change the `http_api`, `verloc` and `mixnode` ports from their default settings. If you wish to change these in the future you can edit their values in the `config.toml` file created by the initialization process, which is located at `~/.nym/mixnodes/<your-id>/`.
@@ -233,27 +159,7 @@ Now you've bonded your mix node, run it with:
~~~admonish example collapsible=true title="Console output"
```
Starting mixnode winston-smithnode...
To bond your mixnode you will need to install the Nym wallet, go to https://nymtech.net/get-involved and select the Download button.
Select the correct version and install it to your machine. You will need to provide the following:
Identity Key: GWrymUuLaxVHSs8iE7YW48MB81npnKjrVuJzJsGkeji6
Sphinx Key: FU89ULkS4YYDXcm5jShhJvoit7H4jG4EXHxRKbS9cXSJ
Host: 62.240.134.46 (bind address: 62.240.134.46)
Version: {{mix_node_release_version}}
Mix Port: 1789, Verloc port: 1790, Http Port: 8000
You are bonding to wallet address: n1x42mm3gsdg808qu2n3ah4l4r9y7vfdvwkw8az6
2022-04-27T16:08:01.159Z INFO nym_mixnode::node > Starting nym mixnode
2022-04-27T16:08:01.490Z INFO nym_mixnode::node > Starting node stats controller...
2022-04-27T16:08:01.490Z INFO nym_mixnode::node > Starting packet delay-forwarder...
2022-04-27T16:08:01.490Z INFO nym_mixnode::node > Starting socket listener...
2022-04-27T16:08:01.490Z INFO nym_mixnode::node::listener > Running mix listener on "62.240.134.46:1789"
2022-04-27T16:08:01.490Z INFO nym_mixnode::node > Starting the round-trip-time measurer...
<!-- cmdrun ../../../../target/release/nym-mixnode run --id winston-smithnode -->
```
~~~
@@ -273,18 +179,7 @@ In order to easily identify your node via human-readable information later on in
./nym-mixnode describe --id winston-smithnode
```
~~~admonish example collapsible=true title="Console output"
```
name: winston-smithnode
description: nym-mixnode hosted on Linode VPS in <location> with the following specs: <specs>.
link, e.g. https://mixnode.yourdomain.com: mixnode.mydomain.net
location, e.g. City: London, Country: UK: <your_location>
This information will be shown in the mixnode's page in the Network Explorer, and help people make delegated staking decisions.
```
~~~
> Remember to restart your mix node process in order for the new description to be propogated
> Remember to restart your mix node process in order for the new description to be propogated.
### Upgrading your mix node
@@ -324,20 +219,6 @@ You can always check the details of your mix node with the `node-details` comman
./nym-mixnode node-details --id winston-smithnode
```
~~~admonish example collapsible=true title="Console output"
```
Identity Key: GWrymUuLaxVHSs8iE7YW48MB81npnKjrVuJzJsGkeji6
Sphinx Key: FU89ULkS4YYDXcm5jShhJvoit7H4jG4EXHxRKbS9cXSJ
Host: 62.240.134.46 (bind address: 62.240.134.46)
Version: {{mix_node_release_version}}
Mix Port: 1789, Verloc port: 1790, Http Port: 8000
You are bonding to wallet address: n1x42mm3gsdg808qu2n3ah4l4r9y7vfdvwkw8az6
```
~~~
## VPS Setup and Automation
### Configure your firewall
The following commands will allow you to set up a firewall using `ufw`.
@@ -499,20 +380,7 @@ You can use either `nym-cli` which can be downloaded from the [release page](htt
~~~admonish example collapsible=true title="Console output"
```
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(nym-mixnode - version {{mix_node_release_version}})
Signing the text "APxUbCmGp4K9qDzvwVADJFNu8S3JV1AJBw7q6bS5KN9E" using your mixnode's Ed25519 identity key...
The base58-encoded signature on 'APxUbCmGp4K9qDzvwVADJFNu8S3JV1AJBw7q6bS5KN9E' is: 2ZuCFYU91pvEcgAj6EzU33oozazvsRAoxP7NQHFM6Xy6AkJrzgCZdnsnZYAmxFtqe8Su17KXwpTHQtkVmAnAiV4H
<!-- cmdrun ../../../../target/release/nym-mixnode sign --id winston-smithnode --text "the text to sign" -->
```
~~~
@@ -545,17 +413,9 @@ To get the node owner signature, use:
```
~~~admonish example collapsible=true title="Console output"
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(nym-mixnode - version {{mix_node_release_version}})
Signing the text "4yRfauFzZnejJhG2FACTVQ7UnYEcFUYw3HzXrmuwLMaR" using your mixnode's Ed25519 identity key...
The base58-encoded signature on '4yRfauFzZnejJhG2FACTVQ7UnYEcFUYw3HzXrmuwLMaR' is: 4By7EQEMM8BAt6ptxJyeGqpoxHWxeRUhyJ4wMr2x3mXSQD9nvttkvd7tgP1uKu2ktJjB2bLzD1oaZ33d2Wv5eYWp
```
<!-- cmdrun ../../../../target/release/nym-mixnode sign --id winston-smithnode --text "the text to sign" -->
```
~~~
Using `nym-cli`:
@@ -591,10 +451,7 @@ Using `nyxd`:
./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "<base58-encoded-signature>","family_head": "<text>"}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block
```
## Checking that your node is mixing correctly
### Network explorers
Once you've started your mix node and it connects to the validator, your node will automatically show up in the 'Mix nodes' section of either the Nym Network Explorers:
documentation/docs/src/nodes/network-requester-setup.md
+19 -133
View File
@@ -5,6 +5,7 @@
If you have access to a server, you can run the network requester, which allows Nym users to send outbound requests from their local machine through the mixnet to a server, which then makes the request on their behalf, shielding them (and their metadata) from clearnet, untrusted and unknown infrastructure, such as email or message client servers.
> As of `v1.1.10`, the network requester longer requires a separate nym client instance for it to function, as it has a client embedded within the binary running as a single process.
>
## Network Requester Whitelist
The network requester is **not** an open proxy. It uses a file called `allowed.list` (located in `~/.nym/service-providers/network-requester/<network-requester-id>/`) as a whitelist for outbound requests.
@@ -18,6 +19,8 @@ This default whitelist is useful for knowing that the majority of network reques
The domains and IPs on the default whitelist can be broken down by application as follows:
# TODO pull this in from monorepo
```
# Keybase
keybaseapi.com
@@ -64,14 +67,11 @@ p2pify.com
## Network Requester Directory
You can find a list of Network Requesters running the default whitelist [here](https://explorer.nymtech.net/network-components/service-providers). This list comprises of the NRs running as infrastructure for NymConnect.
> We are currently working on a smart-contract based solution more in line with how Mix nodes and Gateways annouce themselves to the network.
> We are currently working on a smart-contract based solution more in line with how Mix nodes and Gateways announce themselves to the network.
## Initializing and running your network requester (standard mode)
## Initializing and running your network requester
```admonish caution
If you are following these instructions to set up a requester as part of a Service Grant, **ignore these instructions and jump to the step [below](./network-requester-setup.md#running-your-network-requester-stats-mode)**
```
The network-requester needs to be initialized before it can be run. This is required for the embedded nym-client to connect successfully to the mixnet. We want to specify an `id` using the `--id` command and give it a value of your choosing. The following command will achieve that:
```
@@ -84,131 +84,33 @@ Now that we have initialized our network-requester, we can start it with the fol
./nym-network-requester run --id example
```
Expected output:
~~~admonish example collapsible=true title="Console output"
```
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(nym-network-requester - version {{platform_release_version}})
Initialising client...
Registering with new gateway
2023-02-23T11:56:42.370Z INFO gateway_client::client > the gateway is using exactly the same protocol version as we are. We're good to continue!
2023-02-23T11:56:42.375Z INFO config > Configuration file will be saved to "/Users/myusername/.nym/service-providers/network-requester/example/config/config.toml"
Saved configuration file to "/Users/myusername/.nym/service-providers/network-requester/example/config/config.toml"
Using gateway: 3zd3wrCK8Dz5TXrcvk5dG5s9EEdf4Ck1v9VgBPMMFVkR
Client configuration completed.
Version: {{platform_release_version}}
ID: example
Identity key: 3wqJJb1Xj9876KBPnGuSZnN5pCWH6id6wkzS2tL6eZEh
Encryption: 4KfgDmFhwbzLBWcnSEGKgTxGwfJzGqofSVTJKiAcokNX
Gateway ID: 3zd3wrCK8Dz5TXrcvk5dG5s9EEdf4Ck1v9VgBPMMFVkR
Gateway: ws://116.203.88.95:9000
The address of this client is: 3wqJJb1Xj9876KBPnGuSZnN5pCWH6id6wkzS2tL6eZEh.4KfgDmFhwbzLBWcnSEGKgTxGwfJzGqofSVTJKiAcokNX@3zd3wrCK8Dz5TXrcvk5dG5s9EEdf4Ck1v9VgBPMMFVkR
<!-- cmdrun ../../../../target/release/nym-network-requester run --id example -->
```
~~~
When running the above commands, the `./nym-network-requester --help ` command can be used to show a list of available parameters.
## Running your network requester (stats mode)
Once an network-requester has been initialized, we can start it with the following command.
```
./nym-network-requester run --id example --enable-statistics
```
Expected output:
~~~admonish example collapsible=true title="Console output"
```
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(nym-network-requester - version {{platform_release_version}})
THE NETWORK REQUESTER STATISTICS ARE ENABLED. IT WILL COLLECT AND SEND ANONYMIZED STATISTICS TO A CENTRAL SERVER. PLEASE QUIT IF YOU DON'T WANT THIS TO HAPPEN AND START WITHOUT THE enable-statistics FLAG .
2023-02-23T12:08:18.296Z INFO nym_network_requester::cli::run > Starting socks5 service provider
```
<!-- cmdrun ../../../../target/release/nym-network-requester --help -->
```
~~~
## Running your network requester
The `--enable-statistics` flag starts the node in a mode which reports very minimal usage statistics - the amount of bytes sent to a service, and the number of requests - to a service we run, as part of the Nym Connect Beta testing.
Use the following command to ping our stats service to see what it has recorded (remember to change the `'until'` date):
Once an network-requester has been initialized, we can start it with the following command:
```
curl -d '{"since":"2022-07-26T12:46:00.000000+00:00", "until":"2022-07-26T12:57:00.000000+00:00"}' -H "Content-Type: application/json" -X POST http://mainnet-stats.nymte.ch:8090/v1/all-statistics
./nym-network-requester run --id example
```
Expected output:
~~~admonish example collapsible=true title="Console output"
```
[
{
"Service":{
"requested_service":"chat-0.core.keybaseapi.com:443",
"request_processed_bytes":294,
"response_processed_bytes":0,
"interval_seconds":60,
"timestamp":"2022-07-26 12:55:44.459257091"
}
},
{
"Service":{
"requested_service":"chat-0.core.keybaseapi.com:443",
"request_processed_bytes":890,
"response_processed_bytes":0,
"interval_seconds":60,
"timestamp":"2022-07-26 12:56:44.459333653"
}
},
{
"Service":{
"requested_service":"api-0.core.keybaseapi.com:443",
"request_processed_bytes":1473,
"response_processed_bytes":0,
"interval_seconds":60,
"timestamp":"2022-07-26 12:56:44.459333653"
}
},
{
"Gateway":{
"gateway_id":"Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf",
"inbox_count":8,
"timestamp":"2022-07-26 12:46:34.148075290"
}
},
{
"Gateway":{
"gateway_id":"2BuMSfMW3zpeAjKXyKLhmY4QW1DXurrtSPEJ6CjX3SEh",
"inbox_count":6,
"timestamp":"2022-07-26 12:46:51.578765358"
}
},
{
"Gateway":{
"gateway_id":"Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf",
"inbox_count":8,
"timestamp":"2022-07-26 12:47:34.149270862"
}
}
]
```
<!-- cmdrun ../../../../target/release/nym-network-requester run --id example -->
```
~~~
## Upgrading your network requester
@@ -236,6 +138,7 @@ cp -vr ~/.nym/clients/myoldclient/data/* ~/.nym/service-providers/network-reques
```
Edit the gateway configuration to match what you used on your client. Specifically, edit the configuration file at:
```
~/.nym/service-providers/network-requester/mynetworkrequester/config/config.toml
```
@@ -304,29 +207,15 @@ sudo ufw status
For more information about your requester's port configuration, check the [requester port reference table](./network-requester-setup.md#requester-port-reference) below.
## Using your network requester
```admonish caution
Service Grant grantees should only whitelist a single application - edit your `allowed.list` accordingly!
```
Is this safe to do? If it was an open proxy, this would be unsafe, because any Nym user could make network requests to any system on the internet.
The next thing to do is: use your requester, share its address with friends (or whoever you want to help privacy-enhance their app traffic). Is this safe to do? If it was an open proxy, this would be unsafe, because any Nym user could make network requests to any system on the internet.
To make things a bit less stressful for administrators, the Network Requester drops all incoming requests by default. In order for it to make requests, you need to add specific domains to the `allowed.list` file at `$HOME/.nym/service-providers/network-requester/allowed.list`.
### Supporting custom domains with your network requester
It is easy to add new domains and services to your network requester - simply find out which endpoints (both URLs and raw IP addresses are supported) you need to whitelist, and then add these endpoints to your `allowed.list` as such:
It is easy to add new domains and services to your network requester - simply find out which endpoints (both URLs and raw IP addresses are supported) you need to whitelist, and then add these endpoints to your `allowed.list`.
```
cp service-providers/network-requester/allowed.list.sample ~/.nym/service-providers/network-requester/allowed.list
```
Those URLs will let through requests for the Blockstream Green and Electrum cryptocurrency wallets, as well as the KeyBase chat client.
> If you change your `allowed.list`, make sure you restart the `nym-network-requester.service` to pick up the new allowed request list
### Adding URLs for other clients
It would suck if Nym was restricted to only three clients. How can we add support for a new application? It's fairly easy to do.
Have a look in your nym-network-requester config directory:
How to go about this? Have a look in your nym-network-requester config directory:
```
ls $HOME/.nym/service-providers/network-requester/
@@ -334,13 +223,10 @@ ls $HOME/.nym/service-providers/network-requester/
# returns: allowed.list unknown.list
```
We already know that `allowed.list` is what lets requests go through. All unknown requests are logged to `unknown.list`. If you want to try using a new client type, just start the new application, point it at your local SOCKS5 proxy (configured to use your remote `nym-network-requester`), and keep copying URLs from `unknown.list` into `allowed.list` (it may take multiple tries until you get all of them, depending on the complexity of the application).
If you add support for a new application, we'd love to hear about it: let us know or submit a commented pull request on `allowed.list.sample`.
We already know that `allowed.list` is what lets requests go through. All unknown requests are logged to `unknown.list`. If you want to try using a new client type, just start the new application, point it at your local [socks client](../clients/socsk5-client.md) (configured to use your remote `nym-network-requester`), and keep copying URLs from `unknown.list` into `allowed.list` (it may take multiple tries until you get all of them, depending on the complexity of the application). Make sure to restart your network requester!
> If you are adding custom domains, please note that whilst they may appear in the logs of your network-requester as something like `api-0.core.keybaseapi.com:443`, you **only need** to include the main domain name, in this instance `keybaseapi.com`
### Running an open proxy
If you *really* want to run an open proxy, perhaps for testing purposes for your own use or among a small group of trusted friends, it is possible to do so. You can disable network checks by passing the flag `--open-proxy` flag when you run it. If you run in this configuration, you do so at your own risk.