fixed broken links in dev portal + moved a bunch of files from docs -> dev portal
This commit is contained in:
mfahampshire
@@ -59,6 +59,9 @@
|
||||
- [RPC Nodes](nyx/rpc-node.md)
|
||||
- [Ledger Live Support](nyx/ledger-live.md)
|
||||
|
||||
# Tools
|
||||
- [NymCLI](tools/nym-cli.md)
|
||||
|
||||
# User Manuals
|
||||
- [NymVPN alpha](nymvpn/intro.md)
|
||||
- [CLI](nymvpn/cli.md)
|
||||
|
||||
@@ -8,7 +8,7 @@ Nym has two main codebases:
|
||||
- the [Nym platform](https://github.com/nymtech/nym), written in Rust. This contains all of our code _except_ for the validators.
|
||||
- the [Nym validators](https://github.com/nymtech/nyxd), written in Go.
|
||||
|
||||
> This page details how to build the main Nym platform code. **If you want to build and run a validator, [go here](../../../docs/src/nodes/validator.md) instead.**
|
||||
> This page details how to build the main Nym platform code. **If you want to build and run a validator, [go here](https://nymtech.net/operators/nodes/validator.md) instead.**
|
||||
|
||||
## Prerequisites
|
||||
- Debian/Ubuntu: `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq`, `git`
|
||||
@@ -54,19 +54,18 @@ cargo build --release # build your binaries with **mainnet** configuration
|
||||
|
||||
Quite a bit of stuff gets built. The key working parts are:
|
||||
|
||||
* [mix node](../../../docs/src/nodes/mixnode.md): `nym-mixnode`
|
||||
* [gateway node](../../../docs/src/nodes/gateway.md): `nym-gateway`
|
||||
* [mix node](https://nymtech.net/operators/nodes/mixnode.md): `nym-mixnode`
|
||||
* [gateway node](https://nymtech.net/operators/nodes/gateway.md): `nym-gateway`
|
||||
* [websocket client](../clients/websocket-client.md): `nym-client`
|
||||
* [socks5 client](../clients/socks5-client.md): `nym-socks5-client`
|
||||
* [network requester](../../../docs/src/nodes/network-requester.md): `nym-network-requester`
|
||||
* [nym-cli tool](../../../docs/src/tools/nym-cli.md): `nym-cli`
|
||||
* [network requester](https://nymtech.net/operators/nodes/network-requester.md): `nym-network-requester`
|
||||
* [nym-cli tool](../tools/nym-cli.md): `nym-cli`
|
||||
* [nym-api](https://nymtech.net/operators/nodes/nym-api.html): `nym-api`
|
||||
* [nymvisor](https://nymtech.net/operators/nodes/nymvisor-upgrade.html): `nymvisor`
|
||||
|
||||
[//]: # (* [nymvisor](https://nymtech.net/operators/nodes/nymvisor-upgrade.html): `nymvisor`)
|
||||
|
||||
The repository also contains Typescript applications which aren't built in this process. These can be built by following the instructions on their respective docs pages.
|
||||
* [Nym Wallet](../../../docs/src/wallet/desktop-wallet.md)
|
||||
* [Nym Connect](https://nymtech.net/developers/quickstart/nymconnect-gui.html)
|
||||
* [Network Explorer UI](../../../docs/src/explorers/mixnet-explorer.md)
|
||||
[//]: # (The repository also contains Typescript applications which aren't built in this process. These can be built by following the instructions on their respective docs pages.)
|
||||
[//]: # (* [Nym Wallet](../../../docs/src/wallet/desktop-wallet.md))
|
||||
[//]: # (* [Nym Connect](https://nymtech.net/developers/quickstart/nymconnect-gui.html))
|
||||
[//]: # (* [Network Explorer UI](../../../docs/src/explorers/mixnet-explorer.md))
|
||||
|
||||
> 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.
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
# Client Binaries
|
||||
@@ -1,6 +1,6 @@
|
||||
# Socks5 Client
|
||||
|
||||
> The Nym socks5 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.
|
||||
> The Nym socks5 client was built in the [building nym](./building-nym.md) section. If you haven't yet built Nym and want to run the code on this page, go there first.
|
||||
|
||||
## Current version
|
||||
```
|
||||
@@ -60,153 +60,7 @@ There are 2 pieces of software that work together to send SOCKS traffic through
|
||||
The `nym-socks5-client` allows you to do the following from your local machine:
|
||||
* Take a TCP data stream from a application that can send traffic via SOCKS5.
|
||||
* Chop up the TCP stream into multiple Sphinx packets, assigning sequence numbers to them, while leaving the TCP connection open for more data
|
||||
* Send the Sphinx packets through the mixnet to a [network requester](../nodes/network-requester.md). Packets are shuffled and mixed as they transit the mixnet.
|
||||
* Send the Sphinx packets through the mixnet to a [network requester](https://nymtech.net/operators/nodes/network-requester.md). Packets are shuffled and mixed as they transit the mixnet.
|
||||
|
||||
The `nym-network-requester` then reassembles the original TCP stream using the packets' sequence numbers, and make the intended request. It will then chop up the response into Sphinx packets and send them back through the mixnet to your `nym-socks5-client`. The application will then receive its data, without even noticing that it wasn't talking to a "normal" SOCKS5 proxy!
|
||||
|
||||
## Client setup
|
||||
### Viewing command help
|
||||
|
||||
You can check that your binaries are properly compiled with:
|
||||
|
||||
```
|
||||
./nym-socks5-client --help
|
||||
```
|
||||
|
||||
~~~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:
|
||||
|
||||
```
|
||||
./nym-client <COMMAND> --help
|
||||
```
|
||||
|
||||
### 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 docs-example --use-reply-surbs true --provider Entztfv6Uaz2hpYHQJ6JKoaCTpDL5dja18SuQWVJAmmx.Cvhn9rBJw5Ay9wgHcbgCnVg89MPSV5s2muPV2YF1BXYu@Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf
|
||||
```
|
||||
|
||||
~~~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 `--use-reply-surbs` field denotes whether you wish to send [SURBs](../architecture/traffic-flow.md#private-replies-using-surbs) along with your request. It defaults to `false`, we are explicitly setting it as `true`. It defaults to `false` for compatibility with older versions of the [Network Requester](../nodes/network-requester.md).
|
||||
|
||||
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.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](../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.
|
||||
|
||||
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-selection` 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.
|
||||
|
||||
> 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
|
||||
When you initalise a client instance, a configuration directory will be generated and stored in `$HOME_DIR/.nym/socks5-clients/<client-name>/`.
|
||||
|
||||
```
|
||||
tree $HOME/<user>/.nym/socks5-clients/docs-example
|
||||
├── config
|
||||
│ └── config.toml
|
||||
└── data
|
||||
├── ack_key.pem
|
||||
├── credentials_database.db
|
||||
├── gateway_shared.pem
|
||||
├── persistent_reply_store.sqlite
|
||||
├── private_encryption.pem
|
||||
├── private_identity.pem
|
||||
├── public_encryption.pem
|
||||
└── public_identity.pem
|
||||
|
||||
```
|
||||
|
||||
The `config.toml` file contains client configuration options, while the two `pem` files contain client key information.
|
||||
|
||||
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`.
|
||||
|
||||
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.
|
||||
|
||||
### Running the socks5 client
|
||||
|
||||
You can run the initialised client by doing this:
|
||||
|
||||
```
|
||||
./nym-socks5-client run --id docs-example
|
||||
```
|
||||
|
||||
## Automating your socks5 client with systemd
|
||||
|
||||
Create a service file for the socks5 client at `/etc/systemd/system/nym-socks5-client.service`:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Nym Socks5 Client
|
||||
StartLimitInterval=350
|
||||
StartLimitBurst=10
|
||||
|
||||
[Service]
|
||||
User=nym # replace this with whatever user you wish
|
||||
LimitNOFILE=65536
|
||||
ExecStart=/home/nym/nym-socks5-client run --id <your_id>
|
||||
KillSignal=SIGINT
|
||||
Restart=on-failure
|
||||
RestartSec=30
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Now enable and start your socks5 client:
|
||||
|
||||
```
|
||||
systemctl enable nym-socks5-client.service
|
||||
systemctl start nym-socks5-client.service
|
||||
# you can always check your socks5 client has succesfully started with:
|
||||
systemctl status nym-socks5-client.service
|
||||
```
|
||||
|
||||
## Using your Socks5 Client
|
||||
|
||||
After completing the steps above, your local Socks5 Client will be listening on `localhost:1080` ready to proxy traffic to the Network Requester set as the `--provider` when initialising.
|
||||
|
||||
When trying to connect your app, generally the proxy settings are found in `settings->advanced` or `settings->connection`.
|
||||
|
||||
Here is an example of setting the proxy connecting in Blockstream Green:
|
||||
|
||||
|
||||
|
||||
Most wallets and other applications will work basically the same way: find the network proxy settings, enter the proxy url (host: **localhost**, port: **1080**).
|
||||
|
||||
In some other applications, this might be written as **localhost:1080** if there's only one proxy entry field.
|
||||
|
||||
## Useful Commands
|
||||
|
||||
**no-banner**
|
||||
|
||||
Adding `--no-banner` startup flag will prevent Nym banner being printed even if run in tty environment.
|
||||
|
||||
**build-info**
|
||||
|
||||
A `build-info` command prints the build information like commit hash, rust version, binary version just like what command `--version` does. However, you can also specify an `--output=json` flag that will format the whole output as a json, making it an order of magnitude easier to parse.
|
||||
|
||||
@@ -1 +1,145 @@
|
||||
# Setup Guide
|
||||
## Client setup
|
||||
### Viewing command help
|
||||
|
||||
You can check that your binaries are properly compiled with:
|
||||
|
||||
```
|
||||
./nym-socks5-client --help
|
||||
```
|
||||
|
||||
~~~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:
|
||||
|
||||
```
|
||||
./nym-client <COMMAND> --help
|
||||
```
|
||||
|
||||
### 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 docs-example --use-reply-surbs true --provider Entztfv6Uaz2hpYHQJ6JKoaCTpDL5dja18SuQWVJAmmx.Cvhn9rBJw5Ay9wgHcbgCnVg89MPSV5s2muPV2YF1BXYu@Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf
|
||||
```
|
||||
|
||||
~~~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 `--use-reply-surbs` field denotes whether you wish to send [SURBs](https://nymtech.net/docs/architecture/traffic-flow.md#private-replies-using-surbs) along with your request. It defaults to `false`, we are explicitly setting it as `true`. It defaults to `false` for compatibility with older versions of the [Network Requester](https://nymtech.net/operators/nodes/network-requester.md).
|
||||
|
||||
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/).
|
||||
|
||||
#### 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-selection` 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.
|
||||
|
||||
> 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
|
||||
When you initalise a client instance, a configuration directory will be generated and stored in `$HOME_DIR/.nym/socks5-clients/<client-name>/`.
|
||||
|
||||
```
|
||||
tree $HOME/<user>/.nym/socks5-clients/docs-example
|
||||
├── config
|
||||
│ └── config.toml
|
||||
└── data
|
||||
├── ack_key.pem
|
||||
├── credentials_database.db
|
||||
├── gateway_shared.pem
|
||||
├── persistent_reply_store.sqlite
|
||||
├── private_encryption.pem
|
||||
├── private_identity.pem
|
||||
├── public_encryption.pem
|
||||
└── public_identity.pem
|
||||
|
||||
```
|
||||
|
||||
The `config.toml` file contains client configuration options, while the two `pem` files contain client key information.
|
||||
|
||||
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`.
|
||||
|
||||
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.
|
||||
|
||||
### Running the socks5 client
|
||||
|
||||
You can run the initialised client by doing this:
|
||||
|
||||
```
|
||||
./nym-socks5-client run --id docs-example
|
||||
```
|
||||
|
||||
## Automating your socks5 client with systemd
|
||||
|
||||
Create a service file for the socks5 client at `/etc/systemd/system/nym-socks5-client.service`:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Nym Socks5 Client
|
||||
StartLimitInterval=350
|
||||
StartLimitBurst=10
|
||||
|
||||
[Service]
|
||||
User=nym # replace this with whatever user you wish
|
||||
LimitNOFILE=65536
|
||||
ExecStart=/home/nym/nym-socks5-client run --id <your_id>
|
||||
KillSignal=SIGINT
|
||||
Restart=on-failure
|
||||
RestartSec=30
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Now enable and start your socks5 client:
|
||||
|
||||
```
|
||||
systemctl enable nym-socks5-client.service
|
||||
systemctl start nym-socks5-client.service
|
||||
# you can always check your socks5 client has succesfully started with:
|
||||
systemctl status nym-socks5-client.service
|
||||
```
|
||||
|
||||
## Using your Socks5 Client
|
||||
|
||||
After completing the steps above, your local Socks5 Client will be listening on `localhost:1080` ready to proxy traffic to the Network Requester set as the `--provider` when initialising.
|
||||
|
||||
When trying to connect your app, generally the proxy settings are found in `settings->advanced` or `settings->connection`.
|
||||
|
||||
Here is an example of setting the proxy connecting in Blockstream Green:
|
||||
|
||||
|
||||
|
||||
Most wallets and other applications will work basically the same way: find the network proxy settings, enter the proxy url (host: **localhost**, port: **1080**).
|
||||
|
||||
In some other applications, this might be written as **localhost:1080** if there's only one proxy entry field.
|
||||
|
||||
## Useful Commands
|
||||
|
||||
**no-banner**
|
||||
|
||||
Adding `--no-banner` startup flag will prevent Nym banner being printed even if run in tty environment.
|
||||
|
||||
**build-info**
|
||||
|
||||
A `build-info` command prints the build information like commit hash, rust version, binary version just like what command `--version` does. However, you can also specify an `--output=json` flag that will format the whole output as a json, making it an order of magnitude easier to parse.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 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.
|
||||
> The Nym Websocket Client was built in the [building nym](./building-nym.md) section. If you haven't yet built Nym and want to run the code on this page, go there first.
|
||||
|
||||
## Current version
|
||||
```
|
||||
|
||||
@@ -58,7 +58,7 @@ In some applications, e.g. where people are chatting with friends who they know,
|
||||
|
||||
**If that fits your security model, good. However, will probably be the case that you want to send anonymous replies using Single Use Reply Blocks (SURBs)**.
|
||||
|
||||
You can read more about SURBs [here](../../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 client address**.
|
||||
You can read more about SURBs [here](https://nymtech.net/docs/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 client address**.
|
||||
|
||||
Your client will send along a number of `replySurbs` to the recipient of the message. These are pre-addressed Sphinx packets that the recipient can write to the payload of (i.e. write response data to), but not view the final destination of. If the recipient is unable to fit the response data into the bucket of SURBs sent to it, it will use a SURB to request more SURBs be sent to it from your client.
|
||||
|
||||
|
||||
@@ -198,7 +198,7 @@ For the moment then yes, the mixnet is free to use. There are no limits on the a
|
||||
No, although we do recommend that apps that wish to integrate look into running some of their own infrastructure such as gateways in order to assure uptime.
|
||||
|
||||
### How can I find out if an application is already supported by network requester services?
|
||||
You can check the [default allowed list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) file to see which application traffic is whitelisted by default. If the domain is present on that list, it means that existing [network requesters](https://nymtech.net/docs/nodes/network-requester.html) can be used to privacy-protect your application traffic. Simply use [NymConnect](../quickstart/nymconnect-gui.md) to connect to this service through the mixnet.
|
||||
You can check the [default allowed list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) file to see which application traffic is whitelisted by default. If the domain is present on that list, it means that existing [network requesters](https://nymtech.net/docs/nodes/network-requester.html) can be used to privacy-protect your application traffic.
|
||||
|
||||
Currently we are undergoing changes on this policy under the name [Project Smoosh](https://nymtech.net/operators/faq/smoosh-faq.html) where a new type of node [Exit Gateway](https://nymtech.net/operators/legal/exit-gateway.html) will allow users to connect to much wider range of domains, restricted by our new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). Follow the changes [here](https://nymtech.net/operators/faq/smoosh-faq.html#what-are-the-changes).
|
||||
|
||||
|
||||
@@ -1,106 +0,0 @@
|
||||
# Glossary
|
||||
|
||||
__Familiarise yourself with Nym's specific terms and jargon through our glossary, making your understanding of Nym technology more enjoyable and educational.__
|
||||
|
||||
## A
|
||||
**[Address](https://nymtech.net/docs/stable/integrations/addresses-in-nym/)** - A unique string of characters generated from a client keypair. Used to identify clients in the mixnet.
|
||||
|
||||
**[Ack](https://nymtech.net/docs/architecture/traffic-flow.html#acks--package-retransmission)** - Short for "acknowledgement". Whenever a hop is completed, the recieving node will send back an 'ack', so that the sending node knows that the packet was recieved.
|
||||
|
||||
**Attacker** - A person or entity who attempts to gain unauthorised access to a computer system, network, or other information resource.
|
||||
|
||||
## B
|
||||
**Binary** - Is a type of computer file that contains machine code, which is a set of instructions that a computer can execute directly. The file consists of a series of 1s and 0s, which are the two digits used in the binary number system.
|
||||
|
||||
**Blockchain** - A distributed database that maintains a continuously growing list of ordered records, called blocks.
|
||||
|
||||
## C
|
||||
**[Coconut](https://nymtech.net/docs/stable/coconut/)** - A distributed cryptographic signing scheme providing a high degree of privacy for its users.
|
||||
|
||||
**[CLI](https://nymtech.net/docs/stable/nym-cli/)** - A command-line interface (CLI) is a text-based user interface (UI) used to run programs, manage computer files and interact with the computer.
|
||||
|
||||
**Credentials** - Unique values that prove the legitimacy of a user or individual.
|
||||
|
||||
**Centralisation** - Refers to the concentration of control of an activity or organisation under a single authority, or small group of authorities.
|
||||
|
||||
**[CosmWasm](https://cosmwasm.com)** - Cosmos WebAssembly is a WebAssembly (Wasm) interpreter that is used in the Cosmos SDK, a framework for building decentralised applications (dApps) on the Cosmos network. It allows us to write smart contracts in Rust and then compile them to webassembly to be uploaded on the blockchain.
|
||||
|
||||
## D
|
||||
**DAO** - Stands for Decentralised Autonomous Organisation. A type of organisation made up of smart contracts on a blockchain. It operates on a set of rules encoded in a computer program, and is governed by the people who use it, rather than by a central authority.
|
||||
|
||||
**[Delegating NYM](https://medium.com/coinmonks/what-you-have-to-know-about-staking-and-delegating-458b6d2300a5)** - Similar to bonding but by non-operators and as proof of their trust in a node operator providing a good quality of service.
|
||||
|
||||
**Decentralisation** - Refers to the transfer of control and decision-making from a centralised entity (individual, organization, or group thereof) to a distributed network.
|
||||
|
||||
## E
|
||||
**Encryption** - The process of encoding information.
|
||||
|
||||
## G
|
||||
**[Gateways](https://blog.nymtech.net/gateways-to-privacy-51196005bf5)** - The entrance to the mixnet that encrypted packets must pass through before being forwarded to mix nodes. They also act as a sort of mailbox for messages.
|
||||
|
||||
**[Gateway Bonding](https://nymtech.net/docs/stable/run-nym-nodes/nodes/gateways/#bonding-your-gateway)** - The action of node operators to bond their stake (in the form of NYM tokens) to a Gateway in order to join the network topology and begin routing traffic through.
|
||||
|
||||
## I
|
||||
**IPFS** - Stands for InterPlanetary File System. It's a decentralised, peer-to-peer protocol for sharing and storing files. It is designed to make it easier to share and access large amounts of data in a distributed manner, without the need for a central server or authority
|
||||
|
||||
## M
|
||||
**[Metadata](https://www.opendatasoft.com/en/blog/what-is-metadata-and-why-is-it-important-data)** - A set of data that describes and gives information about other data such as IP addresses, device types, geolocations etc.
|
||||
|
||||
**[Mixnet](https://nymtech.net/docs/architecture/traffic-flow.html#mixnet-traffic-flow-1)** - A routing protocol which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom.
|
||||
|
||||
**[Mix Nodes](https://blog.nymtech.net/nym-mixnodes-deep-dive-d2b91917f097)** - The backbone of the Nym infrastructure, that are organised in a three-layer network referred to as the mixnet that network traffic passes through. It mixes, hides and reorders traffic and are rewarded in NYM tokens for their quality of service.
|
||||
|
||||
**[Mix node Bonding](https://nymtech.net/docs/stable/run-nym-nodes/nodes/mixnodes/#bonding-your-mix-node)** - The action of node operators bonding their stake (in the form of NYM tokens) to a Mix node in order to join the network topology and begin routing traffic through.
|
||||
|
||||
## N
|
||||
**[Network Requester](https://nymtech.net/docs/stable/run-nym-nodes/nodes/requester)** - Is a binary that can be ran alongside a Nym Client on a VPS, which allows for private network requests to be made outside the mixnet from you local Nym client
|
||||
|
||||
**Nym** - The in-text name of the organisation.
|
||||
|
||||
**[Nym Typescript SDK](https://nymtech.net/docs/stable/sdk/overview)** - A Typescript software development kit which allows developers to build browser-based Mixnet application.
|
||||
|
||||
**[NYM](https://nymtech.net/docs/stable/nym-cli/#send-tokens-to-an-account)** - Natively distributed token.
|
||||
|
||||
**[Nym Wallet](https://nymtech.net/docs/stable/wallet/)** - The Nym Wallet handles all things regarding handling Nym Tokens about your Nym Node. It is a GUI application that can be downloaded and run on your machine.
|
||||
|
||||
**[Nym Technologies SA](https://nymtech.net)** - The official company name.
|
||||
|
||||
**[Nyx](https://nymtech.net/docs/stable/integrations/payment-integration-overview/)** - A CosmWasm-enabled blockchain smart contracts platform that functions as the backbone of the Nym network, used to keep track and provide the history of the NYM token's transactions.
|
||||
|
||||
## P
|
||||
**Payload** - The carrying capacity of a packet or other transmission data unit.
|
||||
|
||||
**Pledge** - The number of tokens that are put up by node operators on their nodes as their commitment to provide good quality of service and insure against future bad behaviour.
|
||||
|
||||
**Private Key** - A large numerical value that is used to decrypt data.
|
||||
|
||||
**Proof-of-Mixing** - The reward of NYM tokens is based on the good quality of service carried out by node operators.
|
||||
|
||||
**POC** - Stands for Proof of Concept. It's a demonstration that a proposed product, system, or service can be built and will work as intended. It is a way of testing whether an idea is feasible and likely to succeed.
|
||||
|
||||
**Public Key** - A large numerical value that is used to encrypt data.
|
||||
|
||||
## S
|
||||
**Sphinx** - A cryptographic message format used to relay anonymised messages within the mixnet, also used by the Lightning Network or something similar.
|
||||
|
||||
**[Socks5](https://en.wikipedia.org/wiki/SOCKS)** - An proxy protocol that exchanges network packets between a client and server through a proxy server.
|
||||
|
||||
**[Service Provider](https://nymtech.net/docs/stable/tutorials/nym-simple-websocket-tutorial/)** - Any type of app that can communicate with the mixnet via a Nym Client.
|
||||
|
||||
**[SURBs](https://nymtech.net/docs/architecture/traffic-flow.html#private-replies-using-surbs)** - Stands for 'Single Use Reply Blocks'. They are a type of crytographic construct used to facilitate secure communication between parties and are designed to allow a sender to send a message to a recipient in sucha a way that the message can only be read by the intended recipient, and cannot be read by anyone else.
|
||||
|
||||
**Sybil** - In the context of computer networks, a Sybil attach is a type of security attack in which an attacker creates multiple fake identities or "sybils" and uses them to manipulate a network thus gaining control of a network by overwhelming it.
|
||||
|
||||
## T
|
||||
**Tokenomics** - Is the study of the economic and financial aspects of a cryptocurrency or blockchain-based project. It involves the creation, distribution, and management of tokens, which are digital assets that represent a certain value of utility whithin a particular ecosystem.
|
||||
|
||||
## V
|
||||
**[Validators](https://nymtech.net/docs/stable/run-nym-nodes/nodes/validators/)** - Secures the Nyx blockchain with a staking token, defending the network from attacks.
|
||||
|
||||
**[VPS](https://en.wikipedia.org/wiki/Virtual_private_server)** - Stands for Virtual Private Server. Its a virtual machine that acts as an isolated virtual environment on a physical server operated by a cloud, web or internet hosting provider.
|
||||
|
||||
## W
|
||||
**Websocket** - A computer communications protocol that provides a full-duplex channel over a single TCP connection. It is designed to be used as a base for real-time, two-way communication between a client and a server over the web.
|
||||
|
||||
## Z
|
||||
**Zero Knowledge Proofs** - Cryptographic techniques that make it possible to prove something to be true without having to reveal the evidence.
|
||||
@@ -1,13 +1,11 @@
|
||||
# Integration Options
|
||||
If you've already gone through the different [Quick Start](../quickstart/overview.md) options and had a look at the tutorials, you have seen the possibilities available to you for quickly connecting existing application code to another Nym process.
|
||||
|
||||
Below are a resources that will be useful for either beginning to integrate mixnet functionality into existing application code or build a new app using Nym.
|
||||
|
||||
- **We suggest you begin with this [integration decision tree](https://sdk.nymtech.net/integrations)**. This will give you a better idea of what pieces of software (SDKs, standalone clients, service providers) your integration might involve, and what is currently possible to do with as little custom code as possible.
|
||||
|
||||
- The [integrations FAQ](../faq/integrations-faq.md) has a list of common questions regarding integrating with Nym and Nyx, as well as commonly required links.
|
||||
|
||||
- To get an idea of what is possible / has already been built, check the [community applications and resources](../community-resources/community-applications-and-guides.md) page, as well as the [developer tutorials codebase](https://github.com/nymtech/developer-tutorials).
|
||||
- To get an idea of what is possible / has already been built, check the [community applications and resources](../community-resources/community-applications-and-guides.md) page.
|
||||
|
||||
> If you wish to integrate with the Nyx blockchain to use `NYM` for payments, start with the [payment integration](./payment-integration.md) page.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
If you want to integrate with Nym in order to send `NYM` tokens (for instance, if running a `NYM` <-> `BTC` swap application, or using `NYM` for payments), then you will need to interact with the Nyx blockchain.
|
||||
|
||||
Nyx is the blockchain supporting the Nym network, hosting both the `NYM` and `NYX` cryptocurrencies, the CosmWasm smart contracts keeping track of the network, and (coming soon) facilitating zk-Nym credential generation. It is built with the [Cosmos SDK](https://tendermint.com/sdk/).
|
||||
Nyx is the blockchain supporting the Nym network, hosting both the `NYM` and `NYX` cryptocurrencies, the CosmWasm smart contracts keeping track of the network, and facilitating zk-Nym credential generation. It is built with the [Cosmos SDK](https://tendermint.com/sdk/).
|
||||
|
||||
### Interacting with the Nyx blockchain
|
||||
Check out the integration options in the [Integration FAQ](../faq/integrations-faq.md#how-can-i-use-json-rpc-methods-to-interact-with-the-nyx-blockchain).
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# Interacting with Nyx Chain and Smart Contracts
|
||||
|
||||
There are two options for interacting with the blockchain to send tokens or interact with deployed smart contracts:
|
||||
* [`Nym-CLI`](../../../docs/src/tools/nym-cli.md) tool
|
||||
* [`Nym-CLI`](../tools/nym-cli.md) tool
|
||||
* `nyxd` binary
|
||||
|
||||
## Nym-CLI tool (recommended in most cases)
|
||||
The `nym-cli` tool is a binary offering a simple interface for interacting with deployed smart contract (for instance, bonding and unbonding a mix node from the CLI), as well as creating and managing accounts and keypairs, sending tokens, and querying the blockchain.
|
||||
|
||||
Instructions on how to do so can be found on the [`nym-cli` docs page](../../../docs/src/tools/nym-cli.md), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html).
|
||||
Instructions on how to do so can be found on the [`nym-cli` docs page](../tools/nym-cli.md), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html).
|
||||
|
||||
## Nyxd binary
|
||||
The `nyxd` binary, although more complex to compile and use, offers the full range of commands availiable to users of CosmosSDK chains. Use this if you are (e.g.) wanting to perform more granular queries about transactions from the CLI.
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Coconut credential generation
|
||||
The following code shows how you can use the SDK to create and use a [credential](../../../bandwidth-credentials.md) representing paid bandwidth on the Sandbox testnet.
|
||||
The following code shows how you can use the SDK to create and use a [credential](https://nymtech.net/docs/bandwidth-credentials.md) representing paid bandwidth on the Sandbox testnet.
|
||||
|
||||
```rust,noplayground
|
||||
{{#include ../../../../../../sdk/rust/nym-sdk/examples/bandwidth.rs}}
|
||||
```
|
||||
|
||||
You can read more about Coconut credentials (also referred to as `zk-Nym`) [here](../../../coconut.md).
|
||||
You can read more about Coconut credentials (also referred to as `zk-Nym`) [here](https://nymtech.net/docs/coconut.md).
|
||||
|
||||
|
||||
@@ -1,13 +1,11 @@
|
||||
# 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.
|
||||
|
||||
The number of SURBs is set [here](https://github.com/nymtech/nym/blob/master/sdk/rust/nym-sdk/src/mixnet/client.rs#L33).
|
||||
|
||||
```rust,noplayground
|
||||
{{#include ../../../../../../sdk/rust/nym-sdk/src/mixnet/client.rs:33}}
|
||||
```
|
||||
|
||||
You can read more about how SURBs function under the hood [here](../../../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.md#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:
|
||||
|
||||
|
||||
@@ -24,9 +24,6 @@
|
||||
- [Coconut](coconut.md)
|
||||
- [Bandwidth Credentials](bandwidth-credentials.md)
|
||||
|
||||
# Tools
|
||||
- [NymCLI](tools/nym-cli.md)
|
||||
|
||||
---
|
||||
# Misc.
|
||||
- [Code of Conduct](coc.md)
|
||||
|
||||
@@ -34,7 +34,7 @@ If you really don't want to use the shell script installer, the [Rust installati
|
||||
|
||||
|
||||
### Local Development
|
||||
Complete the steps in the [building nym](../../../dev-portal/src/clients/building-nym.md) section, before `cd`-ing into `nym/explorer`.
|
||||
Complete the steps in the [building nym]() section, before `cd`-ing into `nym/explorer`.
|
||||
|
||||
Start a development server with hot reloading running on `http://localhost:3000` with the following commands from inside the `explorer` directory:
|
||||
|
||||
@@ -63,7 +63,7 @@ npm run lint:fix
|
||||
Please see the development docs in `explorer/docs` for more information on the structure and design of this app.
|
||||
|
||||
### Deployment
|
||||
Complete the steps in the [building nym](../../../dev-portal/src/clients/building-nym.md) section, before `cd`-ing into `nym/explorer`.
|
||||
Complete the steps in the [building nym]() section, before `cd`-ing into `nym/explorer`.
|
||||
|
||||
> The Network Explorer should be run on a machine with at least 4GB of RAM - the build process might fail if run on a less powerful machine.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Gateways are key to both the usability of the mixnet, and the operation of the mixnet's tokenomics. They serve two main functions:
|
||||
* In the future (when the mixnet is no longer running in 'free to use' mode), to check for zkNym credentials (previously referred to as [Coconut Credentials](../bandwidth-credentials.md)) with which users can anonymously prove they have paid to send traffic through the mixnet. A % of the worth of these credentials will be distributed to the operator of the gateway periodically as payment for providing their service. The more credentials user clients 'spend' with them, the higher the rewards for the gateway operator and their delegators will be. The rest of this value will be sent to the Mixmining Pool, a pool of tokens from which `NYM` rewards are distributed to mix node operators.
|
||||
* Act as a mailbox for connected clients. Clients create a lasting relationship with a gateway on initialisation, binding themselves to always use a particular gateway as their ingress point for mixnet traffic (this also means that this gateway is the egress point for any traffic sent _to_ this client - see the [mixnet traffic flow page](../architecture/traffic-flow.md) and the [addressing scheme](../clients/addressing-system.md) for further details). If a client is offline and the Gateway can't deliver packets addressed to it, they will hold these packets until the client comes back online.
|
||||
* Act as a mailbox for connected clients. Clients create a lasting relationship with a gateway on initialisation, binding themselves to always use a particular gateway as their ingress point for mixnet traffic (this also means that this gateway is the egress point for any traffic sent _to_ this client - see the [mixnet traffic flow page]() and the [addressing scheme]() for further details). If a client is offline and the Gateway can't deliver packets addressed to it, they will hold these packets until the client comes back online.
|
||||
|
||||
## Further Reading
|
||||
* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4.2
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Validators secure the Nyx blockchain via Proof of Stake consensus. The Nyx blockchain records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. The Nyx validators are run via the `nyxd` binary ([codebase](https://github.com/nymtech/nyxd)), maintaining a CosmWasm- and IBC-enabled blockchain.
|
||||
|
||||
The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet](../../../dev-portal/src/nyx/mixnet-contract.md) and [Vesting](../../../dev-portal/src/nyx/vesting-contract.md) smart contracts are deployed.
|
||||
The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet]() and [Vesting]() smart contracts are deployed.
|
||||
|
||||
## Further Reading
|
||||
* Detailed info on Nyx Validators and token flow can be found in [Nym Reward Sharing for Mixnets document](https://nymtech.net/nym-cryptoecon-paper.pdf) in section 2.3 and 2.4.
|
||||
|
||||
@@ -5,4 +5,4 @@ If you have already read our validator setup and maintenance [documentation](htt
|
||||
### Using `nyxd` binary as a CLI wallet
|
||||
You can use the `nyxd` as a minimal CLI wallet if you want to set up an account (or multiple accounts). Just compile the binary as per the documentation, **stopping after** the [building your validator](https://nymtech.net/operators/nodes/validator-setup.html#building-your-validator) step is complete. You can then run `nyxd keys --help` to see how you can set up and store different keypairs with which to interact with the Nyx blockchain.
|
||||
|
||||
For more on interacting with the chain, see the [Interacting with Nyx Chain and Smart Contracts](../../../dev-portal/src/nyx/interacting-with-chain.md) page.
|
||||
For more on interacting with the chain, see the [Interacting with Nyx Chain and Smart Contracts]() page.
|
||||
|
||||
Reference in New Issue
Block a user