From 7e36595d8fa7706876880b42df1c998a4b8c1478 Mon Sep 17 00:00:00 2001 From: import this <97586125+serinko@users.noreply.github.com> Date: Tue, 6 Aug 2024 12:37:37 +0000 Subject: [PATCH] [DOCs/bugfix]: Fix broken URLs (#4745) * create archive nym connect page & add redirections * add info to socks5 page * fix dev-portal links * finish URL edits and redirection --- documentation/dev-portal/src/SUMMARY.md | 9 ++++-- .../dev-portal/src/binaries/building-nym.md | 4 +-- .../dev-portal/src/clients/socks5-client.md | 2 -- .../dev-portal/src/clients/socks5/setup.md | 9 ++++-- .../src/clients/websocket/examples.md | 2 ++ .../dev-portal/src/clients/websocket/usage.md | 28 +++++++++---------- .../dev-portal/src/examples/browser-only.md | 12 ++++---- .../dev-portal/src/examples/using-nrs.md | 16 +++++------ documentation/dev-portal/src/nymvpn/cli.md | 2 +- .../src/sdk/rust/examples/credential.md | 3 +- .../dev-portal/src/sdk/rust/examples/surbs.md | 2 +- documentation/docs/book.toml | 12 ++++++-- .../docs/src/architecture/nym-vs-others.md | 9 +++--- .../src/archive/nodes/gateway-setup.md | 23 ++++++++------- .../operators/src/binaries/building-nym.md | 6 ++-- .../operators/src/legal/exit-gateway.md | 26 ++++++++--------- documentation/operators/src/sandbox.md | 2 +- .../operators/src/testing/gateway-probe.md | 4 +-- .../operators/src/testing/performance.md | 10 +++---- .../src/testing/prometheus-grafana.md | 4 +-- .../operators/src/troubleshooting/vps-isp.md | 2 +- 21 files changed, 100 insertions(+), 87 deletions(-) diff --git a/documentation/dev-portal/src/SUMMARY.md b/documentation/dev-portal/src/SUMMARY.md index 948235c69fe..355ed855682 100644 --- a/documentation/dev-portal/src/SUMMARY.md +++ b/documentation/dev-portal/src/SUMMARY.md @@ -2,7 +2,7 @@ - [Introduction](introduction.md) - [Clients Overview - Start Here!](clients-overview.md) -# SDKs +# SDKs - [Rust SDK](sdk/rust/rust.md) - [Message Types](sdk/rust/message-types.md) - [Message Helpers](sdk/rust/message-helpers.md) @@ -30,7 +30,7 @@ - [Using Your Client](clients/websocket/usage.md) - [Examples](clients/websocket/examples.md) - [Socks5 Client](clients/socks5-client.md) - - [Setup & Run](clients/socks5/setup.md) + - [Setup & Run](clients/socks5/setup.md) - [Using Your Client](clients/socks5/usage.md) - [Webassembly Client](clients/webassembly-client.md) @@ -54,8 +54,13 @@ # User Manuals - [NymVPN alpha](nymvpn/intro.md) - [CLI](nymvpn/cli.md) +--- + +# Archive +- [NymConnect Setup](archive/nym-connect.md) --- + # Misc. - [Code of Conduct](coc.md) - [Licensing](licensing.md) diff --git a/documentation/dev-portal/src/binaries/building-nym.md b/documentation/dev-portal/src/binaries/building-nym.md index 47fb637c61e..0bbb5e0ed1c 100644 --- a/documentation/dev-portal/src/binaries/building-nym.md +++ b/documentation/dev-portal/src/binaries/building-nym.md @@ -52,10 +52,10 @@ git checkout master # master branch has the latest release version: `develop` wi cargo build --release # build your binaries with **mainnet** configuration ``` -Quite a bit of stuff gets built. The key working parts for devs are the Client binaries and the CLI tool: +Quite a bit of stuff gets built. The key working parts for devs are the Client binaries and the CLI tool: * [websocket client](../clients/websocket-client.md): `nym-client` * [socks5 client](../clients/socks5-client.md): `nym-socks5-client` -* [nym-cli tool](https://nymtech.net/docs/tools/nym-cli.md): `nym-cli` +* [nym-cli tool](https://nymtech.net/docs/tools/nym-cli.html): `nym-cli` > You cannot build from GitHub's .zip or .tar.gz archive files on the releases page - the Nym build scripts automatically include the current git commit hash in the built binary during compilation, so the build will fail if you use the archive code (which isn't a Git repository). Check the code out from github using `git clone` instead. diff --git a/documentation/dev-portal/src/clients/socks5-client.md b/documentation/dev-portal/src/clients/socks5-client.md index 6fc1e6159fd..8ef8aff80f3 100644 --- a/documentation/dev-portal/src/clients/socks5-client.md +++ b/documentation/dev-portal/src/clients/socks5-client.md @@ -104,8 +104,6 @@ The `--use-reply-surbs` field denotes whether you wish to send [SURBs](https://n 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](https://nymtech.net/operators/nodes/network-requester.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/). -Since the nodes on this list are the infrastructure for [Nymconnect](https://nymtech.net/developers/quickstart/nymconnect-gui.html) they will support all apps on the [default whitelist](https://nymtech.net/operators/nodes/network-requester.md#network-requester-whitelist): Keybase, Telegram, Electrum, Blockstream Green, and Helios. - #### Choosing a Gateway By default - as in the example above - your client will choose a random gateway to connect to. diff --git a/documentation/dev-portal/src/clients/socks5/setup.md b/documentation/dev-portal/src/clients/socks5/setup.md index 55428dae754..a1fc1210a3e 100644 --- a/documentation/dev-portal/src/clients/socks5/setup.md +++ b/documentation/dev-portal/src/clients/socks5/setup.md @@ -1,9 +1,14 @@ -# Setup +# Setup > `nym-socks5-client` now also supports SOCKS4 and SOCKS4A protocols as well as SOCKS5. The Nym socks5 client allows you to proxy traffic from a desktop application through the mixnet, meaning you can send and receive information from remote application servers without leaking metadata which can be used to deanonymise you, even if you're using an encrypted application such as Signal. +```admonish info +Since the beginning of 2024 NymConnect is no longer maintained. Nym is developing a new client called [NymVPN](https://nymvpn.com), an application routing all users traffic thorugh the mixnet. +If users want to route their traffic through socks5 we advice to use this client. If you want to run deprecated NymConnect, visit [NymConnect archive page](../../archive/nym-connect.md) with setup and application examples. +``` + ## Setup and Run ### Download or compile socks5 client @@ -38,5 +43,3 @@ Now your client is initialised, start it with the following: ``` ./nym-socks5-client run --id ``` - - diff --git a/documentation/dev-portal/src/clients/websocket/examples.md b/documentation/dev-portal/src/clients/websocket/examples.md index 7367c291803..df9eb6d6575 100644 --- a/documentation/dev-portal/src/clients/websocket/examples.md +++ b/documentation/dev-portal/src/clients/websocket/examples.md @@ -12,4 +12,6 @@ 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. + diff --git a/documentation/dev-portal/src/clients/websocket/usage.md b/documentation/dev-portal/src/clients/websocket/usage.md index aab3af6b2bf..ed8c0da6f1e 100644 --- a/documentation/dev-portal/src/clients/websocket/usage.md +++ b/documentation/dev-portal/src/clients/websocket/usage.md @@ -1,17 +1,17 @@ # Using Your Client The Nym native client exposes a websocket interface that your code connects to. The **default** websocket port is `1977`, you can override that in the client config if you want. -Once you have a websocket connection, interacting with the client involves piping messages down the socket and listening for incoming messages. +Once you have a websocket connection, interacting with the client involves piping messages down the socket and listening for incoming messages. -# Message Requests -There are a number of message types that you can send up the websocket as defined [here](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs): +# Message Requests +There are a number of message types that you can send up the websocket as defined [here](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs): ```rust,noplayground {{#include ../../../../../clients/native/websocket-requests/src/requests.rs:55:97}} ``` ## Getting your own address -When you start your app, it is best practice to ask the native client to tell you what your own address is (from the generated configuration files - see [here](https://nymtech.net/docs/architecture/addressing-system.md) for more on Nym's addressing scheme). If you are running a service, you need to do this in order to know what address to give others. In a client-side piece of code you can also use this as a test to make sure your websocket connection is running smoothly. To do this, send: +When you start your app, it is best practice to ask the native client to tell you what your own address is (from the generated configuration files . If you are running a service, you need to do this in order to know what address to give others. In a client-side piece of code you can also use this as a test to make sure your websocket connection is running smoothly. To do this, send: ```json { @@ -28,9 +28,9 @@ You'll receive a response of the format: } ``` -See [here](https://github.com/nymtech/nym/blob/93cc281abc2cc951023b51746fa6f2ead1f56c46/clients/native/examples/python-examples/websocket/textsend.py#L16C9-L16C9) for an example of this being used. +See [here](https://github.com/nymtech/nym/blob/93cc281abc2cc951023b51746fa6f2ead1f56c46/clients/native/examples/python-examples/websocket/textsend.py#L16C9-L16C9) for an example of this being used. -> Note that all the pieces of native client example code begin with printing the selfAddress. Examples exist for Rust, Go, Javascript, and Python. +> Note that all the pieces of native client example code begin with printing the selfAddress. Examples exist for Rust, Go, Javascript, and Python. ## Sending text If you want to send text information through the mixnet, format a message like this one and poke it into the websocket: @@ -65,26 +65,26 @@ Your client will send along a number of `replySurbs` to the recipient of the mes ```json { "type": "sendAnonymous", - "message": "something you want to keep secret", - "recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm", + "message": "something you want to keep secret", + "recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm", "replySurbs": 20 // however many reply SURBs to send along with your message } ``` -See ['Replying to SURB Messages'](#replying-to-surb-messages) below for an example of how to deal with incoming messages that have SURBs attached. +See ['Replying to SURB Messages'](#replying-to-surb-messages) below for an example of how to deal with incoming messages that have SURBs attached. -Deciding on the amount of SURBs to generate and send along with outgoing messages depends on the expected size of the reply. You might want to send a lot of SURBs in order to make sure you get your response as quickly as possible (but accept the minor additional latency when sending, as your client has to generate and encrypt the packets), or you might just send a few (e.g. 20) and then if your response requires more SURBs, send them along, accepting the additional latency in getting your response. +Deciding on the amount of SURBs to generate and send along with outgoing messages depends on the expected size of the reply. You might want to send a lot of SURBs in order to make sure you get your response as quickly as possible (but accept the minor additional latency when sending, as your client has to generate and encrypt the packets), or you might just send a few (e.g. 20) and then if your response requires more SURBs, send them along, accepting the additional latency in getting your response. ## 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. -> As a response the `native-client` will send a `ServerResponse` to be decoded. See [Message Responses](#message-responses) below for more. +> As a response the `native-client` will send a `ServerResponse` to be decoded. See [Message Responses](#message-responses) below for more. You can find examples of sending and receiving binary data in the [code examples](https://github.com/nymtech/nym/tree/master/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. ## Replying to SURB messages -Each bucket of `replySURBs`, when received as part of an incoming message, has a unique session identifier, which **only identifies the bucket of pre-addressed packets**. This is necessary to make sure that your app is replying to the correct people with the information meant for them in a situation where multiple clients are sending requests to a single service. +Each bucket of `replySURBs`, when received as part of an incoming message, has a unique session identifier, which **only identifies the bucket of pre-addressed packets**. This is necessary to make sure that your app is replying to the correct people with the information meant for them in a situation where multiple clients are sending requests to a single service. Constructing a reply with SURBs looks something like this (where `senderTag` was parsed from the incoming message) @@ -107,9 +107,9 @@ Errors from the app's client, or from the gateway, will be sent down the websock ``` ## LaneQueueLength -This is currently only used in the [Socks Client](../socks5-client.md) to keep track of the number of Sphinx packets waiting to be sent to the mixnet via being slotted amongst cover traffic. As this value becomes larger, the client signals to the application it should slow down the speed with which it writes to the proxy. This is to stop situations arising whereby an app connected to the client appears as if it has sent (e.g.) a bunch of messages and is awaiting a reply, when they in fact have not been sent through the mixnet yet. +This is currently only used in the [Socks Client](../socks5-client.md) to keep track of the number of Sphinx packets waiting to be sent to the mixnet via being slotted amongst cover traffic. As this value becomes larger, the client signals to the application it should slow down the speed with which it writes to the proxy. This is to stop situations arising whereby an app connected to the client appears as if it has sent (e.g.) a bunch of messages and is awaiting a reply, when they in fact have not been sent through the mixnet yet. -# Message Responses +# Message Responses Responses to your messages are defined [here](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/responses.rs): ```rust,noplayground diff --git a/documentation/dev-portal/src/examples/browser-only.md b/documentation/dev-portal/src/examples/browser-only.md index b41367d76e4..01472bef221 100644 --- a/documentation/dev-portal/src/examples/browser-only.md +++ b/documentation/dev-portal/src/examples/browser-only.md @@ -1,12 +1,12 @@ # Browser only -With the Typescript SDK you can run a Nym client in a webworker - meaning you can connect to the mixnet through the browser without having to worry about any other code than your web framework. +With the Typescript SDK you can run a Nym client in a webworker - meaning you can connect to the mixnet through the browser without having to worry about any other code than your web framework. -- Oreowallet have integrated `mixFetch` into their browser-extension wallet to run transactions through the mixnet. - - [Codebase](https://github.com/oreoslabs/oreowallet-extension/tree/mixFetch) +- Oreowallet have integrated `mixFetch` into their browser-extension wallet to run transactions through the mixnet. + - [Codebase](https://github.com/oreoslabs/oreowallet-extension/tree/mixFetch) -- [NoTrustVerify](https://notrustverify.ch/) have set up an example application using [`mixFetch`](https://sdk.nymtech.net/examples/mix-fetch) to fetch crypto prices from CoinGecko over the mixnet. - - [Website](https://notrustverify.github.io/mixfetch-examples/) - - [Codebase](https://github.com/notrustverify/mixfetch-examples) +- [NoTrustVerify](https://notrustverify.ch/) have set up an example application using [`mixFetch`](https://sdk.nymtech.net/examples/mix-fetch) to fetch crypto prices from CoinGecko over the mixnet. + - [Website](https://notrustverify.github.io/mixfetch-examples/) + - [Codebase](https://github.com/notrustverify/mixfetch-examples) - There is a coconut-scheme based Credential Library playground [here](https://coco-demo.nymtech.net/). This is a WASM implementation of our Coconut libraries which generate raw Coconut credentials. Test it to create and re-randomize your own credentials. For more information on what is happening here check out the [Coconut docs](https://nymtech.net/docs/coconut.html). diff --git a/documentation/dev-portal/src/examples/using-nrs.md b/documentation/dev-portal/src/examples/using-nrs.md index 0732340b792..7111f624013 100644 --- a/documentation/dev-portal/src/examples/using-nrs.md +++ b/documentation/dev-portal/src/examples/using-nrs.md @@ -1,17 +1,17 @@ # Apps Using Network Requesters -These applications utilise custom app logic in the user-facing apps in order to communicate using the mixnet as a transport layer, without having to rely on custom server-side logic. Instead, they utilise existing Nym infrastructure - [Network Requesters](https://nymtech.net/operators/nodes/network-requester-setup.html) - with a custom whitelist addition. +These applications utilise custom app logic in the user-facing apps in order to communicate using the mixnet as a transport layer, without having to rely on custom server-side logic. Instead, they utilise existing Nym infrastructure - Network Requesters - now embeded in `nym-node` running as `exit-gateway`. -If you are sending 'normal' application traffic, and/or don't require and custom logic to be happening on the 'other side' of the mixnet, this is most likely the best option to take as a developer who wishes to privacy-enhance their application. +If you are sending 'normal' application traffic, and/or don't require and custom logic to be happening on the 'other side' of the mixnet, this is most likely the best option to take as a developer who wishes to privacy-enhance their application. + +> Nym will soon be switching from a whitelist-based approach to a blocklist-based approach to filtering traffic. As such, it will soon be even easier for developers to utilise the mixnet, as they will not have to run their own NRs or have to add their domains to the whitelist -> Nym will soon be switching from a whitelist-based approach to a blocklist-based approach to filtering traffic. As such, it will soon be even easier for developers to utilise the mixnet, as they will not have to run their own NRs or have to add their domains to the whitelist - - DarkFi over Nym leverages Nym’s mixnet as a pluggable transport for DarkIRC, their p2p IRC variant. Users can anonymously connect to peers over the network, ensuring secure and private communication within the DarkFi ecosystem. Written in **Rust**. - [Docs](https://darkrenaissance.github.io/darkfi/clients/nym_outbound.html?highlight=nym#3--run) - - [Github](https://github.com/darkrenaissance/darkfi/tree/master/doc) + - [Github](https://github.com/darkrenaissance/darkfi/tree/master/doc) -- MiniBolt is a complete guide to building a Bitcoin & Lightning full node on a personal computer. It has the capacity to run network traffic (transactions and syncing) over the mixnet, so you can privately sync your node and not expose your home IP to the wider world when interacting with the rest of the network! +- MiniBolt is a complete guide to building a Bitcoin & Lightning full node on a personal computer. It has the capacity to run network traffic (transactions and syncing) over the mixnet, so you can privately sync your node and not expose your home IP to the wider world when interacting with the rest of the network! - [Docs](https://v2.minibolt.info/bonus-guides/system/nym-mixnet#proxying-bitcoin-core) - [Codebase](https://github.com/minibolt-guide/minibolt) -- Email over Nym is a set of configuration options to set up a Network Requester to send and recieve emails over Nym, using something like Thunderbird. - - [Codebase](https://github.com/dial0ut/nymstr-email) \ No newline at end of file +- Email over Nym is a set of configuration options to set up a Network Requester to send and recieve emails over Nym, using something like Thunderbird. + - [Codebase](https://github.com/dial0ut/nymstr-email) diff --git a/documentation/dev-portal/src/nymvpn/cli.md b/documentation/dev-portal/src/nymvpn/cli.md index b921d4f859f..8e682dc987e 100644 --- a/documentation/dev-portal/src/nymvpn/cli.md +++ b/documentation/dev-portal/src/nymvpn/cli.md @@ -171,7 +171,7 @@ If you want to run NymVPN CLI in Nym Sandbox environment, there are a few adjust curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env ``` -2. Check available Gateways at [nymvpn.com/en/alpha/api/gateways](https://nymvpn.com/en/alpha/api/gateways) +2. Check available Gateways at [Sandbox API](https://sandbox-nym-api1.nymtech.net/api/v1/gateways) or [Sandbox Swagger page](https://sandbox-nym-api1.nymtech.net/api/swagger/index.html) 3. Run with a flag `-c` ```sh diff --git a/documentation/dev-portal/src/sdk/rust/examples/credential.md b/documentation/dev-portal/src/sdk/rust/examples/credential.md index 979d0219147..f29d6748ba8 100644 --- a/documentation/dev-portal/src/sdk/rust/examples/credential.md +++ b/documentation/dev-portal/src/sdk/rust/examples/credential.md @@ -5,5 +5,4 @@ The following code shows how you can use the SDK to create and use a credential {{#include ../../../../../../sdk/rust/nym-sdk/examples/bandwidth.rs}} ``` -You can read more about Coconut credentials (also referred to as `zk-Nym`) [here](https://nymtech.net/docs/coconut.md). - +You can read more about Coconut credentials (also referred to as `zk-Nym`) [here](https://nymtech.net/docs/coconut.html). diff --git a/documentation/dev-portal/src/sdk/rust/examples/surbs.md b/documentation/dev-portal/src/sdk/rust/examples/surbs.md index 3cedd45ba10..d3b6b2da1bc 100644 --- a/documentation/dev-portal/src/sdk/rust/examples/surbs.md +++ b/documentation/dev-portal/src/sdk/rust/examples/surbs.md @@ -1,7 +1,7 @@ # Anonymous Replies with SURBs (Single Use Reply Blocks) Both functions used to send messages through the mixnet (`send_message` and `send_plain_message`) send a pre-determined number of SURBs along with their messages by default. -You can read more about how SURBs function under the hood [here](https://nymtech.net/docs/architecture/traffic-flow.md#private-replies-using-surbs). +You can read more about how SURBs function under the hood [here](https://nymtech.net/docs/architecture/traffic-flow.html#private-replies-using-surbs). In order to reply to an incoming message using SURBs, you can construct a `recipient` from the `sender_tag` sent along with the message you wish to reply to: diff --git a/documentation/docs/book.toml b/documentation/docs/book.toml index 87087c093d4..45eb6e51ae0 100644 --- a/documentation/docs/book.toml +++ b/documentation/docs/book.toml @@ -18,8 +18,8 @@ pagetoc = true sidebar-width = "280px" content-max-width = "80%" root-font-size = "70%" -# if you need to change anything in the index.hbs file you need to turn this to `false`, rebuild the book, -# probably remove the additional `comment` that gets appended to the header, and then change this back to `true`. +# if you need to change anything in the index.hbs file you need to turn this to `false`, rebuild the book, +# probably remove the additional `comment` that gets appended to the header, and then change this back to `true`. # this is because of a bug in the `mdbook-theme` plugin turn-off = true @@ -103,3 +103,11 @@ copy-js = true # include Javascript code for search [output.linkcheck] warning-policy = "warn" + +[output.html.redirect] +"/sdk/rust/examples/socks.html" = "https://nymtech.net/developers/sdk/rust/examples/socks.html" +"/clients/overview.html" = "https://nymtech.net/developers/clients-overview.html" +"/sdk/rust/rust.html" = "https://nymtech.net/developers/sdk/rust/rust.html" +"/clients/socks5-client.html" = "https://nymtech.net/developers/clients/socks5-client.html" +"/clients/webassembly-client.html" = "https://nymtech.net/developers/clients/webassembly-client.html" +"/sdk/typescript.html" = "https://sdk/nymtech.net" diff --git a/documentation/docs/src/architecture/nym-vs-others.md b/documentation/docs/src/architecture/nym-vs-others.md index 27ec3a4f869..de654675eda 100644 --- a/documentation/docs/src/architecture/nym-vs-others.md +++ b/documentation/docs/src/architecture/nym-vs-others.md @@ -4,11 +4,12 @@ Nym is the first system we're aware of which provides integrated protection on both the network and transaction level at once. This seamless approach gives the best possible privacy protections, ensuring that nothing falls through the cracks between systems. -The diagram and brief explainer texts below give a high level overview of the difference between Nym and other comparable systems. +The diagram and brief explainer texts below give a high level overview of the difference between Nym and other comparable systems. -> If you want to dig more deeply into the way traffic is packetised and moved through the mixnet, check out the [Mixnet Traffic Flow](https://nymtech.net/docs/architecture/traffic-flow.html) page of the docs. - - +> If you want to dig more deeply into the way traffic is packetised and moved through the mixnet, check out the [Mixnet Traffic Flow](https://nymtech.net/docs/architecture/traffic-flow.html) page of the docs. + ### Nym vs VPNs diff --git a/documentation/operators/src/archive/nodes/gateway-setup.md b/documentation/operators/src/archive/nodes/gateway-setup.md index c48bc6608a4..06b87fca1c7 100644 --- a/documentation/operators/src/archive/nodes/gateway-setup.md +++ b/documentation/operators/src/archive/nodes/gateway-setup.md @@ -23,7 +23,7 @@ Make sure you do the preparation listed in the [preliminary steps page](initial- ## 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. +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. To begin, move to `/target/release` directory from which you run the node commands: @@ -47,10 +47,10 @@ You can also check the various arguments required for individual commands with: ## Initialising your Gateway -As Nym developers build towards [Exit Gateway](../../legal/exit-gateway.md) functionality, operators can now run their `nym-gateway` binary with inbuilt Network Requester and include the our new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). Considering the plan to [*smoosh*](../faq/smoosh-faq.md) all the nodes into one binary and have wide opened Exit Gateways, we recommend this setup, instead of operating two separate binaries. +As Nym developers build towards [Exit Gateway](../../legal/exit-gateway.md) functionality, operators can now run their `nym-gateway` binary with inbuilt Network Requester and include the our new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). Considering the plan to [*smoosh*](../faq/smoosh-faq.md) all the nodes into one binary and have wide opened Exit Gateways, we recommend this setup, instead of operating two separate binaries. ```admonish warning -Before you start an Exit Gateway, read our [Operators Legal Forum](../legal/exit-gateway.md) page and [*Project Smoosh FAQ*](../faq/smoosh-faq.md). +Before you start an Exit Gateway, read our [Operators Legal Forum](../../legal/exit-gateway.md) page and [*Project Smoosh FAQ*](../faq/smoosh-faq.md). ``` ```admonish info @@ -68,9 +68,9 @@ An operator can initialise the Exit Gateway functionality by adding Network Requ ``` -You can see that the printed information besides *identity* and *sphinx keys* also includes a long string called *address*. This is the address to be provided to your local [socks5 client](https://nymtech.net/docs/clients/socks5-client.html) as a `--provider` if you wish to connect to your own Exit Gateway. +You can see that the printed information besides *identity* and *sphinx keys* also includes a long string called *address*. This is the address to be provided to your local [socks5 client](https://nymtech.net/docs/clients/socks5-client.html) as a `--provider` if you wish to connect to your own Exit Gateway. -Additionally +Additionally #### Add Network Requester to an existing Gateway @@ -83,10 +83,10 @@ See the options: ``` -To setup Exit Gateway functionality with our new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) add a flag `--with-exit-policy true`. +To setup Exit Gateway functionality with our new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) add a flag `--with-exit-policy true`. ``` -./nym-gateway setup-network-requester --enabled true --with-exit-policy true --id +./nym-gateway setup-network-requester --enabled true --with-exit-policy true --id ``` Say we have a Gateway with `` as `new-gateway`, originally initialised and ran without the Exit Gateway functionality. To change the setup, run: @@ -156,7 +156,7 @@ The `run` command starts the Gateway: ## Bonding your Gateway ```admonish info -Before you bond your Gateway, please make sure the [firewall configuration](./maintenance.md#configure-your-firewall) is setup so your Gateway can be reached from the outside. You can also setup WSS and automate your Gateway to simplify the operation overhead. We highly recommend to run any of these steps before bonding to prevent disruption of your Gateway's routing score later on. +Before you bond your Gateway, please make sure the [firewall configuration](../../nodes/maintenance.md#configure-your-firewall) is setup so your Gateway can be reached from the outside. You can also setup WSS and automate your Gateway to simplify the operation overhead. We highly recommend to run any of these steps before bonding to prevent disruption of your Gateway's routing score later on. ``` ### Via the Desktop wallet (recommended) @@ -167,7 +167,7 @@ You can bond your Gateway via the Desktop wallet. **Make sure your Gateway is ru 2. Enter the `Amount`, `Operating cost` and press `Next`. -3. You will be asked to run a the `sign` command with your `gateway` - copy and paste the long signature `` and paste it as a value of `--contract-msg` in the following command: +3. You will be asked to run a the `sign` command with your `gateway` - copy and paste the long signature `` and paste it as a value of `--contract-msg` in the following command: ``` ./nym-gateway sign --id --contract-msg @@ -186,7 +186,7 @@ It will look something like this (as `` we used `supergateway`): |_| |_|\__, |_| |_| |_| |___/ - (nym-gateway - version v1.1.) + (nym-gateway - version v1.1.) >>> attempting to sign 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a @@ -206,7 +206,7 @@ It will look something like this (as `` we used `supergateway`): * And paste it into the wallet nodal, press `Next` and confirm the transaction. -![Paste Signature](../../images/wallet-screenshots/wallet-gateway-sign.png) +![Paste Signature](../../images/wallet-screenshots/wallet-gateway-sign.png) *This image is just an example, copy-paste your own base58-encoded signature.* * Your Gateway is now bonded. @@ -220,4 +220,3 @@ If you want to bond your Gateway via the CLI, then check out the [relevant secti ## Maintenance For Gateway upgrade, firewall setup, port configuration, API endpoints, VPS suggestions, automation, WSS setup and more, see the [maintenance page](../../nodes/maintenance.md) - diff --git a/documentation/operators/src/binaries/building-nym.md b/documentation/operators/src/binaries/building-nym.md index d0aa4033763..42165b9bc83 100644 --- a/documentation/operators/src/binaries/building-nym.md +++ b/documentation/operators/src/binaries/building-nym.md @@ -56,9 +56,9 @@ Quite a bit of stuff gets built. The key working parts are: * [Nym Node](../nodes/nym-node.md): `nym-node` * [Validator](../nodes/validator-setup.md) -* [websocket client](https://nymtech.net/docs/clients/websocket-client.html): `nym-client` -* [socks5 client](https://nymtech.net/docs/clients/socks5-client.html): `nym-socks5-client` -* [webassembly client](https://nymtech.net/docs/clients/webassembly-client.html): `webassembly-client` +* [websocket client](https://nymtech.net/developers/clients/websocket-client.html): `nym-client` +* [socks5 client](https://nymtech.net/developers/clients/socks5-client.html): `nym-socks5-client` +* [webassembly client](https://nymtech.net/developers/clients/webassembly-client.html): `webassembly-client` * [nym-cli tool](https://nymtech.net/docs/tools/nym-cli.html): `nym-cli` * [nym-api](../nodes/nym-api.md): `nym-api` * [nymvisor](../nodes/nymvisor-upgrade.md): `nymvisor` diff --git a/documentation/operators/src/legal/exit-gateway.md b/documentation/operators/src/legal/exit-gateway.md index 9294e97837b..7e0f5cc71ca 100644 --- a/documentation/operators/src/legal/exit-gateway.md +++ b/documentation/operators/src/legal/exit-gateway.md @@ -6,7 +6,7 @@ The entire content of this page is under [Creative Commons Attribution 4.0 Inter This page is a part of Nym Community Legal Forum and its content is composed by shared advices in [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) as well as though pull requests done by the node operators directly to our [repository](https://github.com/nymtech/nym/tree/develop/documentation/operators/src), reviewed by Nym DevRels. -This document presents an initiative to further support Nym’s mission of allowing privacy for everyone everywhere. This would be achieved with the support of Nym node operators operating Gateways and opening these to any online service. Such setup needs a **clear policy**, one which will remain the **same for all operators** running Nym nodes. The [proposed **Exit policy**](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) is a combination of two existing safeguards: [Tor Null ‘deny’ list](https://tornull.org/) and [Tor reduced policy](https://tornull.org/tor-reduced-reduced-exit-policy.php). +This document presents an initiative to further support Nym’s mission of allowing privacy for everyone everywhere. This would be achieved with the support of Nym node operators operating Gateways and opening these to any online service. Such setup needs a **clear policy**, one which will remain the **same for all operators** running Nym nodes. The [proposed **Exit policy**](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) is a combination of two existing safeguards: [Tor Null ‘deny’ list](https://tornull.org/) and Tor reduced policy. All the technical changes on the side of Nym nodes - ***Project Smoosh*** - are described in the [FAQ section](../archive/faq/smoosh-faq.md). @@ -17,13 +17,13 @@ Nym core team cannot provide comprehensive legal advice across all jurisdictions ## Summary -* This document outlines a plan to change Nym Gateways from operating with an ‘allow’ to a ‘deny’ list to enable broader uptake and usage of the Nym Mixnet. It provides operators with an overview of the plan, pros and cons, legal as well as technical advice. +* This document outlines a plan to change Nym Gateways from operating with an ‘allow’ to a ‘deny’ list to enable broader uptake and usage of the Nym Mixnet. It provides operators with an overview of the plan, pros and cons, legal as well as technical advice. * Nym is committed to ensuring privacy for all users, regardless of their location and for the broadest possible range of online services. In order to achieve this aim, the Nym Mixnet needs to increase its usability across a broad range of apps and services. -* Currently, Nym Gateway nodes only enable access to apps and services that are on an ‘allow’ list that is maintained by the core team. +* Currently, Nym Gateway nodes only enable access to apps and services that are on an ‘allow’ list that is maintained by the core team. -* To decentralise and enable privacy for a broader range of services, this initiative will have to transition from the current ‘allow’ list to a ‘deny’ list - [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). In accordance with the [Tor Null 'deny' list](https://tornull.org/) and [Tor reduced policy](https://tornull.org/tor-reduced-reduced-exit-policy.php), which are two established safeguards. +* To decentralise and enable privacy for a broader range of services, this initiative will have to transition from the current ‘allow’ list to a ‘deny’ list - [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). In accordance with the Tor Null 'deny' list and [Tor reduced policy](https://tornull.org/tor-reduced-reduced-exit-policy.php), which are two established safeguards. * This will enhance the usage and appeal of Nym products for end users. As a result, increased usage will ultimately lead to higher revenues for Nym operators. @@ -52,7 +52,7 @@ Previous setup: Running nodes supporting strict SOCKS5 app-based traffic | Technical | - No changes required in technical setup | | | Operational | - No impact on operators operations (e.g., relationships with VPS providers)
- Low overhead
- Can be run as an individual | | | Legal | - Limited legal risks for operators | | -| Financial | | - Low revenues for operators due to limited product traction | +| Financial | | - Low revenues for operators due to limited product traction | The new setup: Running nodes supporting traffic of any online service (with safeguards in the form of a denylist) @@ -66,11 +66,11 @@ The new setup: Running nodes supporting traffic of any online service (with safe ## Exit Gateways: New setup -In our previous technical setup, Network Requesters acted as a proxy, and only made requests that match an allow list. That was a default IP based list of allowed domains stored at Nym page in a centralised fashion possibly re-defined by any Network Requester operator. +In our previous technical setup, Network Requesters acted as a proxy, and only made requests that match an allow list. That was a default IP based list of allowed domains stored at Nym page in a centralised fashion possibly re-defined by any Network Requester operator. This restricts the hosts that the NymConnect app can connect to and has the effect of selectively supporting messaging services (e.g. Telegram, Matrix) or crypto wallets (e.g. Electrum or Monero). Operators of Network Requesters can have confidence that the infrastructure they run only connects to a limited set of public internet hosts. -The principal change in the new configuration is to make this short allow list more permissive. Nym's [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) will restrict the hosts to which Nym Mixnet and Nym VPN users are permitted to connect. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym Mixnet VPN and VPN clients (both wrapped in the same app). +The principal change in the new configuration is to make this short allow list more permissive. Nym's [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) will restrict the hosts to which Nym Mixnet and Nym VPN users are permitted to connect. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym Mixnet VPN and VPN clients (both wrapped in the same app). As of now we the Gateways will be defaulted to a combination of [Tor Null ‘deny’ list](https://tornull.org/) (note: Not affiliated with Tor) - reproduction permitted under Creative Commons Attribution 3.0 United States License which is IP-based, e.g., `ExitPolicy reject 5.188.10.0/23:*` and [Tor reduced policy](https://tornull.org/tor-reduced-reduced-exit-policy.php). Whether we will stick with this list, do modifications or compile another one is still a subject of discussion. In all cases, this policy will remain the same for all the nodes, without any option to modify it by Nym node operators to secure stable and reliable service for the end users. @@ -82,14 +82,14 @@ We also recommend operators to check the technical advice from [Tor](https://com Giving the legal similarity between Nym Exit Gateways and Tor Exit Relays, it is helpful to have a look in [Tor community Exit Guidelines](https://community.torproject.org/relay/community-resources/tor-exit-guidelines/). This chapter is an exert of tor page. -Note that Tor states: +Note that Tor states: > This FAQ is for informational purposes only and does not constitute legal advice. -*Check legal advice prior to running an exit relay* +*Check legal advice prior to running an exit relay* * Understand the risks associated with running an exit relay; E.g., know legal paragraphs relevant in the country of operations: - US [DMCA 512](https://www.law.cornell.edu/uscode/text/17/512); see [EFF's Legal FAQ for Tor Operators](https://community.torproject.org/relay/community-resources/eff-tor-legal-faq) (a very good and relevant read for other countries as well) - - Germany’s [TeleMedienGesetz 8](http://www.gesetze-im-internet.de/tmg/__8.html) and [15](http://www.gesetze-im-internet.de/tmg/__15.html) + - Germany’s [TeleMedienGesetz 8](https://www.gesetze-im-internet.de/tmg/__8.html) and 15](https://www.gesetze-im-internet.de/tmg/__15.html) - Netherlands: [Artikel 6:196c BW](http://wetten.overheid.nl/BWBR0005289/Boek6/Titel3/Afdeling4A/Artikel196c/) - Austria: [E-Commerce-Gesetz 13](http://www.ris.bka.gv.at/Dokument.wxe?Abfrage=Bundesnormen&Dokumentnummer=NOR40025809) - Sweden: [16-19 2002:562](https://lagen.nu/2002:562#P16S1) @@ -100,9 +100,9 @@ Note that Tor states: * Consult a lawyer / local digital rights association / the EFF prior to operating an exit relay, especially in a place where exit relay operators have been harassed or not operating before. Note that Tor DOES NOT provide legal advice for specific countries. It only provides general advice (itself or in partnership), eventually skewed towards [US audiences](https://www.eff.org/pages/legal-faq-tor-relay-operators). -*Run an exit relay within an entity* +*Run an exit relay within an entity* -As an organisation - it might help from a liability perspective +As an organisation - it might help from a liability perspective * Within your university * With a node operators’ association (e.g., a Torservers.net partner) * Within a company @@ -114,7 +114,7 @@ As an organisation - it might help from a liability perspective * Note that Tor states: *“We are not aware of any case that made it near a court, and we will do everything in our power to support you if it does.”* * Document experience with ISPs at [community.torproject.org/relay/community-resources/good-bad-isps](https://community.torproject.org/relay/community-resources/good-bad-isps/) -Useful links: +Useful links: * Tor abuse templates: - [community.torproject.org/relay/community-resources/tor-abuse-templates/](https://community.torproject.org/relay/community-resources/tor-abuse-templates/) diff --git a/documentation/operators/src/sandbox.md b/documentation/operators/src/sandbox.md index 4a24396085f..dee07d0245b 100644 --- a/documentation/operators/src/sandbox.md +++ b/documentation/operators/src/sandbox.md @@ -40,7 +40,7 @@ curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/env ![](images/sandbox.png) ~~~admonish tip -1. If you [built Nym from source](building-nym.md), you already have `sandbox.env` as a part of the monorepo (`nym/envs/sandbox.env`). Giving that you are likely to run `nym-node` from `nym/target/release`, the flag will look like this `--config-env-file ../../envs/sandbox.env` +1. If you [built Nym from source](../binaries/building-nym.md), you already have `sandbox.env` as a part of the monorepo (`nym/envs/sandbox.env`). Giving that you are likely to run `nym-node` from `nym/target/release`, the flag will look like this `--config-env-file ../../envs/sandbox.env` 2. You can export the path to `sandbox.env` to your enviromental variables: ```sh diff --git a/documentation/operators/src/testing/gateway-probe.md b/documentation/operators/src/testing/gateway-probe.md index 3fe82a19ea9..235758facac 100644 --- a/documentation/operators/src/testing/gateway-probe.md +++ b/documentation/operators/src/testing/gateway-probe.md @@ -2,8 +2,8 @@ Nym Node operators running Gateway functionality are already familiar with the monitoring tool [Harbourmaster.nymtech.net](https://harbourmaster.nymtech.net). Under the hood of Nym Harbourmaster runs iterations of `nym-gateway-probe` doing various checks and displaying the results on the interface. Operators don't have to rely on the probe ran by Nym and wait for the data to refresh. With `nym-gateway-probe` everyone can check any Gateway's networking status from their own computer at any time. In one command the client queries data from: -- [`nym-api`](https://validator.nymtech.net/api/) -- [`explorer-api`](https://explorer.nymtech.net/api/) +- [`nym-api`](https://validator.nymtech.net/api/v1/gateways) +- [`explorer-api`](https://explorer.nymtech.net/api/v1/gateways) - [`harbour-master`](https://harbourmaster.nymtech.net/) diff --git a/documentation/operators/src/testing/performance.md b/documentation/operators/src/testing/performance.md index e6d0eeee0c2..a9648b15299 100644 --- a/documentation/operators/src/testing/performance.md +++ b/documentation/operators/src/testing/performance.md @@ -4,7 +4,7 @@ Nym Mixnet has been running on mainnet for quite some time. There is still work As developers we need to be constantly improving the software. Operators have as much important role, keep their nodes up to date, monitor their performance and share their feedback with the rest of the community and core developers. -Therefore [monitoring](#monitoring) and [testing](#testing) are essential pieces of our common work. We call out all Nym operators to join the efforts! +Therefore [monitoring](#monitoring) and [testing](#testing) are essential pieces of our common work. We call out all Nym operators to join the efforts! ## Monitoring @@ -24,10 +24,10 @@ A list of different scripts, templates and guides for easier navigation: For the purpose of the performance testing Nym core developers plan to run instances of Prometheus and Grafana connected to Node explorer in the house. The network overall key insights we seek from these tests are primarily internal. We're focused on pinpointing bottlenecks, capacity loads, and monitoring cpu usage on the nodes' machines. -## Testing +## Testing ```admonish info -For the moment we paused Fast and Furious `perf` environment. Nym Mainnet environment will be used for future tests, please wait for further instructions. +For the moment we paused Fast and Furious `perf` environment. Nym Mainnet environment will be used for future tests, please wait for further instructions. ``` Nym asks its decentralised community of operators to join a series of performance testing events in order to **increase the overall quality of the Mixnet**. The main takeaways of such event are: @@ -45,7 +45,7 @@ Visit [Fast and Furious web page]({{performance_testing_webpage}}) and [Nym Harb ## Performance Testing Work Flow -* Nym runs a paralel network environment [validator.performance.nymte.ch]({{performance_validator}}) with a chain ID `perf` +* Nym runs a paralel network environment with a chain ID `perf` * Operators of Nym Nodes join by following easy steps on [performance testing web page]({{performance_testing_webpage}}), including simplified node authentication signature (while keep running their nodes on the mainnet) * Once signed in, operators will be asked to swap their binary for the modified version with metrics endpoint to be able to connect their own [monitoring system](#monitoring) * Core node data will be fed to a unique mixnet contract for the `perf` side chain @@ -57,5 +57,3 @@ Visit [Fast and Furious web page]({{performance_testing_webpage}}) and [Nym Harb ## More Information * What happens after the test or what operators get for participating is shared up to date on the [performance testing web page]({{performance_testing_webpage}}) - - diff --git a/documentation/operators/src/testing/prometheus-grafana.md b/documentation/operators/src/testing/prometheus-grafana.md index bd9f5af8256..3ea0f88d5e0 100644 --- a/documentation/operators/src/testing/prometheus-grafana.md +++ b/documentation/operators/src/testing/prometheus-grafana.md @@ -1,6 +1,6 @@ # Prometheus & Grafana -The combination of Prometheus and Grafana is a common stack used by Nym team for internal monitoring as well as by core community operators like [ExploreNym](https://github.com/ExploreNYM/vps-monitor) or [No Trust Verify](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1). +The combination of Prometheus and Grafana is a common stack used by Nym team for internal monitoring as well as by core community operators like [ExploreNym](https://github.com/ExploreNYM/self-hosted-monitor) or [No Trust Verify](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1). @@ -33,4 +33,4 @@ There are various ways how to setup this stack. You can chose based on your pref * [Prometheus documentation](https://prometheus.io/docs/introduction/overview/) * Installation [guide to install Prometheus](https://www.cherryservers.com/blog/install-prometheus-ubuntu) on Ubuntu by cherryservers * [Grafana installation guide](https://grafana.com/docs/grafana/latest/setup-grafana/installation/debian/) -* Nym's script [`prom_targets.py`](https://github.com/nymtech/nym/blob/promethus-is-our-friend/scripts/prom_targets.py) - a python program to request data from API and can be plugged to this stack +* Nym's script [`prom_targets.py`](https://github.com/nymtech/nym/blob/develop/scripts/prom_targets.py) - a python program to request data from API and can be plugged to this stack diff --git a/documentation/operators/src/troubleshooting/vps-isp.md b/documentation/operators/src/troubleshooting/vps-isp.md index 3a1c5d6d91d..a7c8ce212b6 100644 --- a/documentation/operators/src/troubleshooting/vps-isp.md +++ b/documentation/operators/src/troubleshooting/vps-isp.md @@ -64,7 +64,7 @@ Be extra careful editing this file since you may lock yourself out of the server Once finished, save the file and reboot the server. Now, running `ip a` command should return correct IPv4 and IPv6 addresses. -Finally re-run `network_tunnel_manager.sh` script, following the steps in node [IPv6 configuration chapter](https://github.com/nymtech/nym/nodes/configuration.md#ipv6-configuration). +Finally re-run `network_tunnel_manager.sh` script, following the steps in node [IPv6 configuration chapter](../nodes/configuration.md#ipv6-configuration). ## Other VPS troubleshooting