diff --git a/documentation/old_docs/dev-portal/.gitignore b/documentation/old_docs/dev-portal/.gitignore deleted file mode 100644 index 1451d34afd..0000000000 --- a/documentation/old_docs/dev-portal/.gitignore +++ /dev/null @@ -1,24 +0,0 @@ -# Generated by Cargo -# will have compiled files and executables -/target/ - -# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries -# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html -Cargo.lock - -# These are backup files generated by rustfmt -**/*.rs.bk - -# Book specific -book - -# OSX -.DS_Store - -theme/ -theme -theme/* - -.idea - -notes \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/LICENSE b/documentation/old_docs/dev-portal/LICENSE deleted file mode 100644 index 261eeb9e9f..0000000000 --- a/documentation/old_docs/dev-portal/LICENSE +++ /dev/null @@ -1,201 +0,0 @@ - Apache License - Version 2.0, January 2004 - http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - "Contribution" shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, "submitted" - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but not limited to - communication on electronic mailing lists, source code control systems, - and issue tracking systems that are managed by, or on behalf of, the - Licensor for the purpose of discussing and improving the Work, but - excluding communication that is conspicuously marked or otherwise - designated in writing by the copyright owner as "Not a Contribution." - - "Contributor" shall mean Licensor and any individual or Legal Entity - on behalf of whom a Contribution has been received by Licensor and - subsequently incorporated within the Work. - - 2. Grant of Copyright License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - copyright license to reproduce, prepare Derivative Works of, - publicly display, publicly perform, sublicense, and distribute the - Work and such Derivative Works in Source or Object form. - - 3. Grant of Patent License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - (except as stated in this section) patent license to make, have made, - use, offer to sell, sell, import, and otherwise transfer the Work, - where such license applies only to those patent claims licensable - by such Contributor that are necessarily infringed by their - Contribution(s) alone or by combination of their Contribution(s) - with the Work to which such Contribution(s) was submitted. If You - institute patent litigation against any entity (including a - cross-claim or counterclaim in a lawsuit) alleging that the Work - or a Contribution incorporated within the Work constitutes direct - or contributory patent infringement, then any patent licenses - granted to You under this License for that Work shall terminate - as of the date such litigation is filed. - - 4. Redistribution. You may reproduce and distribute copies of the - Work or Derivative Works thereof in any medium, with or without - modifications, and in Source or Object form, provided that You - meet the following conditions: - - (a) You must give any other recipients of the Work or - Derivative Works a copy of this License; and - - (b) You must cause any modified files to carry prominent notices - stating that You changed the files; and - - (c) You must retain, in the Source form of any Derivative Works - that You distribute, all copyright, patent, trademark, and - attribution notices from the Source form of the Work, - excluding those notices that do not pertain to any part of - the Derivative Works; and - - (d) If the Work includes a "NOTICE" text file as part of its - distribution, then any Derivative Works that You distribute must - include a readable copy of the attribution notices contained - within such NOTICE file, excluding those notices that do not - pertain to any part of the Derivative Works, in at least one - of the following places: within a NOTICE text file distributed - as part of the Derivative Works; within the Source form or - documentation, if provided along with the Derivative Works; or, - within a display generated by the Derivative Works, if and - wherever such third-party notices normally appear. The contents - of the NOTICE file are for informational purposes only and - do not modify the License. You may add Your own attribution - notices within Derivative Works that You distribute, alongside - or as an addendum to the NOTICE text from the Work, provided - that such additional attribution notices cannot be construed - as modifying the License. - - You may add Your own copyright statement to Your modifications and - may provide additional or different license terms and conditions - for use, reproduction, or distribution of Your modifications, or - for any such Derivative Works as a whole, provided Your use, - reproduction, and distribution of the Work otherwise complies with - the conditions stated in this License. - - 5. Submission of Contributions. Unless You explicitly state otherwise, - any Contribution intentionally submitted for inclusion in the Work - by You to the Licensor shall be under the terms and conditions of - this License, without any additional terms or conditions. - Notwithstanding the above, nothing herein shall supersede or modify - the terms of any separate license agreement you may have executed - with Licensor regarding such Contributions. - - 6. Trademarks. This License does not grant permission to use the trade - names, trademarks, service marks, or product names of the Licensor, - except as required for reasonable and customary use in describing the - origin of the Work and reproducing the content of the NOTICE file. - - 7. Disclaimer of Warranty. Unless required by applicable law or - agreed to in writing, Licensor provides the Work (and each - Contributor provides its Contributions) on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - implied, including, without limitation, any warranties or conditions - of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A - PARTICULAR PURPOSE. You are solely responsible for determining the - appropriateness of using or redistributing the Work and assume any - risks associated with Your exercise of permissions under this License. - - 8. Limitation of Liability. In no event and under no legal theory, - whether in tort (including negligence), contract, or otherwise, - unless required by applicable law (such as deliberate and grossly - negligent acts) or agreed to in writing, shall any Contributor be - liable to You for damages, including any direct, indirect, special, - incidental, or consequential damages of any character arising as a - result of this License or out of the use or inability to use the - Work (including but not limited to damages for loss of goodwill, - work stoppage, computer failure or malfunction, or any and all - other commercial damages or losses), even if such Contributor - has been advised of the possibility of such damages. - - 9. Accepting Warranty or Additional Liability. While redistributing - the Work or Derivative Works thereof, You may choose to offer, - and charge a fee for, acceptance of support, warranty, indemnity, - or other liability obligations and/or rights consistent with this - License. However, in accepting such obligations, You may act only - on Your own behalf and on Your sole responsibility, not on behalf - of any other Contributor, and only if You agree to indemnify, - defend, and hold each Contributor harmless for any liability - incurred by, or claims asserted against, such Contributor by reason - of your accepting any such warranty or additional liability. - - END OF TERMS AND CONDITIONS - - APPENDIX: How to apply the Apache License to your work. - - To apply the Apache License to your work, attach the following - boilerplate notice, with the fields enclosed by brackets "[]" - replaced with your own identifying information. (Don't include - the brackets!) The text should be enclosed in the appropriate - comment syntax for the file format. We also recommend that a - file or class name and description of purpose be included on the - same "printed page" as the copyright notice for easier - identification within third-party archives. - - Copyright [yyyy] [name of copyright owner] - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. diff --git a/documentation/old_docs/dev-portal/README.md b/documentation/old_docs/dev-portal/README.md deleted file mode 100644 index 0b53b8e984..0000000000 --- a/documentation/old_docs/dev-portal/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Nym Developer Portal -Developer Portal for the Nym privacy platform built using the [mdBook](https://rust-lang.github.io/mdBook/) docs framework. Deployed version can be found [here](https://nymtech.net/developers). - -## Contributing -Contributions to our documentation are very welcome. Please work on your contribution in either a `feature/` or `chore/` branch from `master` and target your pull request at `master`. - -Changes merged to `master` will be autodeployed to the production site. - -### Adding community projects and resources -If you have built a project with Nym or are compiling and writing resources about Nym, we want to include your work in the `community-resources/` section to share with the rest of the community! Just follow the existing formatting and add your project to the page, then put in a pull request. - -## Variables -There are some variables that are shared across this book, such as the current latest software version. - -Variables are denoted in the `.md` files wrapped in `{{}}` (e.g `{{wallet_release_version}}`), and are located in the `book.toml` file under the `[preprocessor.variables.variables]` heading. If you are changing something like the software release version, minimum code versions in prerequisites, etc, **check in here first!** - -## Building -When working locally, it is recommended that you use `mdbook serve` to have a local version of the docs served on `localhost:3000`, with hot reloading on any changes made to files in the `src/` directory. - -You can find other commands in the [mdBook CLI tool docs](https://rust-lang.github.io/mdBook/cli/index.html). - -### I tried to edit files in `theme/` and they aren't taking effect / `mdbook serve` causes a looping reload on file changes after changing fields in `[preprocessor.theme]` config - -Looping reload is a known issue with the `mdbook-theme` preprocessor used for the table of contents and layout of these docs. As outlined in the `mdbook-theme` [readme](https://github.com/zjp-CN/mdbook-theme#avoid-repeating-call-on-this-tool-when-mdbook-watch) one way to mitigate this is to set `turn-off = true` under `[preprocessor.theme]`. This means that `mdbook serve` or `mdbook watch` ignores changes to the `theme/` directory, which is the source of the looping reload. If you have changed or commented out this line, reintroduce it to remove the looping reload. If you are trying to edit the theme of the docs and want to apply the change, see [here](https://github.com/zjp-CN/mdbook-theme#avoid-repeating-call-on-this-tool-when-mdbook-watch) for more info on how to remove the block, change the theme, and reintroduce the block. diff --git a/documentation/old_docs/dev-portal/book.toml b/documentation/old_docs/dev-portal/book.toml deleted file mode 100644 index e4bf22202c..0000000000 --- a/documentation/old_docs/dev-portal/book.toml +++ /dev/null @@ -1,118 +0,0 @@ -[book] -title = "Nym Docs" -authors = ["Max Hampshire, Serinko, Alexia Lorenza Martinel"] -description = "Nym technical documentation" -language = "en" -multilingual = false # for the moment - ideally work on chinese, brazillian ,portugese spanish next -src = "src" - -[rust] -edition = "2018" - -################# -# PREPROCESSORS # -################# - -[preprocessor.theme] -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`. -# this is because of a bug in the `mdbook-theme` plugin -turn-off = true - - -[preprocessor.admonish] -command = "mdbook-admonish" -assets_version = "3.0.2" # do not edit: managed by `mdbook-admonish install` - -# https://gitlab.com/tglman/mdbook-variables/ -[preprocessor.variables.variables] -minimum_rust_version = "1.66" -wallet_release_version = "1.2.8" -# nym-vpn related variables -nym_vpn_releases = "https://github.com/nymtech/nym-vpn-client/releases" -nym_vpn_form_url = "https://opnform.com/forms/nymvpn-user-research-at-37c3-yccqko-2" - -# versions are pulled by cmdrun now -# nym_vpn_gui_version = "0.0.6" -# nym_vpn_cli_version = "0.0.4" - -[preprocessor.last-changed] -command = "mdbook-last-changed" -renderer = ["html"] - -# used for grabbing output of binary commands for automation https://github.com/FauconFan/mdbook-cmdrun -[preprocessor.cmdrun] - -# more pre-processor plugins to look into from https://github.com/rust-lang/mdBook/wiki/Third-party-plugins & https://lib.rs/keywords/mdbook-preprocessor -# mdbook-i18n - -######### -# BUILD # -######### - -[build] -build-dir = "book" # the directory where the output is placed -create-missing = true # whether or not to create missing pages -use-default-preprocessors = true # use the default preprocessors -extra-watch-dirs = [] # directories to watch for triggering builds - -########## -# OUTPUT # -########## - -[output.html] -theme = "themes" -default-theme = "coal" -preferred-dark-theme = "coal" -curly-quotes = true -copy-fonts = true -no-section-label = false -additional-css = [ - "./themes/custom.css", - "./themes/mdbook-admonish.css", - "./themes/pagetoc.css", -] -additional-js = ["./themes/pagetoc.js"] -git-repository-url = "https://github.com/nymtech/nym" -git-repository-icon = "fa-github" -input-404 = "not-found.md" - -[output.html.fold] -enable = true # whether or not to enable section folding -level = 0 # the depth to start folding - -# controlling rust sample code blocks -[output.html.playground] -editable = false # allows editing the source code -copyable = true # include the copy button for copying code snippets -copy-js = true # includes the JavaScript for the code editor -line-numbers = true # displays line numbers for editable code -runnable = true # displays a run button for rust code - -# options for the built in text search -[output.html.search] -enable = true # enables the search feature -limit-results = 30 # maximum number of search results -teaser-word-count = 30 # number of words used for a search result teaser -use-boolean-and = true # multiple search terms must all match -boost-title = 2 # ranking boost factor for matches in headers -boost-hierarchy = 1 # ranking boost factor for matches in page names -boost-paragraph = 1 # ranking boost factor for matches in text -expand = true # partial words will match longer terms -heading-split-level = 3 # link results to heading levels -copy-js = true # include Javascript code for search - -[output.linkcheck] -warning-policy = "warn" - -[output.html.redirect] -"/faq/general-faq.html" = "https://nymtech.net/developers/faq/integrations-faq.html" -"/tutorials/simple-service-provider/user-client.html" = "https://nymtech.net/developers/examples/custom-services.html" -"/quickstart/socks-proxy.html" = "https://nymtech.net/developers/clients/socks5/setup.html" -"/tutorials/matrix.html" = "https://nymtech.net/developers/archive/nym-connect.html#matrix-element-via-nymconnect" -"/tutorials/monero.html" = "https://nymtech.net/developers/archive/nym-connect.html#monero-wallet-via-nymconnect" -"/tutorials/telegram.html" = "https://nymtech.net/developers/archive/nym-connect.html#telegram-via-nymconnect" diff --git a/documentation/old_docs/dev-portal/diagrams/example-app-flow-init.md b/documentation/old_docs/dev-portal/diagrams/example-app-flow-init.md deleted file mode 100644 index a378925a1f..0000000000 --- a/documentation/old_docs/dev-portal/diagrams/example-app-flow-init.md +++ /dev/null @@ -1,24 +0,0 @@ - +-----------+ - | Gateway | - +-----------+ - ^ - | - | - | - | - | - | - +-------------------+ - | +---------------+ | - | | Nym client | | - | +---------------+ | - | ^ | - | | | - | | | - | | | - | v | - | +---------------+ | - | | Your app code | | - | +---------------+ | - +-------------------+ - Your Local Machine \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/diagrams/mixnet-traffic-flow.md b/documentation/old_docs/dev-portal/diagrams/mixnet-traffic-flow.md deleted file mode 100644 index fbb0a4caaf..0000000000 --- a/documentation/old_docs/dev-portal/diagrams/mixnet-traffic-flow.md +++ /dev/null @@ -1,33 +0,0 @@ - - +----------+ +----------+ +----------+ - | Mix Node |<-----------> | Mix Node |<----------->| Mix Node | - | Layer 1 | | Layer 2 | | Layer 3 | - +----------+ +----------+ +----------+ - ^ ^ - | | - | | - v v - +--------------+ +-----------------+ - | Your gateway | | Service gateway | - +--------------+ +-----------------+ - ^ ^ - | | - | | - v v - +-------------------+ +-------------------+ - | +---------------+ | | +---------------+ | - | | Nym client | | | | Nym Client | | - | +---------------+ | | +---------------+ | - | ^ | | ^ | - | | | | | | - | | | | | | - | v | | v | - | +---------------+ | | +---------------+ | - | | Your app code | | | | Service Code | | - | +---------------+ | | +---------------+ | - +-------------------+ +-------------------+ - Your Local Machine** Service Provider Machine** - - -** note that depending on the technical setup, the Nym client running on these machines may -be either a seperate process or embedded in the same process as the app code via one of our SDKs. \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/diagrams/send-to-ourselves.md b/documentation/old_docs/dev-portal/diagrams/send-to-ourselves.md deleted file mode 100644 index 218a9d3330..0000000000 --- a/documentation/old_docs/dev-portal/diagrams/send-to-ourselves.md +++ /dev/null @@ -1,34 +0,0 @@ - - +----------+ +----------+ +----------+ - | Mix Node |<-----------> | Mix Node |<----------->| Mix Node | - | Layer 1 | | Layer 2 | | Layer 3 | - +----------+ +----------+ +----------+ - ^ ^ - | | - |<--------------------------------------------------+ - | - v - +--------------+ - | Your gateway | - +--------------+ - ^ - | - | - v - +-------------------+ - | +---------------+ | - | | Nym client | | - | +---------------+ | - | ^ | - | | | - | | | - | v | - | +---------------+ | - | | Your app code | | - | +---------------+ | - +-------------------+ - Your Local Machine** - - -** note that depending on the technical setup, the Nym client running on this machine may -be either a seperate process or embedded in the same process as the app code via one of our SDKs. \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/diagrams/templates/local-machine.md b/documentation/old_docs/dev-portal/diagrams/templates/local-machine.md deleted file mode 100644 index fa63a5cbff..0000000000 --- a/documentation/old_docs/dev-portal/diagrams/templates/local-machine.md +++ /dev/null @@ -1,14 +0,0 @@ -+-------------------+ -| +---------------+ | -| | Nym client | | -| +---------------+ | -| ^ | -| | | -| | | -| | | -| v | -| +---------------+ | -| | Your app code | | -| +---------------+ | -+-------------------+ - Your Local Machine \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/diagrams/templates/service-machine.md b/documentation/old_docs/dev-portal/diagrams/templates/service-machine.md deleted file mode 100644 index f9acb9d1e9..0000000000 --- a/documentation/old_docs/dev-portal/diagrams/templates/service-machine.md +++ /dev/null @@ -1,15 +0,0 @@ -+-------------------+ -| +---------------+ | -| | Nym client | | -| +---------------+ | -| ^ | -| | | -| | | -| | | -| v | -| +---------------+ | -| | Service code | | -| +---------------+ | -+-------------------+ - Service Machine - \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/archive/nym-connect.md b/documentation/old_docs/dev-portal/src/archive/nym-connect.md deleted file mode 100644 index 2dca063dd8..0000000000 --- a/documentation/old_docs/dev-portal/src/archive/nym-connect.md +++ /dev/null @@ -1,85 +0,0 @@ -# Archive page: NymConnect Setup - -```admonish warning -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 maintained [Nym Socks5 Client](../clients/socks5/setup.md). -``` - -In case you want to run deprecated NymConnect, follow these steps: - -1. Navigate to our [Github repository](https://github.com/nymtech/nym/releases?q=nym-connect&expanded=true) and download NymConnect binary -2. On Linux and Mac, make executable by opening terminal in the same directory and run: - -```sh -chmod +x ./nym-connect_.AppImage -``` - -1. Start the application -2. Click on `Connect` button to initialise the connection with the Mixnet -3. Anytime you'll need to setup Host and Port in your applications, click on `IP` and `Port` to copy the values to clipboard -4. In case you have problems such as `Gateway Issues`, try to reconnect or restart the application - -## Connect Privacy Enhanced Applications (PEApps) - -Here are some examples of applications which will work behind Socks5 proxy (`nym-socks5-client` or deprecated NymConnect), to enhance users privacy. - -### Electrum Bitcoin wallet via NymConnect - -To download Electrum visit the [official webpage](https://electrum.org/#download). To connect to the Mixnet follow these steps: - -1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md)) -2. Start your Electrum Bitcoin wallet -3. Go to: *Tools* -> *Network* -> *Proxy* -4. Set *Use proxy* to ✅, choose `SOCKS5` from the drop-down and add (copy-paste) the values from your NymConnect application -5. Now your Electrum Bitcoin wallet runs through the Mixnet and it will be connected only if your NymConnect or `nym-socks5-client` are connected. - -![Electrum Bitcoin wallet setup](../images/electrum_tutorial/electrum.gif) - -### Monero wallet via NymConnect - -To download Monero wallet visit [getmonero.org](https://www.getmonero.org/downloads/). To connect to the Mixnet follow these steps: - -1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md)) -2. Start your Monero wallet -3. Go to: *Settings* -> *Interface* -> *Socks5 proxy* -> Add values: IP address `127.0.0.1`, Port `1080` (the values copied from NymConnect) -5. Now your Monero wallet runs through the Mixnet and it will be connected only if your NymConnect or `nym-socks5-client` are connected. - -![Monero wallet setup](../images/monero_tutorial/monero-gui-NC.gif) - -### Matrix (Element) via NymConnect - -To download Element (chat client for Matrix) visit [element.io](https://element.io/download). To connect to the Mixnet follow these steps: - -1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md)) -2. Start `element-desktop` with `--proxy-server` argument: - -**Linux** - -```sh -element-desktop --proxy-server=socks5://127.0.0.1:1080 -``` - -**Mac** - -```sh -open -a Element --args --proxy-server=socks5://127.0.0.1:1080 -``` - -To make the start of Element over NymConnect simplier, you can add this command to your key-binding shortcuts in your system settings. - -### Telegram via NymConnect - -1. Start and connect NymConnect (or [`nym-socks5-client`](../clients/socks5/setup.md)) -2. Start your Telegram chat application -3. Open the Telegram proxy settings. - - Linux: *Settings* -> *Advanced* -> *Connection type* -> *Use custom proxy* - - MacOS: *Settings* -> *Advanced* -> *Data & Storage* -> *Connection Type* -> *Use custom Proxy* - - Windows: *Settings* -> *Data and Storage* -> *Use proxy* -4. Add a proxy with the *Add proxy button*. -5. Select *SOCKS5* and make sure the port details are the same as those generated by NymConnect. Alternatively, follow this link: [https://t.me/socks?server=127.0.0.1&port=1080](https://t.me/socks?server=127.0.0.1&port=1080) -6. *Save the proxy settings* in Telegram. -7. Telegram is now running through the Nym Mixnet and is privacy-enhanced! This allows you to connect from regions which blocked Telegram. -8. Note if you remain idle on Telegram for a while you might lose connectivity and your messages might not get through via SOCKS5 proxy. If that happens reconnect your NymConnect and reset the proxy again. - - -Follow this [video](https://youtu.be/quj8H2qeOwY?t=97) to see the steps on Telegram setup. diff --git a/documentation/old_docs/dev-portal/src/binaries/building-nym.md b/documentation/old_docs/dev-portal/src/binaries/building-nym.md deleted file mode 100644 index 0bbb5e0ed1..0000000000 --- a/documentation/old_docs/dev-portal/src/binaries/building-nym.md +++ /dev/null @@ -1,61 +0,0 @@ -# Building from Source - -> Nym runs on Mac OS X, Linux, and Windows. All nodes **except the Desktop Wallet and NymConnect** on Windows should be considered experimental - it works fine if you're an app developer but isn't recommended for running nodes. - -## Building Nym -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. - -## Prerequisites -- Debian/Ubuntu: `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq`, `git` - -``` -apt install pkg-config build-essential libssl-dev curl jq git -``` - -- Arch/Manjaro: `base-devel` - -``` -pacman -S base-devel -``` - -- Mac OS X: `pkg-config` , `brew`, `openss1`, `protobuf`, `curl`, `git` -Running the following the script installs Homebrew and the above dependencies: - -``` -/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" -``` - -- `Rust & cargo >= {{minimum_rust_version}}` - -We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old. - -If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms. - -## Download and build Nym binaries -The following commands will compile binaries into the `nym/target/release` directory: - -```sh -rustup update -git clone https://github.com/nymtech/nym.git -cd nym - -git reset --hard # in case you made any changes on your branch -git pull # in case you've checked it out before - -git checkout master # master branch has the latest release version: `develop` will most likely be incompatible with deployed public networks - -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: - -* [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.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/old_docs/dev-portal/src/binaries/pre-built-binaries.md b/documentation/old_docs/dev-portal/src/binaries/pre-built-binaries.md deleted file mode 100644 index 269c26276c..0000000000 --- a/documentation/old_docs/dev-portal/src/binaries/pre-built-binaries.md +++ /dev/null @@ -1,6 +0,0 @@ -# Pre-built Binaries - -The [Github releases page](https://github.com/nymtech/nym/releases) has pre-built binaries which should work on Ubuntu 20.04 and other Debian-based systems, but at this stage cannot be guaranteed to work everywhere. - -If the pre-built binaries don't work or are unavailable for your system, you will need to build the platform yourself. - diff --git a/documentation/old_docs/dev-portal/src/clients-overview.md b/documentation/old_docs/dev-portal/src/clients-overview.md deleted file mode 100644 index 616ddc797e..0000000000 --- a/documentation/old_docs/dev-portal/src/clients-overview.md +++ /dev/null @@ -1,49 +0,0 @@ -# Clients Overview - -A large proportion of the Nym mixnet's functionality is implemented client-side. - -Clients perform the following actions on behalf of users: - -* determine network topology - what mixnodes exist, what their keys are, etc. -* register with a gateway -* authenticate with a gateway -* receive and decrypt messages from the gateway -* create layer-encrypted Sphinx packets -* send Sphinx packets with real messages -* send Sphinx packet _cover traffic_ when no real messages are being sent -* retransmit un-acknowledged packet sends - if a client sends 100 packets to a gateway, but only receives an acknowledgement ('ack') for 95 of them, it will resend those 5 packets to the gateway again, to make sure that all packets are received. - -> As a developer, you'll want to use a Nym client to send your application network traffic through the mixnet; whether that is an RPC call, a TCP connection request, or treating it like a UDP pipe, you need to send whatever bytes your app needs to send through it. However, unlike (e.g.) a TCP Socket, Nym client communication is message-based, so you cannot (yet) simply plug-and-play using the mixnet as a seamless drop-in replacement. We are currently working on stream-like abstractions for ease of integration with the Rust SDK. - -## Types of Nym clients -At present, there are three Nym clients: - -- the websocket (native) client -- the SOCKS5 client -- the wasm (webassembly) client - -You need to choose which one you want incorporate into your app. Which one you use will depend largely on your preferred programming style and the purpose of your app. - -### The websocket client -Your first option is the native websocket client (`nym-client`). This is a compiled program that can run on Linux, Mac OS X, and Windows machines. It can be run as a persistent process on a desktop or server machine. You can connect to it with **any language that supports websockets**. - -> Rust developers can import websocket client functionality into their code via the [Rust SDK](sdk/rust/rust.md). - -### The webassembly client -If you're working in JavaScript or Typescript in the browser, or building an [edge computing](https://en.wikipedia.org/wiki/Edge_computing) app, you'll likely want to choose the webassembly client. - -It's packaged and [available on the npm registry](https://www.npmjs.com/package/@nymproject/nym-client-wasm), so you can `npm install` it into your JavaScript or TypeScript application. - -> The webassembly client is most easily used via the [Typescript SDK](sdk/typescript.md). Typescript developers who wish to send API requests through the mixnet can can also check the [`mixfetch`]() package. - -### The SOCKS5 client -The `nym-socks5-client` is useful for allowing existing applications to use the Nym mixnet without any code changes. All that's necessary is that they can use one of the SOCKS5, SOCKS4a, or SOCKS4 proxy protocols (which many applications can - crypto wallets, browsers, chat applications etc). - -When used as a standalone client, it's less flexible as a way of writing custom applications than the other clients, but able to be used to proxy application traffic through the mixnet without having to make any code changes. - -> Rust developers can import socks client functionality into their code via the [Rust SDK](sdk/rust/rust.md). - -## Commonalities between clients -All Nym client packages present basically the same capabilities to the privacy application developer. They need to run as a persistent process in order to stay connected and ready to receive any incoming messages from their gateway nodes. They register and authenticate to gateways, and encrypt Sphinx packets. - - diff --git a/documentation/old_docs/dev-portal/src/clients/overview.md b/documentation/old_docs/dev-portal/src/clients/overview.md deleted file mode 100644 index fcce9eb8bb..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/overview.md +++ /dev/null @@ -1,45 +0,0 @@ -# Clients Overview - -A large proportion of the Nym mixnet's functionality is implemented client-side. - -Clients perform the following actions on behalf of users: - -* determine network topology - what mixnodes exist, what their keys are, etc. -* register with a gateway -* authenticate with a gateway -* receive and decrypt messages from the gateway -* create layer-encrypted Sphinx packets -* send Sphinx packets with real messages -* send Sphinx packet _cover traffic_ when no real messages are being sent -* retransmit un-acknowledged packet sends - if a client sends 100 packets to a gateway, but only receives an acknowledgement ('ack') for 95 of them, it will resend those 5 packets to the gateway again, to make sure that all packets are received. - -## Types of Nym clients -At present, there are three Nym clients: - -- the websocket (native) client -- the SOCKS5 client -- the wasm (webassembly) client - -You need to choose which one you want incorporate into your app. Which one you use will depend largely on your preferred programming style and the purpose of your app. - -### The websocket client -Your first option is the native websocket client (`nym-client`). This is a compiled program that can run on Linux, Mac OS X, and Windows machines. It can be run as a persistent process on a desktop or server machine. You can connect to it with **any language that supports websockets**. - -> Rust developers can import websocket client functionality into their code via the [Rust SDK](../sdk/rust/rust.md). - -### The webassembly client -If you're working in JavaScript or Typescript in the browser, or building an [edge computing](https://en.wikipedia.org/wiki/Edge_computing) app, you'll likely want to choose the webassembly client. - -It's packaged and [available on the npm registry](https://www.npmjs.com/package/@nymproject/nym-client-wasm), so you can `npm install` it into your JavaScript or TypeScript application. - -> The webassembly client is most easily used via the [Typescript SDK](../sdk/typescript.md). Typescript developers who wish to send API requests through the mixnet can can also check the [`mixfetch`]() package. - -### The SOCKS5 client -The `nym-socks5-client` is useful for allowing existing applications to use the Nym mixnet without any code changes. All that's necessary is that they can use one of the SOCKS5, SOCKS4a, or SOCKS4 proxy protocols (which many applications can - crypto wallets, browsers, chat applications etc). - -When used as a standalone client, it's less flexible as a way of writing custom applications than the other clients, but able to be used to proxy application traffic through the mixnet without having to make any code changes. - -_Rust developers can import socks client functionality into their code via the [Rust SDK](../sdk/rust/rust.md)_. - -## Commonalities between clients -All Nym client packages present basically the same capabilities to the privacy application developer. They need to run as a persistent process in order to stay connected and ready to receive any incoming messages from their gateway nodes. They register and authenticate to gateways, and encrypt Sphinx packets. diff --git a/documentation/old_docs/dev-portal/src/clients/socks5/usage.md b/documentation/old_docs/dev-portal/src/clients/socks5/usage.md deleted file mode 100644 index f05c594ef0..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/socks5/usage.md +++ /dev/null @@ -1,33 +0,0 @@ -# Using Your Client - -## Proxying traffic -After completing the steps above, your local `nym-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: - -![Blockstream Green settings](../../images/blockstream-green.gif) - -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. - -## Supported Applications - -Any application which can be redirected over Socks5 proxy should work. Nym community has been successfully running over Nym Mixnet these applications: - -- Bitcoin Electrum wallet -- Monero wallet (GUI and CLI with monerod) -- Telegram chat -- Element/Matrix chat -- Firo wallet -- Blockstream Green - -> DarkFi's ircd chat was previously supported: they have moved to DarkIrc: whether the existing integration work is still operational needs to be tested. - -Keep in mind that Nym has been developing a new client **[NymVPN](https://nymvpn.com) (GUI and CLI) routing all users traffic through the Mixnet.** - -## Further reading - -If you want to dig more into the architecture and use of the socks5 client check out its documentation [here](https://nymtech.net/docs/clients/socks5-client.html). diff --git a/documentation/old_docs/dev-portal/src/clients/webassembly-client.md b/documentation/old_docs/dev-portal/src/clients/webassembly-client.md deleted file mode 100644 index f6a0aa55c2..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/webassembly-client.md +++ /dev/null @@ -1,22 +0,0 @@ -# Webassembly Client - -The Nym webassembly client allows any webassembly-capable runtime to build and send Sphinx packets to the Nym network, for uses in edge computing and browser-based applications. - -This is currently packaged and distributed for ease of use via the [Nym Typescript SDK library](../sdk/typescript.md). **We imagine most developers will use this client via the SDK for ease.** - -The webassembly client allows for the easy creation of Sphinx packets from within mobile apps and browser-based client-side apps (including Electron or similar). - -## Building apps with Webassembly Client - -Check out the [Typescript SDK docs](https://sdk.nymtech.net) for examples of usage. - -There are also example applications located in the `clients/webassembly` directory in the main Nym platform codebase. - -## Think about what you're sending! -```admonish caution -Think about what information your app sends. That goes for whatever you put into your Sphinx packet messages as well as what your app's environment may leak. -``` - -Whenever you write client PEAPPs using HTML/JavaScript, we recommend that you do not load external resources from CDNs. Webapp developers do this all the time, to save load time for common resources, or just for convenience. But when you're writing privacy apps it's better not to make these kinds of requests. Pack everything locally. - -If you use only local resources within your Electron app or your browser extensions, explicitly encoding request data in a Sphinx packet does protect you from the normal leakage that gets sent in a browser HTTP request. [There's a lot of stuff that leaks when you make an HTTP request from a browser window](https://panopticlick.eff.org/). Luckily, all that metadata and request leakage doesn't happen in Nym, because you're choosing very explicitly what to encode into Sphinx packets, instead of sending a whole browser environment by default. diff --git a/documentation/old_docs/dev-portal/src/clients/websocket-client.md b/documentation/old_docs/dev-portal/src/clients/websocket-client.md deleted file mode 100644 index add7ef24dc..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/websocket-client.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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. - -## Current version -``` - -``` - -You can run this client as a standalone process and pipe traffic into it to be sent through the mixnet. This is useful if you're building an application in a language other than Typescript or Rust and cannot utilise one of the SDKs. - -You can find the code for this client [here](https://github.com/nymtech/nym/tree/develop/clients/native). - diff --git a/documentation/old_docs/dev-portal/src/clients/websocket/config.md b/documentation/old_docs/dev-portal/src/clients/websocket/config.md deleted file mode 100644 index 8bd6d8bedb..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/websocket/config.md +++ /dev/null @@ -1,47 +0,0 @@ -# Configuration - -## Default listening port -The Nym native client exposes a websocket interface that your code connects to. To program your app, choose a websocket library for whatever language you're using. The **default** websocket port is `1977`, you can override that in the client config if you want. - -You can either set this via the `--port` flag at `init` or `run`, or you can manually edit `~/.nym/clients//config/config.toml`. - -> Remember to restart your client if you change your listening port via editing your config file. - -## Choosing a Gateway -By default your client will choose a random gateway to connect to. - -However, there are several options for choosing a gateway, if you do not want one that is randomly assigned to your client: -* If you wish to connect to a specific gateway, you can specify this with the `--gateway` flag when running `init`. -* You can also choose a gateway based on its location relative to your client. This can be done by appending the `--latency-based-routing` flag to your `init` command. This command means that to select a gateway, your client will: - * fetch a list of all available 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/clients//`. - -``` -tree $HOME//.nym/clients/example-client -├── config -│   └── config.toml -└── data - ├── ack_key.pem - ├── gateway_shared.pem - ├── 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 `` 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. diff --git a/documentation/old_docs/dev-portal/src/clients/websocket/examples.md b/documentation/old_docs/dev-portal/src/clients/websocket/examples.md deleted file mode 100644 index df9eb6d657..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/websocket/examples.md +++ /dev/null @@ -1,17 +0,0 @@ -# Examples -The Nym monorepo includes websocket client example code for Rust, Go, Javacript, and Python, all of which can be found [here](https://github.com/nymtech/nym/tree/master/clients/native/examples). - -> Rust users can run the examples with `cargo run --example .rs`, as the examples are not organised in the same way as the other examples, due to already being inside a Cargo project. - -All of these code examples will do the following: -* connect to a running websocket client on port `1977` -* format a message to send in either JSON or Binary format. Nym messages have defined JSON formats. -* send the message into the websocket. The native client packages the message into a Sphinx packet and sends it to the mixnet -* wait for confirmation that the message hit the native client -* wait to receive messages from other Nym apps - -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/old_docs/dev-portal/src/clients/websocket/setup.md b/documentation/old_docs/dev-portal/src/clients/websocket/setup.md deleted file mode 100644 index e682e87175..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/websocket/setup.md +++ /dev/null @@ -1,59 +0,0 @@ -# Setup & Run - -## Viewing command help - -You can check that your binaries are properly compiled with: - -``` -./nym-client --help -``` - -~~~admonish example collapsible=true title="Console output" -``` - -``` -~~~ - -The two most important commands you will issue to the client are: - -* `init` - initalise a new client instance. -* `run` - run a mixnet client process. - -You can check the necessary parameters for the available commands by running: - -``` -./nym-client --help -``` - -## Initialising your client - -Before you can use the client, you need to initalise a new instance of it. Each instance of the client has its own public/private keypair, and connects to its own gateway node. Taken together, these 3 things (public/private keypair + gateway node identity key) make up an app's identity. - -Initialising a new client instance can be done with the following command: - -``` -./nym-client init --id example-client -``` - -~~~admonish example collapsible=true title="Console output" -``` - -``` -~~~ - -The `--id` in the example above is a local identifier so that you can name your clients; it is **never** transmitted over the network. - -There is an optional `--gateway` flag that you can use if you want to use a specific gateway. The supplied argument is the `Identity Key` of the gateway you wish to use, which can be found on the [mainnet Network Explorer](https://explorer.nymtech.net/network-components/gateways) or [Sandbox Testnet Explorer](https://sandbox-explorer.nymtech.net/network-components/gateways) depending on which network you are on. - -Not passing this argument will randomly select a gateway for your client. - -## Running your client -You can run the initalised client by doing this: - -``` -./nym-client run --id example-client -``` - -When you run the client, it immediately starts generating (fake) cover traffic and sending it to the mixnet. - -When the client is first started, it will reach out to the Nym network's validators, and get a list of available Nym nodes (gateways, mixnodes, and validators). We call this list of nodes the network _topology_. The client does this so that it knows how to connect, register itself with the network, and know which mixnodes it can route Sphinx packets through. diff --git a/documentation/old_docs/dev-portal/src/clients/websocket/usage.md b/documentation/old_docs/dev-portal/src/clients/websocket/usage.md deleted file mode 100644 index ecc157d98d..0000000000 --- a/documentation/old_docs/dev-portal/src/clients/websocket/usage.md +++ /dev/null @@ -1,117 +0,0 @@ -# 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. - -# 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 . 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 -{ - "type": "selfAddress" -} -``` - -You'll receive a response of the format: - -```json -{ - "type": "selfAddress", - "address": "your address" // e.g. "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm" -} -``` - -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. - -## Sending text -If you want to send text information through the mixnet, format a message like this one and poke it into the websocket: - -```json -{ - "type": "send", - "message": "the message", - "recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm" -} -``` - -In some applications, e.g. where people are chatting with friends who they know, you might want to include unencrypted reply information in the message field. This provides an easy way for the receiving chat to then turn around and send a reply message: - -```json -{ - "type": "send", - "message": { - "sender": "198427b63ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm", - "chatMessage": "hi julia!" - }, - "recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm" -} -``` - -**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](https://nymtech.net/docs/architecture/traffic-flow.html#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. - -```json -{ - "type": "sendAnonymous", - "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. - -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. - -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. - -Constructing a reply with SURBs looks something like this (where `senderTag` was parsed from the incoming message) - -```json -{ - "type": "reply", - "message": "reply you also want to keep secret", - "senderTag": "the sender tag you parsed from the incoming message" -} -``` - -## Error messages -Errors from the app's client, or from the gateway, will be sent down the websocket to your code in the following format: - -```json -{ - "type": "error", - "message": "string message" -} -``` - -## 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. - -# 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 -{{#include ../../../../../clients/native/websocket-requests/src/responses.rs:48:53}} -``` diff --git a/documentation/old_docs/dev-portal/src/coc.md b/documentation/old_docs/dev-portal/src/coc.md deleted file mode 100644 index 5cfce4d121..0000000000 --- a/documentation/old_docs/dev-portal/src/coc.md +++ /dev/null @@ -1,17 +0,0 @@ -# Code of Conduct - -We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. - -Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all. - -Please be kind and courteous. There’s no need to be mean or rude. - -Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. - -Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. - -We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behaviour that excludes people in socially marginalized groups. - -Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust moderation team immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back. - -Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome. diff --git a/documentation/old_docs/dev-portal/src/events/hcpp23-max.md b/documentation/old_docs/dev-portal/src/events/hcpp23-max.md deleted file mode 100644 index 441094bb80..0000000000 --- a/documentation/old_docs/dev-portal/src/events/hcpp23-max.md +++ /dev/null @@ -1,33 +0,0 @@ -# HCPP23 - Building with Nym workshop - -This is a *reference page*, to see the entire presentation join Max's talk at [HCPP 2023](https://resistance.hcpp.cz/) on [Satuday](https://cfp.paralelnipolis.cz/hcpp23/talk/LLPWXW/). - -## Mixnet architecture - -* [Mixnet motivations](https://nymtech.net/developers/infrastructure/nym.html) -* [Mixnet architecture overview](https://nymtech.net/docs/architecture/network-overview.html) -* [Mixnet traffic flow](https://nymtech.net/docs/architecture/traffic-flow.html) -* [Tor + VPN comparison](https://nymtech.net/developers/infrastructure/nym-vs-others.html) -* [Addressing system](https://nymtech.net/docs/clients/addressing-system.html) - -## Clients - -* [Clients overview](https://nymtech.net/docs/clients/overview.html) - -## SDKs - -* [Rust SDK](https://nymtech.net/docs/sdk/rust.html) -* [Typescript SDK](https://sdk.nymtech.net/) - -### Rust examples - -* [Libp2p examples](https://github.com/nymtech/nym/tree/develop/sdk/rust/nym-sdk/examples) -* [Lighthouse PoC](https://github.com/ChainSafe/lighthouse/blob/nym/USE_NYM.md) -* [Dev tutoral: chain service](https://nymtech.net/developers/tutorials/cosmos-service/intro.html) -* [Community: Darkfi over Nym](https://darkrenaissance.github.io/darkfi/clients/nym_outbound.html?highlight=nym#3--run) - -### Typescript - -* [Mixfetch NPM](https://www.npmjs.com/package/@nymproject/mix-fetch) -* [Interactive Typescript SDK docs](https://sdk.nymtech.net) - diff --git a/documentation/old_docs/dev-portal/src/events/hcpp23-serinko.md b/documentation/old_docs/dev-portal/src/events/hcpp23-serinko.md deleted file mode 100644 index 4fda998fae..0000000000 --- a/documentation/old_docs/dev-portal/src/events/hcpp23-serinko.md +++ /dev/null @@ -1,323 +0,0 @@ -# HCPP 2023 - Securing the Lunarpunks Workshop - -[Serinko's](https://resistance.hcpp.cz/) [workshop](ttps://cfp.paralelnipolis.cz/hcpp23/talk/LLPWXW/) will introduce ***why*** and ***how to use [Nym](https://nymtech.net) platform as a network protection*** layer when using some of our favorite privacy applications. This page serves as an accessible guide alongside the talk and it includes all the steps, pre-requisities and dependencies needed. Preferably the users interested in this setup start downloading and building the tools before the workshop or in the beginning of it. We can use the limited time for questions and addressing problems. This guide will stay online after the event just in case people were not finished and want to catch up later. - -This page is a *how to guide* so it contains the setup only, to see the entire presentation join in at [HCPP 2023](https://resistance.hcpp.cz/) on [Sunday](https://cfp.paralelnipolis.cz/hcpp23/talk/LLPWXW/). - -## Preparation - -During this workshop we will introduce [NymConnect](https://nymtech.net/developers/quickstart/nymconnect-gui.html) and [Socks5 client](https://nymtech.net/docs/clients/socks5-client.html). The difference between them is that the Socks5 client does everything Nymconnect does, but it has more optionality and it's run from a commandline. NymConnect is a one-button GUI application that wraps around the `nym-socks5-client` for proxying application traffic through the Mixnet. - -We will learn how to run through [Nym Mixnet](https://nymtech.net/docs/architecture/network-overview.html) the following applications: Electrum Bitcoin wallet, Monero wallet (desktop and CLI), Matrix (Element app) and ircd chat. For those who want to run ircd through the Mixnet, `nym-socks5-client` client is a must. For all other applications you can choose if you settle with our slick app NymConnect which does all the job in the background or you prefer Socks5 client. - -> Any syntax in `<>` brackets is a user's/version unique variable. Exchange with a corresponding name without the `<>` brackets. - -## NymConnect Installation - -NymConnect application is for everyone who does not want to install and run `nym-socks5-client`. NymConnect is plug-and-play, fast and easy use. Electrum Bitcoin wallet, Monero wallet (desktop and CLI) and Matrix (Element app) connects through NymConnect automatically to the Mixnet. - -1. [Download](https://nymtech.net/download/nymconnect) NymConnect -2. On Linux and Mac, make executable by opening terminal in the same directory and run: - -```sh -chmod +x ./nym-connect_.AppImage -``` - -3. Start the application -4. Click on `Connect` button to initialise the connection with the Mixnet -5. Anytime you'll need to setup Host and Port in your applications, click on `IP` and `Port` to copy the values to clipboard -6. In case you have problems such as `Gateway Issues`, try to reconnect or restart the application - -## Connect Privacy Enhanced Applications (PEApps) - -For simplification in this guide we connect Electrum, Monero wallet and Matrix (Element) using NymConnect and ircd over `nym-socks5-client`. Of course if your choice is to run `nym-socks5-client` all these apps will connect through that and you don't need to install NymConnect. - -```admonish info -This guide aims to connect your favourite applications to Nym Mixnet, therefore we do not include detailed guides on how to install them, only reference to the source pages. -``` - -### Electrum Bitcoin wallet via NymConnect - -To download Electrum visit the [official webpage](https://electrum.org/#download). To connect to the Mixnet follow these steps: - -1. Start and connect [NymConnect](./hcpp23-serinko.html#nymconnect-installation) (or [`nym-socks5-client`](./hcpp23-serinko.html#building-nym-platform)) -2. Start your Electrum Bitcoin wallet -3. Go to: *Tools* -> *Network* -> *Proxy* -4. Set *Use proxy* to ✅, choose `SOCKS5` from the drop-down and add the values from your NymConnect application -5. Now your Electrum Bitcoin wallet runs through the Mixnet and it will be connected only if your NymConnect or `nym-socks5-client` are connected. - -![Electrum Bitcoin wallet setup](../images/electrum_tutorial/electrum.gif) - -### Monero wallet via NymConnect - -To download Monero wallet visit [getmonero.org](https://www.getmonero.org/downloads/). To connect to the Mixnet follow these steps: - -1. Start and connect [NymConnect](./hcpp23-serinko.html#nymconnect-installation) (or [`nym-socks5-client`](./hcpp23-serinko.html#building-nym-platform)) -2. Start your Monero wallet -3. Go to: *Settings* -> *Interface* -> *Socks5 proxy* -> Add values: IP address `127.0.0.1`, Port `1080` (the values copied from NymConnect) -5. Now your Monero wallet runs through the Mixnet and it will be connected only if your NymConnect or `nym-socks5-client` are connected. - -![Monero wallet setup](../images/monero_tutorial/monero-gui-NC.gif) - -If you prefer to run Monero-CLI wallet with Monerod, please check out [this guide](https://nymtech.net/developers/tutorials/monero.html#how-can-i-use-monero-over-the-nym-mixnet). - -### Matrix (Element) via NymConnect - -To download Element (chat client for Matrix) visit [element.io](https://element.io/download). To connect to the Mixnet follow these steps: - -1. Start and connect [NymConnect](./hcpp23-serinko.html#nymconnect-installation) (or [`nym-socks5-client`](./hcpp23-serinko.html#building-nym-platform)) -2. Start `element-desktop` with `--proxy-server` argument: - -**Linux** - -```sh -element-desktop --proxy-server=socks5://127.0.0.1:1080 -``` - -**Mac** - -```sh -open -a Element --args --proxy-server=socks5://127.0.0.1:1080 -``` - -To setup your own alias or key-binding see our [*Matrix NymConnect Integration* guide](https://nymtech.net/developers/tutorials/matrix.html#optimise-setup-with-a-keybinding--alias). - - -## Building Nym Platform - -If you prefer to run to run `nym-socks5-client` the possibility is to download the pre-build binary or build the entire platform. To run ircd through the Mixnet `nym-socks5-client` and `nym-network-requester` are mandatory. Before you start with download and installation, make sure you are on the same machine from which you will connect to ircd. - -We recommend to clone and build the entire platform instead of individual binaries as it offers an easier update and more options down the road, however it takes a basic command-line knowledge and more time. The [Nym platform](https://github.com/nymtech/nym) is written in Rust. For that to work we will need a few pre-requisities. If you prefer to download individual pre-build binaries, skip this part and go directly [that chapter](./hcpp23-serinko.html#pre-built-binaries). - -### Prerequisites -- Debian/Ubuntu: `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq`, `git` - -```sh -apt install pkg-config build-essential libssl-dev curl jq git -``` - -- Arch/Manjaro: `base-devel` - -```sh -pacman -S base-devel -``` - -- Mac OS X: `pkg-config` , `brew`, `openss1`, `protobuf`, `curl`, `git` -Running the following the script installs Homebrew and the above dependencies: - -```sh -/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" -``` - -- `Rust & cargo >= {{minimum_rust_version}}` - -We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old. - -If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms. - -### Download and Compile Nym - -The following commands will compile binaries into the `nym/target/release` directory: - -```sh -rustup update -git clone https://github.com/nymtech/nym.git -cd nym -git checkout master # master branch has the latest release version: `develop` will most likely be incompatible with deployed public networks -cargo build --release # build your binaries with **mainnet** configuration -``` - -Quite a bit of stuff gets built. The key working parts for the workshop are: - -* [socks5 client](https://nymtech.net/docs/clients/socks5-client.html): `nym-socks5-client` -* [network requester](https://nymtech.net/operators/nodes/network-requester-setup.html): `nym-network-requester` - -## Pre-built Binaries - -The [Github releases page](https://github.com/nymtech/nym/releases) has pre-built binaries which should work on Ubuntu 20.04 and other Debian-based systems, but at this stage cannot be guaranteed to work everywhere. - -**Download:** Find the binary of your choice, right click on the binary, select *Copy Link*. This will save the binary `` to clipboard. Run the following commands on your machine: - -``` -wget # to download the binary -``` - -If the pre-built binaries don't work or are unavailable for your system, you will need to [build the platform](./hcpp23-serinko.html#building-nym-platform) yourself. - -All Nym binaries must first be made executable. - -To make a binary executable, open terminal in the same directory and run: - -```sh -chmod +x ./ -# for example: chmod +x ./nym-network-requester -``` - -## Initialize Socks5 Client and Network Requester - -Whether you build the entire platform or downloaded binaries, `nym-socks5-client` and `nym-network-requester` need to be initialised with `init` before being `run`. - -In your terminal navigate to the directory where you have your `nym-socks5-client` and `nym-network-requester`. In case you built the entire platform it's in `nym/target/release`. - -```sh -# change directory from nym repo -cd target/release -``` - -**Network Requester** - -The `init` command is usually where you pass flags specifying configuration arguments such as the gateway you wish to communicate with, the ports you wish your binary to listen on, etc. - -The `init` command will also create the necessary keypairs and configuration files at `~/.nym///` if these files do not already exist. **It will NOT overwrite existing keypairs if they are present.** - -To run [ircd](https://darkrenaissance.github.io/darkfi/clients/nym_outbound.html) through the Mixnet you need to run your own [Network Requester](https://nymtech.net/operators/nodes/network-requester-setup.html) and add known peer's domains/addresses to `~/.nym/service-providers/network-requester//data/allowed.list`. For all other applications `nym-socks5-client` (or NymCOnnect) is enough, no need to initialize and run `nym-network-requester`. - -Here are the steps to initialize `nym-network-requester`: - -```sh -# open the directory with your binaries -./nym-network-requester init --id -``` -This will print you information about your client `
`, it will look like: -```sh -The address of this client is: 8hUvtEyZK8umsdxxPS2BizQhEDmbNeXEPBZLgscE57Zh.5P2bWn6WybVL8QgoPEUHf6h2zXktmwrWaqaucEBZy7Vb@5vC8spDvw5VDQ8Zvd9fVvBhbUDv9jABR4cXzd4Kh5vz -``` - -**Socks5 Client** - -If you run `nym-socks5-client` instead of NymConnect, you can choose your `--provider` [here](https://explorer.nymtech.net/network-components/service-providers) or leave that flag empty and your client will chose one randomly. To run ircd, you will need to connect it to your `nym-network-requester` by using your `
` for your `nym-socks5-client` initialisation and add a flag `--use-reply-surbs true`. Run the command in the next terminal window: - -```sh -# to connect to your nym-network-requester as a provider for ircd -./nym-socks5-client init --use-reply-surbs true --id --provider
- -# simple socks5 client init (random provider) for other apps -./nym-socks5-client init --id -``` - -```admonish info -You can reconfigure your binaries at any time by editing the config file located at `~/.nym/service-providers///config/config.toml` and restarting the binary process. -``` - -**Run Clients** - -Once you have run `init`, you can start your binary with the `run` command, accompanied by the `id` of the binary that you specified. - -This `id` is **never** transmitted over the network, and is used to select which local config and key files to use for startup. - -```sh -# network requester -./nym-network-requester run --id - -# socks5 client (in other terminal window) -./nym-socks5-client run --id -``` - -**Troubleshooting** - -In case your `nym-socks5-client` has a problem to connect to your `nym-network-requester` try to setup a firewall by running these commands: - -```sh -# check if you have ufw installed -ufw version - -# if it is not installed, install with -sudo apt install ufw -y - -# enable ufw -sudo ufw enable - -# check the status of the firewall -sudo ufw status - -# open firewall ports for network requester -sudo ufw allow 22,9000/tcp - -# re-check the ufw status -sudo ufw status -``` - -Restart your network requester. - - -## ircd - -[Dark.fi](htps://dark.fi) built a fully anonymous and p2p instance of IRC chat called [ircd](https://darkrenaissance.github.io/darkfi/misc/ircd/ircd.html). The team is just finishing their new instance of the program darkirc which we hope to see in production soon. - -```admonish info -It is highly recomended to install [dark.fi architecture](https://github.com/darkrenaissance/darkfi) prior to the workshop following the [documentation](https://darkrenaissance.github.io/darkfi/misc/ircd/ircd.html) so we have enough time for the network configuration. -``` - -### Configuration - -Make sure to have [ircd installed](https://darkrenaissance.github.io/darkfi/misc/ircd/ircd.html) on the same machine like your `nym-socks5-client` (`nym-network-requester` can run anywhere). - -Currently `nym-network-requester` automatically connnects only to the [whitelisted URLs](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt). This will [change soon](https://nymtech.net/operators/faq/smoosh-faq.html) into a more opened setup. This list can be changed by an operator running a node. - -**Edit allowed.list** - -1. Open a text editor and add: -```yaml -dasman.xyz -``` -2. Save it as `allowed.list` in `~/.nym/service-providers/network-requester//data/` -3. Restart your `nym-network-requester` -```sh -./nym-network-requester run --id -``` -4. Make sure both `nym-socks5-client` and `nym-network-requester` are running and connected - -**ircd setup** - -In case your ircd has problems to start or connect, run the following: - -```sh -# cd to darkfi repo -git pull -git checkout c4b78ead5111b0423fca3bd53cb7185acd6f0faa - -# compile ircd -make ircd - -# in case of dependency error: "failed to load source for dependency `halo2_gadgets`" -rm Cargo.lock -make ircd - -# remove the config file (rename it if you want to safe any values first) -rm ~/.config/darkfi/ircd_config.toml - -# rerun ircd to generate new config file -./ircd - -# add your custom values from the old config file -``` - -5. Open `~/.config/darkfi/ircd_config.toml` -6. Coment the line with `seeds` -7. Add line: -```yaml -peers = ["nym://dasman.xyz:25552"] -``` -8. Change `outbond_transports` to: -```yaml -outbond_transports = ["nym"] -``` -9. Make sure that -```yaml -outbound_connections = 0 -``` -10. Save and restart `ircd` - -Observe the ircd deamon to see that the communication is running through the mixnet. - -## Bonus: Join hcpp23 channel - -Now, when your Darkfi's ircd runs through Nym Mixnet, you can join public and fully anonymous channel `#hcpp23`. To do so, follow one of the two possibilities: - -1. Run a command in your weechat: -```sh -/join #hcpp23 -``` -2. Open `~/.config/darkfi/ircd_config.toml` and add `"#hcpp23"` to the `autojoin = []` brackets, save and restart ircd. - - diff --git a/documentation/old_docs/dev-portal/src/events/web3-privacy.md b/documentation/old_docs/dev-portal/src/events/web3-privacy.md deleted file mode 100644 index 83fd723719..0000000000 --- a/documentation/old_docs/dev-portal/src/events/web3-privacy.md +++ /dev/null @@ -1,38 +0,0 @@ -# Web3 Privacy Now - Nym for Ethereum validator privacy - -Serinko's presentation on [Web3Privacy Now: Community 1st](https://lu.ma/web3privacynow_rome) introduces ***why network privacy matters*** for ETH 2.0 validators' security and decentralisation. - -This page serves as an accessible list of references mentioned during the talk. - -## References - -### Mixnet architecture - -* [Mixnet motivations](https://nymtech.net/developers/infrastructure/nym.html) -* [Mixnet architecture overview](https://nymtech.net/docs/architecture/network-overview.html) -* [Mixnet traffic flow](https://nymtech.net/docs/architecture/traffic-flow.html) -* [Tor + VPN comparison](https://nymtech.net/developers/infrastructure/nym-vs-others.html) -* [Addressing system](https://nymtech.net/docs/clients/addressing-system.html) - -### Nym \<\> ETH 2.0 - -* [Chainsafe Rust libp2p Nym intergration repo](https://github.com/ChainSafe/rust-libp2p-nym) -* [rust-libp2p-nym Transport Specification](https://hackmd.io/@nZ-twauPRISEa6G9zg3XRw/HkE8sHuns) -* [Lighthouse PoC](https://github.com/ChainSafe/lighthouse/blob/nym/USE_NYM.md) -* [Nym \<\> Aztec partnership](https://blog.nymtech.net/nym-partners-with-aztec-to-provide-integral-infrastructure-privacy-in-ethereum-chains-694963c55192) - -### Rust Examples - -* [Dev tutorial: chain service](https://nymtech.net/developers/tutorials/cosmos-service/intro.html) - -### Clients - -* [Clients overview](https://nymtech.net/docs/clients/overview.html) - -### Nym Docs - -* [Nym Developer Portal](https://nymtech.net/developers) -* [Nym Operators Guide](https://nymtech.net/operators) -* [Nym technical Documentation](https://nymtech.net/docs) - - diff --git a/documentation/old_docs/dev-portal/src/examples/browser-only.md b/documentation/old_docs/dev-portal/src/examples/browser-only.md deleted file mode 100644 index 01472bef22..0000000000 --- a/documentation/old_docs/dev-portal/src/examples/browser-only.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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. - -- 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) - -- 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). - -- You can find a browser-based 'hello world' chat app [here](https://chat-demo.nymtech.net). Either open in two browser windows and send messages to yourself, or share with a friend and send messages to each other through the mixnet. diff --git a/documentation/old_docs/dev-portal/src/examples/custom-services.md b/documentation/old_docs/dev-portal/src/examples/custom-services.md deleted file mode 100644 index 94ff743464..0000000000 --- a/documentation/old_docs/dev-portal/src/examples/custom-services.md +++ /dev/null @@ -1,21 +0,0 @@ -# Custom Services -Custom services involve two pieces of code that communicate via the mixnet: a client, and a custom server/service. This custom service will most likely interact with the wider internet / a clearnet service on your behalf, with the mixnet between you and the service, acting as a privacy shield. - -> The current model of relying on a Service Provider has some issues, such as additional complexity in deployment and maintenance, as well as creating potential chokepoints for app traffic. Work is going on (in the open in our [monorepo](https://github.com/nymtech/nym) ofc) to start removing this requirement as much as possible, by allowing for the creation of packet-contents in such a way that the existing Network Requester/Exit Gateway infrastructure can support network requests in a similar way to `mixFetch`. More on this as and when it is released. - -- [Nym Zcash RPC demo](https://github.com/nymtech/nym-zcash-rpc-demo), although used to only pipe RPC traffic, is a proof of concept 'generic' mixnet piping example which exposes a TPC Socket on the client side for incoming traffic, pipes this through the mixnet, and then streams TCP packets 'out' the other side. A good example of non-app-specific traffic transport which developers could also quite easily use as a template for their own app-specific work. - - [Codebase](https://github.com/nymtech/nym-zcash-rpc-demo) - -- PasteNym is a private pastebin alternative. It involves a browser-based frontend utilising the Typescript SDK and a Python-based backend service communicating with a standalone Nym Websocket Client. **If you're a Python developer, start here!**. - - [Frontend codebase](https://github.com/notrustverify/pastenym) - - [Backend codebase](https://github.com/notrustverify/pastenym-frontend) - -- Nostr-Nym is another application written by [NoTrustVerify](https://notrustverify.ch/), standing between mixnet users and a Nostr server in order to protect their metadata from being revealed when gossiping. **Useful for Go and Python developers**. - - [Codebase](https://github.com/notrustverify/nostr-nym) - -- Spook and Nym-Ethtx are both examples of Ethereum transaction broadcasters utilising the mixnet, written in Rust. Since they were written before the release of the Rust SDK, they utilise standalone clients to communicate with the mixnet. - - [Spook](https://github.com/EdenBlockVC/spook) (**Typescript**) - - [Nym-Ethtx](https://github.com/noot/nym-ethtx) (**Rust**) - -- NymDrive is an early proof of concept application for privacy-enhanced file storage on IPFS. **JS and CSS**, and a good example of packaging as an Electrum app. - - [Codebase](https://github.com/saleel/nymdrive) diff --git a/documentation/old_docs/dev-portal/src/examples/monorepo-examples.md b/documentation/old_docs/dev-portal/src/examples/monorepo-examples.md deleted file mode 100644 index ad04287f20..0000000000 --- a/documentation/old_docs/dev-portal/src/examples/monorepo-examples.md +++ /dev/null @@ -1,5 +0,0 @@ -# Monorepo examples -As well as these examples, there are a bunch of examples for each SDK in the Nym monorepo. - -- [Rust SDK examples](https://github.com/nymtech/nym/tree/develop/sdk/rust/nym-sdk/examples) -- [Typescript SDK examples](https://github.com/nymtech/nym/tree/develop/sdk/typescript/examples) \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/examples/using-nrs.md b/documentation/old_docs/dev-portal/src/examples/using-nrs.md deleted file mode 100644 index badcb7e7b7..0000000000 --- a/documentation/old_docs/dev-portal/src/examples/using-nrs.md +++ /dev/null @@ -1,24 +0,0 @@ -# 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 - 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. - -> 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 - - - - -- 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) diff --git a/documentation/old_docs/dev-portal/src/faq/integrations-faq.md b/documentation/old_docs/dev-portal/src/faq/integrations-faq.md deleted file mode 100644 index 71f833c864..0000000000 --- a/documentation/old_docs/dev-portal/src/faq/integrations-faq.md +++ /dev/null @@ -1,198 +0,0 @@ -# Integrations FAQ - -On this page, you'll find links and frequently asked questions on how to get started on integrating your project with Nym's Mixnet and its blockchain, Nyx. - -## Links -### General Info -* [Nym Website](https://nymtech.net/) -* [Nym Mixnet Explorer](https://explorer.nymtech.net/) -* [Nyx Block Explorer](https://nym.explorers.guru/) - -### Codebase Info -* [Nym Platform Monorepo](https://github.com/nymtech/nym/) -* [Nym Project](https://github.com/nymtech/) - -### Documentation Info -* [Documentation](https://nymtech.net/docs/) -* Developer Portal - you are currently viewing the Developer Portal - -## Wallet Installation -The Nym wallet can be downloaded [here](https://nymtech.net/download/). - -You can find all the instructions related to setting up your wallet in the [docs](https://nymtech.net/docs/wallet/desktop-wallet.html), as well as instructions on how to build the wallet if there is not a downloadable version built for your operating system. - -### What are the machine hardware requirements for Nym Wallet? -About 16GB of RAM is recommended for the wallet. However you can expect an average memory usage of ~100MB. - - -## Interacting with the Nyx blockchain -### Where can I find information on the blockchain, such as RPC endpoints? -You can find most information required for integration in the [Cosmos Chain Registry](https://github.com/cosmos/chain-registry/blob/master/nyx/chain.json) and [Keplr Chain Registry](https://github.com/chainapsis/keplr-chain-registry/blob/main/cosmos/nyx.json) repositories. - -### How can I use `JSON-RPC` methods to interact with the Nyx blockchain? -There are multiple ways to use `JSON-RPC` methods to interact with the Nyx blockchain. Which method you use will depend on the type of application you are integrating Nyx interactions into. - -1. The standalone `nyxd` binary can be used for CLI wallets, interacting with smart contracts via the CLI, setting up RPC nodes, and even running validators. This is a version of the Cosmos Hub's `gaiad` binary compiled with Nyx chain configuration, and is written in `Go`. Instructions on setting up the `nyxd` binary can be found [here](https://nymtech.net/docs/nyx/interacting-with-chain.html). This is recommended for more complex commands. For full documentation check the [`gaiad documentation`](https://hub.cosmos.network/main/hub-overview/overview.html#). - -2. `CosmJS` is a Typescript library allowing for developers to interact with CosmosSDK blockchains from a Javascript or Typescript project. You can find it on Github [here](https://github.com/cosmos/cosmjs) and an explainer of its functionality [in the Cosmos Developer Portal](https://tutorials.cosmos.network/tutorials/7-cosmjs/1-cosmjs-intro.html). You can find a list of example apps which use CosmJS [here](https://codesandbox.io/examples/package/@cosmjs/stargate). - -3. The `Nym-CLI` tool, a standalone rust binary which can be built and used according to the [docs](https://nymtech.net/docs/tools/nym-cli.html) can be used in much the same way as `nyxd`. It is a bit simpler to use than the `nyxd` binary, but is not recommended for complex queries, and not all commands are currently implemented. A list of Nym CLI commands and example usage can be found [here](https://nymtech.net/docs/tools/nym-cli.html) - -### How do I generate an address/mnemonic for users to interact with? -**Nyxd** - -Use the following command, replacing `your_id` with the ID you want to use for your keypair: -``` -./nyxd keys add your_id --chain-id=nyx --gas=auto --gas-adjustment=1.4 --fees=7000unym -``` - -**Nym-CLI** -``` -./nym-cli account create -``` - -Both methods will generate a keypair and log the mnemonic in the console. - -**CosmJS** - -You can find example code for keypair generation [here](https://tutorials.cosmos.network/tutorials/7-cosmjs/2-first-steps.html#testnet-preparation). - -### How to get block information like block height, block hash, block time as so on? -**Nyxd** - -You would use one of the subcommands returned by this command: -``` -./nyxd query tx --chain-id=nyx --gas=auto --gas-adjustment=1.4 --fees=7000unym -``` - -**Nym-CLI** -``` -./nym-cli block current-height -``` - -**CosmJS** - -`CosmJS` documentation can be found [here](https://cosmos.github.io/cosmjs/). We will be working on example code blocks soon. - -### How to get account/address balance to check there is enough coins to withdraw? -**Nyxd** -``` -./nyxd query bank balances
--chain-id=nyx --gas=auto --gas-adjustment=1.4 --fees=7000unym -``` - -**Nym-CLI** -``` -./nym-cli account balance -``` - -**CosmJS** - -`CosmJS` documentation can be found [here](https://cosmos.github.io/cosmjs/). We will be working on example code blocks soon. - -### How do I transfer tokens to another address? -**Nyxd** -``` -./nyxd tx bank send [from_key_or_address] [to_address] [amount] --chain-id=nyx --gas=auto --gas-adjustment=1.4 --fees=7000unym -``` - -**Nym-CLI** -``` -./nym-cli account send TARGET_ADDRESS AMOUNT -``` -**CosmJS** - -`CosmJS` documentation can be found [here](https://cosmos.github.io/cosmjs/). We will be working on example code blocks soon. - -### Does the address support the inclusion of a `memo` or `destinationTag` when doing the transfer? -Yes, it is supported. - -### Can I use my Ledger hardware wallet to interact with the Nyx blockchain? -Yes. Follow the instructions in the [Ledger support for Nyx documentation](https://nymtech.net/docs/nyx/ledger-live.html). - -### Where can I find network details such as deployed smart contract addresses? -In the [`network defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) file. - -## `NYM` Token -The token used to reward mixnet infrastructure operators - `NYM` - is one of the native tokens of the Nyx blockchain. The other token is `NYX`. - -`NYM` is used to incentivise the mixnet, whereas `NYX` is used to secure the Nyx blockchain via Validator staking. - -> Integration with Nym's technology stack will most likely involve using `NYM` if you do need to interact with the Nyx blockchain and transfer tokens. - -### I've seen an ERC20 representation of `NYM` on Ethereum - what's this and how do I use it? - -We use the [Gravity Bridge](https://github.com/Gravity-Bridge) blockchain to bridge an ERC20 representation of `NYM` between the Cosmos ecosystem of IBC-enabled chains and Ethereum mainnet. Gravity Bridge is its own IBC-enabled CosmosSDK chain, which interacts with a smart contract deployed on Ethereum mainnet. - -> The ERC20 representation of `NYM` **cannot** be used with the mixnet; only the native Cosmos representation is usable for staking or bonding nodes. - -If you need to transfer tokens across the bridge, we recommend users use Cosmostation's [spacestation.zone](https://spacestation.zone/) dApp with Metamask and Keplr. - -### What is Circulating Supply and how to find out the distribution amount? - -Circulating supply is the total number of available `NYM`. `NYM` is currently present on the IBC-enabled Nyx blockchain, as well as in ERC20 form on Ethereum Mainnet. - -The Validator API endpoints can be found via the [Swagger Documentation](https://validator.nymtech.net/api/swagger/index.html). The following endpoints can be called to retrieve the correct distribution amount and circulating supply within Nym. - -Using this API endpoint returns information about the circulating supply of Nym tokens: - -``` -/circulating-supply -``` -Query Response: - - { - "total_supply": { - "denom": "unym", - "amount": "1000000000000000" - }, - "mixmining_reserve": { - "denom": "unym", - "amount": "241105338883248" - }, - "vesting_tokens": { - "denom": "unym", - "amount": "390255200928865" - }, - "circulating_supply": { - "denom": "unym", - "amount": "368639460187887" - } - } - -- `total_supply`- The total number of NYM tokens that have been created and can exist, including those that are currently in circulation and those that are reserved for various purposes. - -- `mixmining_reserved`- The number of NYM tokens that are reserved for the mixnet miners who help to power the Nym network. - -- `vesting_tokens`- The number of NYM tokens that are subject to vesting, meaning they are gradually released over time to certain stakeholders such as the team, advisors, and early investors. - -- `circulating_supply`- The number of NYM tokens that are currently in circulation and available to be traded on the open market, which is calculated by subtracting the `mixmining_reserved` and `vesting_tokens` from the `total_supply`. - -Using this API endpoint returns the current value of the total supply of NYM tokens: - -``` -/circulating-supply/total-supply-value -``` -Query Response: - - 1000000000.0 - -> The maximum number of `NYM` tokens that can ever be created is 1 billion. - -Using this API endpoint returns the current value of the circulating supply of NYM tokens: - -``` -/circulating-supply/circulating-supply-value -``` -Query Response: - - 368639460.187887 - -> This refers to the present quantity of `NYM` tokens that are actively in circulation. - - -## Sending traffic through the Nym mixnet -### Is the mixnet free to use? -For the moment then yes, the mixnet is free to use. There are no limits on the amount of traffic that an app can send through the mixnet. - -### Do I need to run my own gateway to send application traffic through the mixnet? -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. diff --git a/documentation/old_docs/dev-portal/src/faq/rewards-faq.md b/documentation/old_docs/dev-portal/src/faq/rewards-faq.md deleted file mode 100644 index ecf1ceda7e..0000000000 --- a/documentation/old_docs/dev-portal/src/faq/rewards-faq.md +++ /dev/null @@ -1,49 +0,0 @@ -# Rewards FAQ - -On this page you will find important information about participation in community activities which involve NYM token rewards, such as contests, giveaways, and promotions. Before participating in any such activity, make sure to read this page carefully. - -### Am I eligible to participate? What are the conditions? - -Participation in any program or community activity involving NYM token rewards is only available to individuals who do not reside in locations that makes them ineligible to participate and/or receive prizes, including: - -The USA, Central African Republic, Cuba, Iran, Iraq, Lebanon, Libya, North Korea, Somalia, South Sudan, Sudan, Syria, Venezuela, Yemen, and Russian occupied regions of Ukraine (including Crimea, and parts of Donetsk and Luhansk). - -Be nice and play fair! Nym reserves the right to determine the final outcome of its programs and community activities and disqualify any participants without prior notice or recourse for any reason, including fraudulent behavior and failure to adhere to the [Nym Code of Conduct](https://nymtech.net/docs/coc.html). - -### I won NYM rewards. How can I claim them? - -First things first: congratulations! We hope you had some fun in the process. A Nym Community Manger will tag you on Telegram or Discord - send them a private message to start the claim process. You will receive your unique reward ID and detailed instructions on how to use it to claim your rewards. **Remember: we never DM you first!** - -**Note: you have 2 weeks to claim your rewards! If we don't hear from you, your reward ID will expire.** - -### Do I need to pass KYC? - -Before receiving NYM token rewards, you are required to successfully complete KYC verification with Synaps, our KYC provider. You only need to do this once! - -### This is my first time - How do I pass KYC? - -To claim your rewards, you will be asked to provide your email address. If you haven't passed KYC yet, your email address will be added to our KYC whitelist and you will receive a welcome email from Synaps with instructions on how to start the KYC process. Once you complete KYC and provide a valid Nym wallet address, your rewards will be transferred to your wallet automatically. - -**Note: it may take up to 2 weeks for your email address to get whitelisted. Be patient and keep an eye on your inbox!** - -To receive your tokens, you will need a Nym wallet address. If you don't already have one, [download](https://nymtech.net/download/) the Nym wallet and create an account. You can copy your wallet address from the "receive" tab of the wallet. Make sure to keep your mnemonic safe, as losing that means losing your tokens. - -**Tip: If you are not sure you have completed Nym KYC before, visit our KYC portal on [Synaps](https://nym-kyc.synaps.me/signup) and try to log in with your email.** - -### I have already passed KYC on Synaps. What do I need to do next? - -If you have successfully completed KYC on Synaps earlier and provided your Nym wallet address, you are all set - we will send you a link so you can claim your rewards. - -**Note: after claiming your NYM rewards, it may take up to 3 weeks for the tokens to be transferred to your wallet. Be patient and keep an eye on your wallet!** - -### I received my NYM tokens. What can I do with them? - - We're glad you asked! The Nym network is the most robust privacy infrastructure the world has ever seen, and the NYM token is how you can access its [utility](https://www.youtube.com/watch?v=G1qrYlyFt48): - -* As a user, [unparalleled privacy](https://www.youtube.com/watch?v=SQHF4LkX7M8) for your communications -* As a [mix node operator](https://medium.com/nymtech/nym-mixnodes-deep-dive-d2b91917f097), rewards for your crucial role in operating our decentralized privacy infrastructure -* As a [delegator](https://medium.com/nymtech/want-to-stake-in-nym-here-is-how-to-choose-a-mix-node-to-delegate-nym-to-c3b862add165), rewards for securing the Nym network and ensuring outstanding quality of service - -Using the Nym network is free for now, but user fees will be introduced in the future and those will be paid in NYM tokens, so set them aside! And until then, you can contribute to running our decentralized infrastructure and earn mix mining rewards by setting up Nym mix nodes and bonding your tokens to them. You don't need to run nodes to contribute to the security and performance of the Nym network though. You can pledge your trust in someone else's node by delegating your NYM tokens to it, and receive a share of their mix mining rewards. - -You can find out more about how staking works in [this](https://www.youtube.com/watch?v=PcNGcTwlm0I) video from our Chief Scientist Claudia Diaz and if you need help setting up your mix node, choosing one to delegate your tokens to, or anything else, our community is there to help on [Discord](https://nymtech.net/go/discord) and [Telegram](https://t.me/nymchan). diff --git a/documentation/old_docs/dev-portal/src/glossary.md b/documentation/old_docs/dev-portal/src/glossary.md deleted file mode 100644 index 2e969c84b0..0000000000 --- a/documentation/old_docs/dev-portal/src/glossary.md +++ /dev/null @@ -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. diff --git a/documentation/old_docs/dev-portal/src/images/blockstream-green.gif b/documentation/old_docs/dev-portal/src/images/blockstream-green.gif deleted file mode 100644 index 33e2725c29..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/blockstream-green.gif and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/electrum_tutorial/electrum.gif b/documentation/old_docs/dev-portal/src/images/electrum_tutorial/electrum.gif deleted file mode 100644 index bbf2602539..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/electrum_tutorial/electrum.gif and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/element_nym_keybind.png b/documentation/old_docs/dev-portal/src/images/element_nym_keybind.png deleted file mode 100644 index d0bd383494..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/element_nym_keybind.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/firo_tutorial/firo.png b/documentation/old_docs/dev-portal/src/images/firo_tutorial/firo.png deleted file mode 100644 index ed1d7a0789..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/firo_tutorial/firo.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/icons/discord_icon.png b/documentation/old_docs/dev-portal/src/images/icons/discord_icon.png deleted file mode 100644 index 5b5cc32b0e..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/icons/discord_icon.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/icons/element_icon.png b/documentation/old_docs/dev-portal/src/images/icons/element_icon.png deleted file mode 100644 index 7c8db46df7..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/icons/element_icon.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/icons/telegram_icon.png b/documentation/old_docs/dev-portal/src/images/icons/telegram_icon.png deleted file mode 100644 index 0d2249f337..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/icons/telegram_icon.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/icons/twitter_icon.png b/documentation/old_docs/dev-portal/src/images/icons/twitter_icon.png deleted file mode 100644 index 0ae0d42f34..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/icons/twitter_icon.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/icons/youtube_icon.png b/documentation/old_docs/dev-portal/src/images/icons/youtube_icon.png deleted file mode 100644 index 88c0fe1143..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/icons/youtube_icon.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ifps-sp-image.png b/documentation/old_docs/dev-portal/src/images/ifps-sp-image.png deleted file mode 100644 index 12b6b92bba..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ifps-sp-image.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-1.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-1.png deleted file mode 100644 index 983455db54..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-1.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-2.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-2.png deleted file mode 100644 index 71f282a607..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-2.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-3.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-3.png deleted file mode 100644 index ec42093884..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/angular-app-3.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-1.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-1.png deleted file mode 100644 index 1deed94387..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-1.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-2.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-2.png deleted file mode 100644 index a1eb0cb92b..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-2.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-3.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-3.png deleted file mode 100644 index 194b847dd3..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/demo-ipfs-3.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-1.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-1.png deleted file mode 100644 index deed0f7980..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-1.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-2.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-2.png deleted file mode 100644 index b65bf187bc..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-2.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-3.png b/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-3.png deleted file mode 100644 index ed3123ea61..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ipfs-upload-service-tutorial/ipfs-user-client-3.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/matrix.png b/documentation/old_docs/dev-portal/src/images/matrix.png deleted file mode 100644 index 2ea4ae4bf0..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/matrix.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/matrix.webp b/documentation/old_docs/dev-portal/src/images/matrix.webp deleted file mode 100644 index 4faa931660..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/matrix.webp and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/monero_tutorial/monero-gui-NC.gif b/documentation/old_docs/dev-portal/src/images/monero_tutorial/monero-gui-NC.gif deleted file mode 100644 index f5ec96f462..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/monero_tutorial/monero-gui-NC.gif and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/monero_tutorial/monero.png b/documentation/old_docs/dev-portal/src/images/monero_tutorial/monero.png deleted file mode 100644 index 3c7fadd32a..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/monero_tutorial/monero.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/nym-client_image.png b/documentation/old_docs/dev-portal/src/images/nym-client_image.png deleted file mode 100644 index b954e08082..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/nym-client_image.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/nym-vs-animation.gif b/documentation/old_docs/dev-portal/src/images/nym-vs-animation.gif deleted file mode 100644 index 797978d74d..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/nym-vs-animation.gif and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/darkfi_over_nym_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/darkfi_over_nym_pp.png deleted file mode 100644 index 9ae44d85c1..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/darkfi_over_nym_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/ethereum_rpc_spook_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/ethereum_rpc_spook_pp.png deleted file mode 100644 index b7a593a68a..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/ethereum_rpc_spook_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/ethereum_transaction_broadcaster_root_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/ethereum_transaction_broadcaster_root_pp.png deleted file mode 100644 index 45755cf565..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/ethereum_transaction_broadcaster_root_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/minibolt_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/minibolt_pp.png deleted file mode 100644 index 455243cc22..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/minibolt_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/nym_dashboard_pp.svg b/documentation/old_docs/dev-portal/src/images/profile_picture/nym_dashboard_pp.svg deleted file mode 100644 index e91f3abdb4..0000000000 --- a/documentation/old_docs/dev-portal/src/images/profile_picture/nym_dashboard_pp.svg +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - - - - - - - diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/nymdrive_saleel_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/nymdrive_saleel_pp.png deleted file mode 100644 index a2fab0447f..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/nymdrive_saleel_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/nymgraph_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/nymgraph_pp.png deleted file mode 100644 index 411dbec6e0..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/nymgraph_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/nymstr_email_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/nymstr_email_pp.png deleted file mode 100644 index 404b9e2529..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/nymstr_email_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/pastenym_ntv_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/pastenym_ntv_pp.png deleted file mode 100644 index 79df7280f5..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/pastenym_ntv_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/profile_picture/pineappleproxy_pp.png b/documentation/old_docs/dev-portal/src/images/profile_picture/pineappleproxy_pp.png deleted file mode 100644 index fcb7ab5cd8..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/profile_picture/pineappleproxy_pp.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/send-to-gateway-dark.png b/documentation/old_docs/dev-portal/src/images/send-to-gateway-dark.png deleted file mode 100644 index 81fc8623e2..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/send-to-gateway-dark.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/simplest-request-dark.png b/documentation/old_docs/dev-portal/src/images/simplest-request-dark.png deleted file mode 100644 index b87d9d47fd..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/simplest-request-dark.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/sp-request-dark.png b/documentation/old_docs/dev-portal/src/images/sp-request-dark.png deleted file mode 100644 index 6eacac4b3c..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/sp-request-dark.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/ssp_image.png b/documentation/old_docs/dev-portal/src/images/ssp_image.png deleted file mode 100644 index 9a06073927..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/ssp_image.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/telegram.png b/documentation/old_docs/dev-portal/src/images/telegram.png deleted file mode 100644 index e65407a5b6..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/telegram.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/telegram.webp b/documentation/old_docs/dev-portal/src/images/telegram.webp deleted file mode 100644 index b9448ec965..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/telegram.webp and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/traffic-flow-dark.png b/documentation/old_docs/dev-portal/src/images/traffic-flow-dark.png deleted file mode 100644 index 01e28b4da4..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/traffic-flow-dark.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/tutorial_image_1.png b/documentation/old_docs/dev-portal/src/images/tutorial_image_1.png deleted file mode 100644 index a9ddda654b..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/tutorial_image_1.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/tutorial_image_2.png b/documentation/old_docs/dev-portal/src/images/tutorial_image_2.png deleted file mode 100644 index 394ace8046..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/tutorial_image_2.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/tutorial_image_4.png b/documentation/old_docs/dev-portal/src/images/tutorial_image_4.png deleted file mode 100644 index 50fcff9ec6..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/tutorial_image_4.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/tutorial_image_5.png b/documentation/old_docs/dev-portal/src/images/tutorial_image_5.png deleted file mode 100644 index 201b36c845..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/tutorial_image_5.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/images/wallet-proxy-settings/blockstream-green.gif b/documentation/old_docs/dev-portal/src/images/wallet-proxy-settings/blockstream-green.gif deleted file mode 100644 index 33e2725c29..0000000000 Binary files a/documentation/old_docs/dev-portal/src/images/wallet-proxy-settings/blockstream-green.gif and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/info-request.md b/documentation/old_docs/dev-portal/src/info-request.md deleted file mode 100644 index e3edbdc3de..0000000000 --- a/documentation/old_docs/dev-portal/src/info-request.md +++ /dev/null @@ -1,14 +0,0 @@ -# Change Service Grantee Information - -If you wish to update any of the following information: - - `Email Address` - - `NYM address` - - `Network Requester` - - `Gateway ID Key` - - `Gateway Address` - - `Service` - - `Payment Address` - -Please reach out either in the `#service-grantees` channel on Discord or on [Matrix](https://matrix.to/#/#nym-community:nymtech.chat). - - diff --git a/documentation/old_docs/dev-portal/src/infrastructure/node-types.md b/documentation/old_docs/dev-portal/src/infrastructure/node-types.md deleted file mode 100644 index cb5e9c3d35..0000000000 --- a/documentation/old_docs/dev-portal/src/infrastructure/node-types.md +++ /dev/null @@ -1,14 +0,0 @@ -# Node Types - -Discover the workings of Nym's privacy-enhancing mixnet infrastructure through the below video, where we break down the different types of nodes and how they each play a crucial role in ensuring secure and anonymous communication. - - - -### Where do I go from here? 💭 - -For more in-depth information on the network architecture, head to the [Network Overview page](https://nymtech.net/docs/architecture/network-overview.html), and check out the [Operators book](https://nymtech.net/operators) if you want to run a node yourself. - -If you would like to concentrate on building an application that uses the mixnet: -* Explore the [Quickstart](../quickstart/overview.md) options. -* Check out examples of [Community Apps](../community-resources/community-applications-and-guides.md). -* Run through the [Rust SDK](../tutorials/rust-sdk.md) or [Typescript](../tutorials/typescript.md) tutorials. diff --git a/documentation/old_docs/dev-portal/src/infrastructure/nym.md b/documentation/old_docs/dev-portal/src/infrastructure/nym.md deleted file mode 100644 index 53bc4b377f..0000000000 --- a/documentation/old_docs/dev-portal/src/infrastructure/nym.md +++ /dev/null @@ -1,33 +0,0 @@ -# What is Nym? - -Nym is a privacy platform that secures user data and protects against surveillance. It leverages the [mixnet](./node-types.md), a type of overlay network that makes both content and metadata of transactions private through network-level obfuscation and incentivisation, and [Coconut](https://nymtech.net/docs/coconut.html), a privacy technology that creates an application-level private access control layer. Nym also utilises [Nyx](https://blog.nymtech.net/nym-now-supports-smart-contracts-2186da46bc7f), our Cosmos SDK blockchain, to allow for us to use payment tokens in the form of `NYM`, as well as smart contracts, in order to create a robust, decentralised, and secure environment for the mixnet. In a nutshell, Nym is a solution that provides strong privacy protection for users in the digital world. - -> All the technical nuances about Nym platform can come out quite complex at first. Look for any questions in the [FAQ section](../faq/general-faq.md), take part in our [DevRel AMAs](../community-resources/ama.md) or seek support in [Nym's community](https://nymtech.net/community) - -### An overlay network for network-level traffic privacy -Our mixnet design is based on the [Loopix Anonymity System](https://arxiv.org/abs/1703.00536), somewhat modified to provide better quality of service guarantees. - -In this brief video, our Head of Research and creator of the Loopix mixnet paper, Ania Piotrowska, delves into the design of the Loopix mixnet in depth at USENix 2017. - - - - -The Nym mixnet effectively addresses privacy concerns by utilizing network nodes to mix messages, making them unidentifiable to adversaries. Each packet is layer encrypted, and binary-padded so that it's indistinguishable from all other packets. Incoming packets are "mixed" with all other messages inside the node. That is, the node strips one layer of packet encryption, and adds a small random transmission delay, so that messages are not emitted in the same order as which they arrived. - -Next, the message is sent to another mix node, decrypted and mixed again, then to a third mixnode for further mixing. Finally, the message is delivered to its destination gateway. - -As long as there's enough traffic flowing through the nodes, even an adversary who can monitor the entire network cannot trace the packet flow through the system. - -Privacy Enhanced Applications (PEApps) that need to defend against network-level monitoring can utilize the Nym mixnet to protect against network-level surveillance. - -### Revolutionising Privacy: An Incentivized Mixnet, the First of its Kind -Nym is the first mixnet to incentivise its node operators via a cryptocurrency: the `NYM` token. The tokenomic design of Nym ensures that nodes are motivated to provide top-notch performance and robust security, as they are financially rewarded for doing so. The video below contains an explanation of Nym's tokenomic design from Nym's Chief Scientist Claudia Diaz: - - - -### ELI5 Understanding of the Implications of Nym -Nym is a type of technology that is designed to keep your online activities private from surveillance networks which track users of many online services. As well as protecting the contents of your messages - the data - Nym's design means that metadata - data about the data - is also kept private. This means that the location from which you sent your message, the time you did so, and a lot of information about your network connection is kept private: this is information that can be used to deanonymise users of other privacy systems, even if they employ encrypted messaging! - -Nym works by "mixing" your data with other users' data, making it much more difficult for anyone to single out and track just your information. - -This system is unique because it provides an incentive for people to participate and help improve the network, making it stronger and more secure for everyone. By breaking down Nym and understanding its implications, you can see why it's an important tool for anyone who values their privacy online. diff --git a/documentation/old_docs/dev-portal/src/integrations/integration-options.md b/documentation/old_docs/dev-portal/src/integrations/integration-options.md deleted file mode 100644 index 5c7d417420..0000000000 --- a/documentation/old_docs/dev-portal/src/integrations/integration-options.md +++ /dev/null @@ -1,12 +0,0 @@ -# Integration Options -If you've already gone through the different 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. - -> If you wish to integrate with the Nyx blockchain to use `NYM` for payments, start with the [payment integration](./payment-integration.md) page. - - diff --git a/documentation/old_docs/dev-portal/src/integrations/mixnet-integration.md b/documentation/old_docs/dev-portal/src/integrations/mixnet-integration.md deleted file mode 100644 index a26f0a885b..0000000000 --- a/documentation/old_docs/dev-portal/src/integrations/mixnet-integration.md +++ /dev/null @@ -1,175 +0,0 @@ -# Integrating with Nym for network privacy -If you are wanting to integrate Nym by using the Mixnet as a transport layer for application traffic, you will have to run one of the three Nym clients in order to connect to the Mixnet. - -## Connecting applications to the mixnet -### SDK support -If your app is written in Typescript or Rust, then you can use the [Typescript](https://nymtech.net/docs/sdk/typescript.html) or [Rust](https://nymtech.net/docs/sdk/rust.html) SDKs. These SDKs abstract away much of the messaging logic from your app, and allow you to run a Nym client as part of your application process, instead of having to run them seperately. - -### Choosing a client -In order to connect your application to the mixnet, you need to select one of three clients to use. These clients do the majority of the heavy-lifting with regards to cryptographic operations and routing under the hood, and all do basically the same thing: create a connection to a gateway, encrypt and decrypt packets sent to and received from the mixnet, and send cover traffic to hide the flow of actual app traffic from observers. - -As outlined in the [clients overview documentation](https://nymtech.net/docs/clients/overview.html) there are three clients availiable to developers to use when connecting applications to the mixnet: - -#### Websocket client -Your first option is the native websocket client. This is a compiled program that can run on Linux, Mac OS X, and Windows machines. It runs as a persistent process on a desktop or server machine. You can connect to it with any language that supports websockets. - -[//]: # (You can see an example of how to connect to and manage interactions with this client in the [Simple Service Provider tutorial](../tutorials/simple-service-provider/simple-service-provider.md).) - -#### Webassembly client -If you’re working in JavaScript or Typescript in the browser, or building an edge computing app, you’ll likely want to choose the webassembly client. - -It’s packaged and available on the npm registry, so you can npm install it into your JavaScript or TypeScript application. - -The webassembly client is most easily used via the [typescript sdk](https://nymtech.net/docs/sdk/typescript.html). - -You can find example code in the [examples section](https://github.com/nymtech/nym/tree/master/sdk/typescript/examples) of the codebase, and in the [typescript sdk docs](https://nymtech.net/docs/sdk/typescript.html). - -#### SOCKS client -This client is useful for allowing existing applications to use the Nym mixnet without any code changes. All that’s necessary is that they can use one of the SOCKS5, SOCKS4a, or SOCKS4 proxy protocols (which many applications can - crypto wallets, browsers, chat applications etc). - -It’s less flexible as a way of writing custom applications than the other clients, but able to be used to proxy application traffic through the mixnet without having to make any code changes. - -You can find examples of how to utilise this client in the [Quickstart](../quickstart/socks-proxy.md) section, and the [SOCKS5 documentation](https://nymtech.net/docs/clients/socks5-client.html). - -## Recommended infrastructure setup -In order to ensure uptime and reliability, it is recommended that you run some pieces of mixnet infrastructure. What infrastructure is necessary to run depends on the architecture of your application, and the endpoints that it needs to hit! - -* If you're running a purely P2P application, then just integrating clients and having some method of sharing addresses should be enough to route your traffic through the mixnet. -* If you're wanting to place the mixnet between your users' application instances and a server-based backend, you can use the [network requester](https://nymtech.net/operators/nodes/network-requester-setup.html) service provider binary to proxy these requests to your application backend, with the mixnet 'between' the user and your service, in order to prevent metadata leakage being broadcast to the internet. -* If you're wanting to route RPC requests through the mixnet to a blockchain, you will need to look into setting up some sort of service that does the transaction broadcasting for you. You can find examples of such projects on the [community applications](../community-resources/community-applications-and-guides.md) page. - -## Example application traffic flow -### Initialization -First, we need to initalise an app and connect it to Nym. - - -``` - +-----------+ - | Gateway | - +-----------+ - ^ - | - | - | - | - | - | - +-------------------+ - | +---------------+ | - | | Nym client | | - | +---------------+ | - | ^ | - | | | - | | | - | | | - | v | - | +---------------+ | - | | Your app code | | - | +---------------+ | - +-------------------+ - Your Local Machine -``` - -At the bottom we have an app. It consists of two parts: - -* your application specific logic -* your Nym client - either running as a standalone process, or as part of the process of your app code if you're using an SDK - -Nym apps have a stable, potentially long-lasting relation to a gateway node. A client will register itself with a gateway, and get back an authentication token that it can then use to retrieve messages from the gateway later on. - -Gateways serve a few different functions: - -* they act as an end-to-end encrypted message store in case your app goes offline. -* they send encrypted surb-acks for potentially offline recipients, to ensure reliable message delivery -* they offer a stable addressing location for apps, although the IP may change frequently - -### Sending messages to ourselves -The Nym client part of the app accepts messages from your code and automatically turns it into layer-encrypted Sphinx packets. If your message is too big to fit inside on Sphinx packet, it'll be split into multiple packets with a sequence numbers to ensure reliable automatic reassembly of the full message when it gets to the recipient. - -The app has now connected to the Gateway, but we haven't sent a message to ourselves yet. Let's do that now. - -``` - - +----------+ +----------+ +----------+ - | Mix Node |<-----------> | Mix Node |<----------->| Mix Node | - | Layer 1 | | Layer 2 | | Layer 3 | - +----------+ +----------+ +----------+ - ^ ^ - | | - |<--------------------------------------------------+ - | - v - +--------------+ - | Your gateway | - +--------------+ - ^ - | - | - v - +-------------------+ - | +---------------+ | - | | Nym client | | - | +---------------+ | - | ^ | - | | | - | | | - | v | - | +---------------+ | - | | Your app code | | - | +---------------+ | - +-------------------+ - Your Local Machine** - - -** note that depending on the technical setup, the Nym client running on this machine may -be either a seperate process or embedded in the same process as the app code via one of our SDKs. -``` - -Let's say your code code pokes a message `hello world` into the Nym client. The Nym client automatically wraps that message up into a layer encrypted Sphinx packet, adds some routing information and encryption, and sends it to its own gateway. The gateway strips the first layer of encryption, ending up with the address of the first mixnode it should forward to, and a Sphinx packet. - -The gateway forwards the Sphinx packet containing the `hello world` message. Each mixnode in turn forwards to the next mixnode. The last mixnode forwards to the recipient gateway (in this case, our own gateway since we are sending to ourselves). - -Our app has presumably not gone offline in the short time since the message was sent. So when the gateway receives the packet, it decrypts the packet and sends the (encrypted) content back to our app. - -The Nym client inside the app decrypts the message, and your code receives the message `hello world`, again as a websocket event. - -Messages are end-to-end encrypted. Although the gateway knows our app's IP when it connects, it's unable to read any of the message contents. - -### Sending messages to other apps -The process for sending messages to other apps is exactly the same, you simply specify a different recipient address. Address discovery happens outside the Nym system: in the case of a Service Provider app, the service provider has presumably advertised its own address. If you're sending to a friend of yours, you'll need to get a hold of their address out of band, maybe through a private messaging app such as Signal. - -``` - - +----------+ +----------+ +----------+ - | Mix Node |<-----------> | Mix Node |<----------->| Mix Node | - | Layer 1 | | Layer 2 | | Layer 3 | - +----------+ +----------+ +----------+ - ^ ^ - | | - | | - v v - +--------------+ +-----------------+ - | Your gateway | | Service gateway | - +--------------+ +-----------------+ - ^ ^ - | | - | | - v v - +-------------------+ +-------------------+ - | +---------------+ | | +---------------+ | - | | Nym client | | | | Nym Client | | - | +---------------+ | | +---------------+ | - | ^ | | ^ | - | | | | | | - | | | | | | - | v | | v | - | +---------------+ | | +---------------+ | - | | Your app code | | | | Service Code | | - | +---------------+ | | +---------------+ | - +-------------------+ +-------------------+ - Your Local Machine** Service Provider Machine** - - -** note that depending on the technical setup, the Nym client running on these machines may -be either a seperate process or embedded in the same process as the app code via one of our SDKs. -``` diff --git a/documentation/old_docs/dev-portal/src/integrations/payment-integration.md b/documentation/old_docs/dev-portal/src/integrations/payment-integration.md deleted file mode 100644 index 937702a3bd..0000000000 --- a/documentation/old_docs/dev-portal/src/integrations/payment-integration.md +++ /dev/null @@ -1,16 +0,0 @@ -# Integrating with Nyx for payments - -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/). - -### 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). - -### Chain information and RPC endpoints -You can find most information required for integration in the [Cosmos Chain Registry](https://github.com/cosmos/chain-registry/blob/master/nyx/chain.json) and [Keplr Chain Registry](https://github.com/chainapsis/keplr-chain-registry/blob/main/cosmos/nyx.json) repositories. - -## Recommended setup -We recommend that users wanting to integrate with Nyx for cryptocurrency payments set up their own RPC Node, in order to be able to reliably query the blockchain and send transactions without having to worry about relying on 3rd party validators. - -The guide to setting up an RPC node can be found [here](https://nymtech.net/docs/nyx/rpc-node.html). diff --git a/documentation/old_docs/dev-portal/src/introduction.md b/documentation/old_docs/dev-portal/src/introduction.md deleted file mode 100644 index 742853c56c..0000000000 --- a/documentation/old_docs/dev-portal/src/introduction.md +++ /dev/null @@ -1,9 +0,0 @@ -# Introduction - -Welcome to the Nym Developer Portal, containing quickstart resources, user manuals, integration information, and tutorials outlining to start building privacy enhanced apps. - -For more in-depth information about nodes, network traffic flows, clients, coconut etc check out the [docs](https://nymtech.net/docs). - -If you are looking for information and setup guides for the various pieces of Nym mixnet infrastructure (mix nodes, gateways and network requesters) and Nyx blockchain validators see the [Operators Guides](https://nymtech.net/operators) book. - -If you're looking for TypeScript/JavaScript related information such as SDKs to build your own tools, step-by-step tutorials, live playgrounds and more, make sure to check out the [TS SDK Handbook](https://sdk.nymtech.net/). diff --git a/documentation/old_docs/dev-portal/src/licensing.md b/documentation/old_docs/dev-portal/src/licensing.md deleted file mode 100644 index b569231b75..0000000000 --- a/documentation/old_docs/dev-portal/src/licensing.md +++ /dev/null @@ -1,11 +0,0 @@ -# Licensing - -As a general approach, licensing is as follows this pattern: - -*

Nym Documentation by Nym Technologies is licensed under CC BY-NC-SA 4.0

- -* Nym applications and binaries are [GPL-3.0-only](https://www.gnu.org/licenses/) - -* Used libraries and different components are [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) or [MIT](https://mit-license.org/) - -For accurate information, please check individual files. diff --git a/documentation/old_docs/dev-portal/src/not-found.md b/documentation/old_docs/dev-portal/src/not-found.md deleted file mode 100644 index 704da5ec19..0000000000 --- a/documentation/old_docs/dev-portal/src/not-found.md +++ /dev/null @@ -1,11 +0,0 @@ -# Page Not Found - -You seem to have followed a link to a page that no longer exists. Our documentation is changing and growing over time, so this page has most likely been moved somewhere else. - -For node setup guides, see the [Operator Guides book](https://nymtech.net/operators). - -For information on network architecture traffic flow, clients, the SDKs, or interacting with the Nyx blockchain see the [Technical Documentation](https://nymtech.net/docs). - -If you are looking for information on developer tutorials, app guides, and demo and community apps, check the sitemap on the left hand side of the screen. - -If you still can't find what you're looking for get in touch with us via [Matrix](https://matrix.to/#/#nym-community:nymtech.chat). \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/nymvpn/cli-linux.md b/documentation/old_docs/dev-portal/src/nymvpn/cli-linux.md deleted file mode 100644 index 5d742a5d43..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/cli-linux.md +++ /dev/null @@ -1,142 +0,0 @@ -# NymVPN alpha CLI Guide - -```admonish info -NymVPN is an experimental software and it's for testing purposes only. All users testing the client are expected to sign GDPR Information Sheet and Consent Form (shared at the workshop) so we use their results to improve the client, and submit the form [*NymVPN User research*]({{nym_vpn_form_url}}) with the testing results. -``` - -## Installation - -> Any syntax in `<>` brackets is a user's/version unique variable. Exchange with a corresponding name without the `<>` brackets. - -1. Open Github [releases page]({{nym_vpn_releases}}) and download the CLI latest binary for your system - -2. Verify sha hash of your downloaded binary with the one listed on the [releases page]({{nym_vpn_releases}}). You can use a simple `shasum` command and compare strings (ie with Python) or run in the same directory the following command, exchanging `` with the one of your binary, like in the example: -```sh -echo "" | shasum -a 256 -c - -# choose a correct one according to your binary, this is just an example -# echo "0e4abb461e86b2c168577e0294112a3bacd3a24bf8565b49783bfebd9b530e23 nym-vpn-cli__ubuntu-22.04_amd64.tar.gz" | shasum -a 256 -c -``` - -3. Extract files: -```sh -tar -xvf .tar.gz -# for example -# tar -xvf nym-vpn-cli__ubuntu-22.04_x86_64.tar.gz -``` - -4. Make executable: -```sh -# make sure you are in the right sub-directory -chmod u+x ./nym-vpn-cli -``` - -## Run NymVPN - -**For NymVPN to work, all other VPNs must be switched off!** At this alpha stage of NymVPN, the network connection (wifi) must be reconnected after or in between the testing rounds. - -Make sure your terminal is open in the same directory as your `nym-vpn-cli` binary. - -1. Go to [nymvpn.com/en/alpha](https://nymvpn.com/en/alpha) to get the entire command with all the needed arguments' values and your wireguard private key for testing purposes -2. Run it as root with `sudo` - the command will look like this with specified arguments: -```sh -sudo ./nym-vpn-cli -c ./sandbox.env --entry-gateway-id --exit-router-address --enable-wireguard --private-key --wg-ip -``` -3. To choose different Gateways, visit [explorer.nymtech.net/network-components/gateways](https://explorer.nymtech.net/network-components/gateways) and copy-paste an identity key of your choice -4. See all possibilities in [command explanation](#cli-commands-and-options) section below - -In case of errors, see [troubleshooting section](troubleshooting.md). - -### CLI Commands and Options - -The basic syntax of `nym-vpn-cli` is: -```sh -sudo ./nym-vpn-cli <--exit-router-address |--exit-gateway-id |--exit-gateway-country > -``` -* To choose different Gateways, visit [nymvpn.com/en/alpha/api/gateways](https://explorer.nymtech.net/network-components/gateways) -* To see all possibilities run with `--help` flag: -```sh -./nym-vpn-cli --help -``` -~~~admonish example collapsible=true title="Console output" -```sh -Usage: nym-vpn-cli [OPTIONS] <--exit-router-address |--exit-gateway-id |--exit-gateway-country > - -Options: - -c, --config-env-file - Path pointing to an env file describing the network - --mixnet-client-path - Path to the data directory of a previously initialised mixnet client, where the keys reside - --entry-gateway-id - Mixnet public ID of the entry gateway - --entry-gateway-country - Auto-select entry gateway by country ISO - --entry-gateway-low-latency - Auto-select entry gateway by latency - --exit-router-address - Mixnet recipient address - --exit-gateway-id - - --exit-gateway-country - Mixnet recipient address - --enable-wireguard - Enable the wireguard traffic between the client and the entry gateway - --private-key - Associated private key - --wg-ip - The IP address of the wireguard interface used for the first hop to the entry gateway - --nym-ipv4 - The IPv4 address of the nym TUN device that wraps IP packets in sphinx packets - --nym-ipv6 - The IPv6 address of the nym TUN device that wraps IP packets in sphinx packets - --nym-mtu - The MTU of the nym TUN device that wraps IP packets in sphinx packets - --disable-routing - Disable routing all traffic through the nym TUN device. When the flag is set, the nym TUN device will be created, but to route traffic through it you will need to do it manually, e.g. ping -Itun0 - --enable-two-hop - Enable two-hop mixnet traffic. This means that traffic jumps directly from entry gateway to exit gateway - --enable-poisson-rate - Enable Poisson process rate limiting of outbound traffic - --disable-background-cover-traffic - Disable constant rate background loop cover traffic - -h, --help - Print help - -V, --version - Print version -``` -~~~ - -Here is a list of the options and their descriptions. Some are essential, some are more technical and not needed to be adjusted by users. - -**Fundamental commands and arguments** - -- `-c` is a path to the [Sandbox config](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) file saved as `sandbox.env` -- `--entry-gateway-id`: paste one of the values labeled with a key `"identityKey"` (without `" "`) from [here](https://nymvpn.com/en/alpha/api/gateways) -- `--exit-router-address`: paste one of the values labeled with a key `"address"` (without `" "`) from here [here](https://nymvpn.com/en/alpha/api/gateways) -- `--enable-wireguard`: Enable the wireguard traffic between the client and the entry gateway. NymVPN uses Mullvad libraries for wrapping `wireguard-go` and to setup local routing rules to route all traffic to the TUN virtual network device -- `--wg-ip`: The address of the wireguard interface, you can get it [here](https://nymvpn.com/en/alpha) -- `--private-key`: get your private key for testing purposes [here](https://nymvpn.com/en/alpha) -- `--enable-two-hop` is a faster setup where the traffic is routed from the client to Entry Gateway and directly to Exit Gateway (default is 5-hops) - -**Advanced options** - -- `--enable-poisson`: Enables process rate limiting of outbound traffic (disabled by default). It means that NymVPN client will send packets at a steady stream to the Entry Gateway. By default it's on average one sphinx packet per 20ms, but there is some randomness (poisson distribution). When there are no real data to fill the sphinx packets with, cover packets are generated instead. -- `--ip` is the IP address of the TUN device. That is the IP address of the local private network that is set up between local client and the Exit Gateway. -- `--mtu`: The MTU of the TUN device. That is the max IP packet size of the local private network that is set up between local client and the Exit Gateway. -- `--disable-routing`: Disable routing all traffic through the VPN TUN device. - -## Testnet environment - -If you want to run NymVPN CLI in Nym Sandbox environment, there are a few adjustments to be done: - -1. Create Sandbox environment config file by saving [this](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) as `sandbox.env` in the same directory as your NymVPN binaries by running: -```sh -curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env -``` - -1. Check available Gateways at [nymvpn.com/en/alpha/api/gateways](https://nymvpn.com/en/alpha/api/gateways) - -2. Run with a flag `-c` -```sh -sudo ./nym-vpn-cli -c /sandbox.env <--exit-router-address |--exit-gateway-id |--exit-gateway-country > -``` diff --git a/documentation/old_docs/dev-portal/src/nymvpn/cli-mac.md b/documentation/old_docs/dev-portal/src/nymvpn/cli-mac.md deleted file mode 100644 index 9ae4039cdc..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/cli-mac.md +++ /dev/null @@ -1,123 +0,0 @@ -# NymVPN alpha CLI: Guide for MacOS - -```admonish info -NymVPN is an experimental software and it's for testing purposes only. All users testing the client are expected to sign GDPR Information Sheet and Consent Form (shared at the workshop) so we use their results to improve the client, and submit the form [*NymVPN User research*]({{nym_vpn_form_url}}) with the testing results. -``` - -## Preparation - -> Any syntax in `<>` brackets is a user's/version unique variable. Exchange with a corresponding name without the `<>` brackets. - -1. Open Github [releases page]({{nym_vpn_releases}}) and download the binary for MacOS -2. Verify sha hash of your downloaded binary with the one listed on the [releases page]({{nym_vpn_releases}}). You can use a simple `shasum` command and compare strings (ie with Python) or run in the same directory the following command, exchanging `` with the one of your binary, like in the example: -```sh -echo "" | shasum -a 256 -c - -# choose a correct one according to your binary, this is just an example -# echo "96623ccc69bc4cc0e4e3e18528b6dae6be69f645d0a592d926a3158ce2d0c269 nym-vpn-cli__macos_x86_64.zip" | shasum -a 256 -c -``` -3. Extract files: -```sh -tar -xvf -# for example -# tar -xvf nym-vpn-cli__macos_aarch64.tar.gz -``` -4. Make executable by running: -```sh -# possibly you may have to cd into a sub-directory -chmod u+x ./nym-vpn-cli -``` -5. Create Sandbox environment config file by saving [this](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) as `sandbox.env` in the same directory as your NymVPN binaries by running: -```sh -curl -L "https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env" -o sandbox.env -``` - -## Run NymVPN - -**For NymVPN to work, all other VPNs must be switched off!** At this alpha stage of NymVPN, the network connection (wifi) must be reconnected after or in between the testing rounds. - -Make sure your terminal is open in the same directory as your `nym-vpn-cli` binary. - -1. Go to [nymvpn.com/en/alpha](https://nymvpn.com/en/alpha) to get the entire command with all the needed arguments' values and your wireguard private key for testing purposes -2. Run it as root with `sudo` - the command will look like this with specified arguments: -```sh -sudo ./nym-vpn-cli -c ./sandbox.env --entry-gateway-id --exit-router-address --enable-wireguard --private-key --wg-ip -``` -3. To choose different Gateways, visit [nymvpn.com/en/alpha/api/gateways](https://nymvpn.com/en/alpha/api/gateways) and pick one -4. See all possibilities in [command explanation](#cli-commands-and-options) section below - -In case of errors, see [troubleshooting section](troubleshooting.md). - -### CLI Commands and Options - -The basic syntax of `nym-vpn-cli` is: -```sh -sudo ./nym-vpn-cli -c ./sandbox.env --entry-gateway-id --exit-router-address --enable-wireguard --private-key --wg-ip -``` -* To choose different Gateways, visit [nymvpn.com/en/alpha/api/gateways](https://nymvpn.com/en/alpha/api/gateways) -* To see all possibilities run with `--help` flag: -```sh -./nym-vpn-cli --help -``` -~~~admonish example collapsible=true title="Console output" -```sh -Usage: nym-vpn-cli [OPTIONS] - -Options: - -c, --config-env-file - Path pointing to an env file describing the network - --mixnet-client-path - Path to the data directory of a previously initialised mixnet client, where the keys reside - --entry-gateway-id - Mixnet public ID of the entry gateway - --entry-gateway-country - Auto-select entry gateway by country ISO - --exit-router-address - Mixnet recipient address - --exit-gateway-id - - --exit-router-country - Mixnet recipient address - --enable-wireguard - Enable the wireguard traffic between the client and the entry gateway - --private-key - Associated private key - --wg-ip - The IP address of the wireguard interface used for the first hop to the entry gateway - --nym-ip - The IP address of the nym TUN device that wraps IP packets in sphinx packets - --nym-mtu - The MTU of the nym TUN device that wraps IP packets in sphinx packets - --disable-routing - Disable routing all traffic through the nym TUN device. When the flag is set, the nym TUN device will be created, but to route traffic through it you will need to do it manually, e.g. ping -Itun0 - --enable-two-hop - Enable two-hop mixnet traffic. This means that traffic jumps directly from entry gateway to exit gateway - --enable-poisson-rate - Enable Poisson process rate limiting of outbound traffic - --disable-background-cover-traffic - Disable constant rate background loop cover traffic - -h, --help - Print help - -V, --version - Print version -``` -~~~ - -Here is a list of the options and their descriptions. Some are essential, some are more technical and not needed to be adjusted by users. - -**Fundamental commands and arguments** - -- `-c` is a path to the [Sandbox config](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) file saved as `sandbox.env` -- `--entry-gateway-id`: paste one of the values labeled with a key `"identityKey"` (without `" "`) from [here](https://nymvpn.com/en/alpha/api/gateways) -- `--exit-router-address`: paste one of the values labeled with a key `"address"` (without `" "`) from here [here](https://nymvpn.com/en/alpha/api/gateways) -- `--enable-wireguard`: Enable the wireguard traffic between the client and the entry gateway. NymVPN uses Mullvad libraries for wrapping `wireguard-go` and to setup local routing rules to route all traffic to the TUN virtual network device -- `--wg-ip`: The address of the wireguard interface, you can get it [here](https://nymvpn.com/en/alpha) -- `--private-key`: get your private key for testing purposes [here](https://nymvpn.com/en/alpha) -- `--enable-two-hop` is a faster setup where the traffic is routed from the client to Entry Gateway and directly to Exit Gateway (default is 5-hops) - -**Advanced options** - -- `--enable-poisson`: Enables process rate limiting of outbound traffic (disabled by default). It means that NymVPN client will send packets at a steady stream to the Entry Gateway. By default it's on average one sphinx packet per 20ms, but there is some randomness (poisson distribution). When there are no real data to fill the sphinx packets with, cover packets are generated instead. -- `--ip` is the IP address of the TUN device. That is the IP address of the local private network that is set up between local client and the Exit Gateway. -- `--mtu`: The MTU of the TUN device. That is the max IP packet size of the local private network that is set up between local client and the Exit Gateway. -- `--disable-routing`: Disable routing all traffic through the VPN TUN device. diff --git a/documentation/old_docs/dev-portal/src/nymvpn/cli.bak b/documentation/old_docs/dev-portal/src/nymvpn/cli.bak deleted file mode 100644 index f040b9cff2..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/cli.bak +++ /dev/null @@ -1,35 +0,0 @@ -# NymVPN Command Line Interface (CLI) - -```admonish info -Our alpha testing round is done with participants at live workshop events. This guide will not work for everyone, as the NymVPN source code is not yet publicly accessible. The alpha testing is done on Nym testnet Sandbox environment, this configuration is limited and will not work in the future. - -**If you commit to test NymVPN alpha, please start with the [user research form]({{nym_vpn_form_url}}) where all the steps will be provided**. If you disagree with any of the conditions listed, please leave this page. -``` - -Follow the simple [automated script](#automated-script-for-cli-installation) below to install and run NymVPN CLI. If you prefer to do a manual setup follow the steps in the guide for [Linux](cli-linux.md) or [MacOS](cli-mac.md). - -Visit NymVPN alpha latest [release page]({{nym_vpn_releases}}) to check sha sums or download the binaries directly. - -## Automated Script for CLI Installation - -We wrote a [script](https://gist.github.com/serinko/d65450653d6bbafacbcee71c9cb8fb31) which does download of the CLI, sha256 verification, extraction, installation and configuration for Linux and MacOS users automatically following the steps below: - -1. Open a terminal window in a directory where you want the script and NymVPN CLI binary be downloaded and run -```sh -curl -o execute-nym-vpn-cli-binary.sh -L https://gist.githubusercontent.com/tommyv1987/87267ded27e1eb7651aa9cc745ddf4af/raw/d39f98dbb36ccff761a7e940073388a6fe7b73fe/execute-nym-vpn-cli-binary.sh && chmod u+x execute-nym-vpn-cli-binary.sh && sudo -E ./execute-nym-vpn-cli-binary.sh -``` - -2. Follow the prompts in the program - -3. The script will automatically start the client. Make sure to **turn off any other VPNs** and follow the prompts: - -* It prints a JSON view of existing Gateways and prompt you to: - - *Make sure to use two different Gateways for entry and exit!* - - `enter a gateway ID:` paste one of the values labeled with a key `"identityKey"` printed above (without `" "`) - - `enter an exit address:` paste one of the values labeled with a key `"address"` printed above (without `" "`) - - `do you want five hop or two hop?`: type `five` or `two` - - `enable WireGuard? (yes/no):` if you chose yes, find your private key and wireguard IP [here](https://nymvpn.com/en/alpha) - -To run `nym-vpn-cli` again, reconnect your wifi, move to the directory of your CLI binary `cd ~/nym-vpn-cli-dir` and follow the guide for [Linux](cli-linux.md#run-nymvpn) or [MacOS](cli-mac.md#run-nymvpn). If you find it too difficult, just run this script again - like in step \#3 above. - -In case of errors check out the [troubleshooting](troubleshooting.md) section. diff --git a/documentation/old_docs/dev-portal/src/nymvpn/gui-linux.md b/documentation/old_docs/dev-portal/src/nymvpn/gui-linux.md deleted file mode 100644 index e77945d9eb..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/gui-linux.md +++ /dev/null @@ -1,85 +0,0 @@ -# NymVPN alpha - Desktop: Guide for GNU/Linux - -
- -```admonish info -NymVPN is an experimental software and it's for testing purposes only. All users testing the client are expected to sign GDPR Information Sheet and Consent Form (shared at the workshop) so we use their results to improve the client, and submit the form [*NymVPN User research*]({{nym_vpn_form_url}}) with the testing results. -``` - -## Preparation - -> Any syntax in `<>` brackets is a user's/version unique variable. Exchange with a corresponding name without the `<>` brackets. - -### Installation - -1. Open Github [releases page]({{nym_vpn_releases}}) and download the binary for Debian based Linux - -2. (Optional: if you don't want to check shasum, skip this point) Verify sha hash of your downloaded binary with the one listed on the [releases page]({{nym_vpn_releases}}). You can use a simple `shasum` command and compare strings (ie with Python) or run in the same directory the following command, exchanging `` with the one of your binary, like in the example: -```sh -echo "" | shasum -a 256 -c - -# choose a correct one according to your binary, this is just an example -# echo "a5f91f20d587975e30b6a75d3a9e195234cf1269eac278139a5b9c39b039e807 nym-vpn-desktop__ubuntu-22.04_x86_64.tar.gz" | shasum -a 256 -c -``` - -3. Extract files: -```sh -tar -xvf .tar.gz -# for example -# tar -xvf nym-vpn-desktop__ubuntu-22.04_x86_64.tar.gz -``` - -4. If you prefer to run `.AppImage` make executable by running: -```sh -# make sure you cd into the right sub-directory after extraction -chmod u+x ./nym-vpn__amd64.AppImage -``` - -5. If you prefer to use the `.deb` version for installation (works on Debian based Linux only), open terminal in the same directory and run: -```sh -# make sure you cd into the right sub-directory after extraction -sudo dpkg -i ./nym-vpn__amd64.deb -# or -sudo apt-get install -f ./nym-vpn__amd64.deb -``` - - - -## Run NymVPN - -**For NymVPN to work, all other VPNs must be switched off!** At this alpha stage of NymVPN, the network connection (wifi) must be reconnected after or in between the testing rounds. - -In case you used `.deb` package and installed the client, you may be able to have a NymVPN application icon in your app menu. However this may not work as the application needs root permission. - -Open terminal and run: - -```sh -# .AppImage must be run from the same directory as the binary -sudo -E ./nym-vpn__amd64.AppImage - -# .deb installation shall be executable from anywhere as -sudo -E nym-vpn -``` - -In case of errors, see [troubleshooting section](troubleshooting.md). diff --git a/documentation/old_docs/dev-portal/src/nymvpn/gui-mac.md b/documentation/old_docs/dev-portal/src/nymvpn/gui-mac.md deleted file mode 100644 index f3f3ccb89b..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/gui-mac.md +++ /dev/null @@ -1,65 +0,0 @@ -# NymVPN alpha - Desktop: Guide for Mac OS - -```admonish info -NymVPN is an experimental software and it's for testing purposes only. All users testing the client are expected to sign GDPR Information Sheet and Consent Form (shared at the workshop) so we use their results to improve the client, and submit the form [*NymVPN User research*]({{nym_vpn_form_url}}) with the testing results. -``` - -## Preparation - -> Any syntax in `<>` brackets is a user's/version unique variable. Exchange with a corresponding name without the `<>` brackets. - -### Installation - -1. Open Github [releases page]({{nym_vpn_releases}}) and download the binary for your version of MacOS - -2. Recommended (skip this point if you don't want to verify): Verify sha hash of your downloaded binary with the one listed on the [releases page]({{nym_vpn_releases}}). You can use a simple `shasum` command and compare strings (ie with Python) or run in the same directory the following command, exchanging `` with the one of your binary, like in the example: -```sh -echo "" | shasum -a 256 -c - -# choose a correct one according to your binary, this is just an example -# echo "da4c0bf8e8b52658312d341fa3581954cfcb6efd516d9a448c76d042a454b5df nym-vpn-desktop__macos_x86_64.zip" | shasum -a 256 -c -``` - -3. Extract the downloaded file manually or by a command: -```sh -tar -xvf .tar.gz -# for example -# tar -xvf nym-vpn-desktop__macos_aarch64.tar.gz -``` -4. Mount the `.dmg` image you extracted by double clicking on it and move it (drag it) to your `/Application` folder - - - -## Run NymVPN - -**For NymVPN to work, all other VPNs must be switched off!** At this alpha stage of NymVPN, the network connection (wifi) must be reconnected after or in between the testing rounds. - -Run: -```sh -sudo /Applications/nym-vpn.app/Contents/MacOS/nym-vpn - -# If it didn't start try to run with -E flag -sudo -E /Applications/nym-vpn.app/Contents/MacOS/nym-vpn -``` - -In case of errors check out the [troubleshooting](troubleshooting.md#running-gui-failed-due-to-toml-parse-error) section. diff --git a/documentation/old_docs/dev-portal/src/nymvpn/gui.md b/documentation/old_docs/dev-portal/src/nymvpn/gui.md deleted file mode 100644 index 6eda800aad..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/gui.md +++ /dev/null @@ -1,50 +0,0 @@ -# NymVPN - Desktop (GUI) - -```admonish info -Our alpha testing round is done with participants at live workshop events and the application in this stage may not work for everyone. - -**If you commit to test NymVPN alpha, please start with the [user research form]({{nym_vpn_form_url}}) where all the steps will be provided**. If you disagree with any of the conditions listed, please leave this page. -``` - -This is a desktop (GUI) version of NymVPN client. A demo of how the application will look like for majority of day-to-day users. - -Follow the simple [automated script](#automated-script-for-gui-installation) below to install and run NymVPN GUI. If the script didn't work for your distribution or you prefer to do a manual setup follow the steps in the guide for [Linux](gui-linux.md) or [MacOS](gui-mac.md) . - -Visit NymVPN alpha latest [release page]({{nym_vpn_releases}}) to check sha sums or download the binaries directly. - -## Linux AppImage Automated Installation Method - -The latest releases contain `appimage.sh` script. This method makes the installation simple for Linux users who want to run NymVPN from AppImmage. Executing the command below will download the binary to `~/.local/bin` and verify the checksum: -```sh -curl -fsSL https://github.com/nymtech/nym-vpn-client/releases/download/nym-vpn-desktop-v/appimage.sh | bash -``` - -Run with the command: -```sh -sudo -E ~/.local/bin/nym-vpn.appimage -``` - -## Automated Script for GUI Installation (Linux and Mac) - -We wrote a [script](https://gist.github.com/tommyv1987/7d210d4daa8f7abc61f9a696d0321f19) which does download of dependencies and the application, sha256 verification, extraction, installation and configuration for Linux and MacOS users automatically. Turn off all VPNs and follow the steps below. - -1. Open a terminal window in a directory where you want the script to be downloaded and run -```sh -curl -o nym-vpn-desktop-install-run.sh -L https://gist.githubusercontent.com/tommyv1987/7d210d4daa8f7abc61f9a696d0321f19/raw/939ac8d0afed69f43739b9cf2e5728454ea2c437/nym-vpn-client-install-run.sh && chmod u+x nym-vpn-desktop-install-run.sh && sudo -E ./nym-vpn-desktop-install-run.sh -``` - -2. Follow the prompts in the program - -To start the application again, reconnect your wifi and run -```sh -# Linux .AppImage -sudo -E ~/nym-vpn-latest/nym-vpn-desktop__ubuntu-22.04_x86_64/nym-vpn__amd64.AppImage - -# Linux .deb -sudo -E nym-vpn - -# MacOS -sudo -E $HOME/nym-vpn-latest/nym-vpn -``` - -In case of errors check out the [troubleshooting](troubleshooting.md#running-gui-failed-due-to-toml-parse-error) section. diff --git a/documentation/old_docs/dev-portal/src/nymvpn/images/image1.png b/documentation/old_docs/dev-portal/src/nymvpn/images/image1.png deleted file mode 100644 index d5f9bcb2f5..0000000000 Binary files a/documentation/old_docs/dev-portal/src/nymvpn/images/image1.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/nymvpn/images/image2.png b/documentation/old_docs/dev-portal/src/nymvpn/images/image2.png deleted file mode 100644 index 14b501383c..0000000000 Binary files a/documentation/old_docs/dev-portal/src/nymvpn/images/image2.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/nymvpn/images/image3.png b/documentation/old_docs/dev-portal/src/nymvpn/images/image3.png deleted file mode 100644 index 51d79d42d7..0000000000 Binary files a/documentation/old_docs/dev-portal/src/nymvpn/images/image3.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/nymvpn/images/image4.png b/documentation/old_docs/dev-portal/src/nymvpn/images/image4.png deleted file mode 100644 index 52f4d7dd20..0000000000 Binary files a/documentation/old_docs/dev-portal/src/nymvpn/images/image4.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/nymvpn/images/image5.png b/documentation/old_docs/dev-portal/src/nymvpn/images/image5.png deleted file mode 100644 index 40b9c3aab8..0000000000 Binary files a/documentation/old_docs/dev-portal/src/nymvpn/images/image5.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/nymvpn/images/json.png b/documentation/old_docs/dev-portal/src/nymvpn/images/json.png deleted file mode 100644 index a64c288169..0000000000 Binary files a/documentation/old_docs/dev-portal/src/nymvpn/images/json.png and /dev/null differ diff --git a/documentation/old_docs/dev-portal/src/nymvpn/testing.md b/documentation/old_docs/dev-portal/src/nymvpn/testing.md deleted file mode 100644 index 849b670d8f..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/testing.md +++ /dev/null @@ -1,209 +0,0 @@ -# Testing NymVPN alpha - -
- -```admonish info -NymVPN is an experimental software and it's for [testing](./testing.md) purposes only. All users testing the client are expected to sign GDPR Information Sheet and Consent Form (shared at the workshop) so we use their results to improve the client, and submit the form [*NymVPN User research*]({{nym_vpn_form_url}}) with the testing results. -``` - -> Before you get into testing NymVPN, make sure to go through the preparation steps for NymVPN [CLI](cli.md). - -One of the main aims of NymVPN alpha release is testing; your results will help us to make NymVPN robust and stabilise both the client and the network through provided measurements. - -## Steps to test NymVPN - -> Any syntax in `<>` brackets is a user's/version unique variable. Exchange with a corresponding name without the `<>` brackets. - -1. Create a directory called `nym-vpn-tests` and copy your `nym-vpn-cli` binary ([download here]({{nym_vpn_releases}})) -2. Copy or download [`sandbox.env`](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) testnet config file to the same directory -```sh -curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env -``` -3. Copy the [block below](#testssh) and save it as `tests.sh` to the same folder -4. Open terminal in the same directory and make the script executable -```sh -chmod u+x ./tests.sh -``` -5. Turn off any existing VPN's (including NymVPN instances), reconnect your wifi and run the `tests.sh` script -```sh -sudo ./tests.sh -```` -6. In case of errors, see the [troubleshooting section](troubleshooting.md#missing-jq-error) -7. The script will print a JSON view of existing Gateways and prompt you to: - - *Make sure to use two different Gateways for entry and exit!* - - `enter a gateway ID:` paste one of the values labeled with a key `"identityKey"` printed above (without `" "`) - - `enter an exit address:` paste one of the values labeled with a key `"address"` printed above (without `" "`) - - `enable WireGuard? (yes/no):` if you chose yes, find your private key and wireguard IP [here](https://nymvpn.com/en/alpha) -8. Note that the testing script doesn't print many logs, in case of doubts you can check logs in the log file `temp_log.txt` located in the same directory. -9. The script shall run the tests and generate a folder called `tests_` and files `perf_test_results.log` or `two_hop_perf_test_results.log` as well as some temp files. This is how the directory structure will look like: -```sh -nym-vpn-tests -├── tests.sh -├── nym-vpn-cli -├── sandbox.env -├── perf_test_results.log -├── tests_ -│   ├── api_response_times.txt -│   ├── download_time.txt -│   └── ping_results.txt -├── timeout -└── two_hop_perf_test_results.log -``` -10. When the tests are finished, remove the `nym-vpn-cli` binary from the folder and compress the entire folder as `nym-vpn-tests.zip` (both of these can be done in your graphical environment) -11. Upload this compressed file to the [form]({{nym_vpn_form_url}}) drop field when prompted - -#### tests.sh - -This is the testing script which needs to be copied and saved as `tests.sh` to your `nym-vpn-tests` folder and then run from there as described [above](#steps-to-test-nymvpn). - -```sh -#!/bin/bash - -ENDPOINT="https://sandbox-nym-api1.nymtech.net/api/v1/gateways/described" -json_array=() -echo "🚀 🏎 - please be patient, i'm fetching you your entry points - 🚀 🏎 " - -data=$(curl -s "$ENDPOINT" | jq -c '.[] | {host: .bond.gateway.host, hostname: .self_described.host_information.hostname, identity_key: .bond.gateway.identity_key, exitGateway: .self_described.ip_packet_router.address}') - -while IFS= read -r entry; do - host=$(echo "$entry" | jq -r '.host') - hostname=$(echo "$entry" | jq -r '.hostname') - identity_key=$(echo "$entry" | jq -r '.identity_key') - exit_gateway_address=$(echo "$entry" | jq -r '.exitGateway // empty') - valid_ip=$(echo "$host") - - if [ -n "$exit_gateway_address" ]; then - exit_gateway="{\"address\": \"${exit_gateway_address}\"}" - else - exit_gateway="{}" - fi - if [[ $valid_ip =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then - country_info=$(curl -s "http://ipinfo.io/${valid_ip}/country" | tr -d '\n') - country_info_escaped=$(echo "$country_info" | tr -d '\n' | jq -aRs . | tr -d '"') - else - country_info_escaped="" - fi - json_object="{\"hostname\": \"${hostname}\", \"identityKey\": \"${identity_key}\", \"exitGateway\": ${exit_gateway}, \"location\": \"${country_info_escaped}\"}" - json_array+=("$json_object") -done < <(echo "$data") - -if [ $? -ne 0 ]; then - echo "error fetching data from endpoint" - exit 1 -fi - -download_file() { - local file_url=$1 - local output_file=$2 - local time_file=$3 - - echo "starting download speed test..." - local start_time=$(date +%s) - if [[ "$OSTYPE" == "linux-gnu"* ]]; then - wget -O $output_file $file_url - elif [[ "$OSTYPE" == "darwin"* ]]; then - curl -o $output_file $file_url - fi - local end_time=$(date +%s) - local elapsed_time=$((end_time - start_time)) - echo "download speed test completed in $elapsed_time seconds." >"$time_file" -} - -if ! command -v jq &>/dev/null; then - echo "jq is not installed. Please install jq to proceed." - exit 1 -fi - -temp_log_file="temp_log.txt" - -perform_tests() { - local gateway_id=$1 - local exit_address=$2 - local test_directory="tests_${gateway_id}_${exit_address}" - local file_url="http://ipv4.download.thinkbroadband.com/2MB.zip" - - mkdir -p "$test_directory" - local ping_results_file="${test_directory}/ping_results.txt" - local download_time_file="${test_directory}/download_time.txt" - local api_response_file="${test_directory}/api_response_times.txt" - - # ping test - echo "starting ping test..." - for site in google.com youtube.com facebook.com baidu.com wikipedia.org amazon.com twitter.com instagram.com yahoo.com ebay.com netflix.com; do - ping -c 4 $site >>"$ping_results_file" - done - echo "ping test completed. Results saved in $ping_results_file" - - # download speed test - download_file $file_url /dev/null "$download_time_file" - - # api test - local api_endpoint="https://validator.nymtech.net/api/v1/mixnodes" - local iterations=10 - >"$api_response_file" - for i in $(seq 1 $iterations); do - local start_time=$(date +%s) - local response=$(curl -s -o /dev/null -w '%{http_code}' $api_endpoint) - local end_time=$(date +%s) - - local elapsed_seconds=$((end_time - start_time)) - local hours=$((elapsed_seconds / 3600)) - local minutes=$(((elapsed_seconds % 3600) / 60)) - local seconds=$((elapsed_seconds % 60)) - - local human_readable_time=$(printf "%02dh:%02dm:%02ds" $hours $minutes $seconds) - echo "iteration $i: response Time = ${human_readable_time}, status code = $response" >>"$api_response_file" - done - echo "api response test completed. Results saved in $api_response_file." -} - -printf "%s\n" "${json_array[@]}" | jq -s . - -read -p "enter a gateway ID: " identity_key -read -p "enter an exit address: " exit_address - -while true; do - read -p "enable WireGuard? (yes/no): " enable_wireguard - enable_wireguard=$(echo "$enable_wireguard" | tr '[:upper:]' '[:lower:]') - - case "$enable_wireguard" in - "yes") - read -p "enter your WireGuard private key: " priv_key - read -p "enter your WireGuard IP: " wg_ip - wireguard_options="--enable-wireguard --private-key $priv_key --wg-ip $wg_ip" - break - ;; - "no") - wireguard_options="" - break - ;; - *) - echo "invalid response. please enter 'yes' or 'no'." - ;; - esac -done - -sudo ./nym-vpn-cli -c sandbox.env --entry-gateway-id ${identity_key} --exit-router-address ${exit_address} --enable-two-hop $wireguard_options >"$temp_log_file" 2>&1 & - -timeout=15 -start_time=$(date +%s) -while true; do - current_time=$(date +%s) - if grep -q "received plain" "$temp_log_file"; then - echo "successful configuration with identity_key: $identity_key and exit address: $exit_address" >>perf_test_results.log - perform_tests "$identity_key" "$exit_address" - break - fi - if ((current_time - start_time > timeout)); then - echo "failed to connect with identity_key: $identity_key using the exit address: $exit_address" >>perf_test_results.log - break - fi - sleep 1 -done - -echo "terminating nym-vpn-cli..." -pkill -f './nym-vpn-cli' -sleep 5 -rm -f "$temp_log_file" - -``` diff --git a/documentation/old_docs/dev-portal/src/nymvpn/troubleshooting.md b/documentation/old_docs/dev-portal/src/nymvpn/troubleshooting.md deleted file mode 100644 index 1ae4046cdb..0000000000 --- a/documentation/old_docs/dev-portal/src/nymvpn/troubleshooting.md +++ /dev/null @@ -1,97 +0,0 @@ -# Troubleshooting - -Below are listed some points which may need to be addressed when testing NymVPN alpha. If you crashed into any errors which are not listed, please contact us at the testing workshop or in the NymVPN [Matrix channel](https://matrix.to/#/#NymVPN:nymtech.chat). - -#### NymVPN attempts to connect to sandbox testnet - -If you testing the latest versions and you correctly expect the client to run over the mainnet, but it listens to `https://sandbox-nym-api1.nymtech.net`, it's probably because of your previous configuration. - -Check your `config.toml` either in the directory from which you run your client or in `~/.config/nym-vpn/` and remove `sandbox.env` from the config file and folder. - -If the problem persists (probably due to some locally cache) download [`mainnet.env`](https://github.com/nymtech/nym/blob/master/envs/mainnet.env) and save it to the same directory. - -#### Running GUI failed due to `TOML parse error` - -If you see this error when running NymVPN alpha desktop, it's because the older versions needed entry location in `config.toml` configuration file. From `v0.0.3` the entry location is selected directly by the user in the application. This error is due to an old `app-data.toml` config in your computer. - -```sh -2024-02-15T14:25:02.745331Z ERROR read: nym_vpn_desktop::fs::storage: TOML parse error at line 5, column 1 - | -5 | [entry_node_location] - | ^^^^^^^^^^^^^^^^^^^^^ -wanted exactly 1 element, more than 1 element - self=AppStorage { data: AppData { monitoring: None, autoconnect: None, killswitch: None, entry_location_selector: None, ui_theme: None, ui_root_font_size: None, vpn_mode: None, entry_node_location: None, exit_node_location: None }, dir_path: "/home/companero/.local/share/nym-vpn", filename: "app-data.toml", full_path: "/home/companero/.local/share/nym-vpn/app-data.toml" } -Error: TOML parse error at line 5, column 1 - | -5 | [entry_node_location] - | ^^^^^^^^^^^^^^^^^^^^^ -wanted exactly 1 element, more than 1 element -``` - -Simply delete this file `app-data.toml` from the path listed in the error message. In the example above it would be `/home/companero/.local/share/nym-vpn/app-data.toml`. - -The application will create a new one on startup. - -#### Thread `main` panicked - -If you see a message like: -```sh -thread 'main' panicked at /Users/runner/.cargo/git/checkouts/mullvadvpn-app-a575cf705b5dfd76/ccfbaa2/talpid-routing/src/unix.rs:301:30: -``` -Restart your wifi connection and start again. - -#### MacOS alert on NymVPN UI startup - -If you are running NymVPN on mac OS for the first time, you may see this alert message: - -![](images/image3.png) - -1. Head to System Settings -> Privacy & Security and click `Allow anyway` - -![](images/image5.png) - -2. Confirm with your password or TouchID - -3. Possibly you may have to confirm again upon running the application - - diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples.md deleted file mode 100644 index 648c32fa0d..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples.md +++ /dev/null @@ -1,12 +0,0 @@ -# Examples - -All the following examples can be found in the `nym-sdk` [examples directory](https://github.com/nymtech/nym/tree/master/sdk/rust/nym-sdk/examples) in the monorepo. Just navigate to `nym/sdk/rust/nym-sdk/examples/` and run the files from there with: - -```sh -cargo run --example -``` - -If you wish to run these outside of the workspace - such as if you want to use one as the basis for your own project - then make sure to import the `sdk`, `tokio`, and `nym_bin_common` crates. - -An example `Cargo.toml` file can be found [here](examples/cargo.md). - diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/cargo.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/cargo.md deleted file mode 100644 index e425e124ed..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/cargo.md +++ /dev/null @@ -1,35 +0,0 @@ -# Example Cargo File -This file imports the basic requirements for running these pieces of example code, and can be used as the basis for your own cargo project. - -```toml -[package] -name = "your_app" -version = "x.y.z" -edition = "2021" - -# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html - -[dependencies] -# Async runtime -tokio = { version = "1.24.1", features = ["rt-multi-thread", "macros"] } -# Used for (de)serialising incoming and outgoing messages -serde = "1.0.152" -serde_json = "1.0.91" -# Nym clients, addressing, etc -nym-sdk = { git = "https://github.com/nymtech/nym", branch = "master" } -nym-sphinx-addressing = { git = "https://github.com/nymtech/nym", branch = "master" } -nym-bin-common = { git = "https://github.com/nymtech/nym", branch = "master" } -nym-sphinx-anonymous-replies = { git = "https://github.com/nymtech/nym", branch = "master" } -# Additional dependencies if you're interacting with Nyx or another Cosmos SDK blockchain -cosmrs = "=0.14.0" -nym-validator-client = { git = "https://github.com/nymtech/nym", branch = "master" } - -# If you're building an app with a client and server / serivce this might be a useful structure for your repo -[[bin]] -name = "client" -path = "bin/client.rs" - -[[bin]] -name = "service" -path = "bin/service.rs" -``` \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/credential.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/credential.md deleted file mode 100644 index f29d6748ba..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/credential.md +++ /dev/null @@ -1,8 +0,0 @@ -# Coconut credential generation -The following code shows how you can use the SDK to create and use a credential 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](https://nymtech.net/docs/coconut.html). diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/custom-network.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/custom-network.md deleted file mode 100644 index ae0f145a3b..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/custom-network.md +++ /dev/null @@ -1,18 +0,0 @@ -# Importing and using a custom network topology -If you want to send traffic through a sub-set of nodes (for instance, ones you control, or a small test setup) when developing, debugging, or performing research, you will need to import these nodes as a custom network topology, instead of grabbing it from the [`Mainnet Nym-API`](https://validator.nymtech.net/api/swagger/index.html) (`examples/custom_topology_provider.rs`). - -There are two ways to do this: - -## Import a custom Nym API endpoint -If you are also running a Validator and Nym API for your network, you can specify that endpoint as such and interact with it as clients usually do (under the hood): - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/custom_topology_provider.rs}} -``` - -## Import a specific topology manually -If you aren't running a Validator and Nym API, and just want to import a specific sub-set of mix nodes, you can simply overwrite the grabbed topology manually: - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/manually_overwrite_topology.rs}} -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/keys.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/keys.md deleted file mode 100644 index 84746dcfd6..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/keys.md +++ /dev/null @@ -1,28 +0,0 @@ -# Key Creation and Use -The previous example involves ephemeral keys - if we want to create and then maintain a client identity over time, our code becomes a little more complex as we need to create, store, and conditionally load these keys (`examples/builder_with_storage`): - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/builder_with_storage.rs}} -``` - -As seen in the example above, the `mixnet::MixnetClientBuilder::new()` function handles checking for keys in a storage location, loading them if present, or creating them and storing them if not, making client key management very simple. - -Assuming our client config is stored in `/tmp/mixnet-client`, the following files are generated: -``` -$ tree /tmp/mixnet-client - -mixnet-client -├── ack_key.pem -├── db.sqlite -├── db.sqlite-shm -├── db.sqlite-wal -├── gateway_details.json -├── gateway_shared.pem -├── persistent_reply_store.sqlite -├── private_encryption.pem -├── private_identity.pem -├── public_encryption.pem -└── public_identity.pem - -1 directory, 11 files -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/simple.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/simple.md deleted file mode 100644 index 20872ce96b..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/simple.md +++ /dev/null @@ -1,8 +0,0 @@ -# Simple Send -Lets look at a very simple example of how you can import and use the websocket client in a piece of Rust code (`examples/simple.rs`). - -Simply importing the `nym_sdk` crate into your project allows you to create a client and send traffic through the mixnet. - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/simple.rs}} -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/socks.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/socks.md deleted file mode 100644 index de027e9011..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/socks.md +++ /dev/null @@ -1,10 +0,0 @@ -# Socks Proxy -There is also the option to embed the [`socks5-client`](../../../clients/socks5-client.md) into your app code (`examples/socks5.rs`): - -```admonish info -If you are looking at implementing Nym as a transport layer for a crypto wallet or desktop app, this is probably the best place to start if they can speak SOCKS5, 4a, or 4. -``` - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/socks5.rs}} -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/split-send.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/split-send.md deleted file mode 100644 index 6b7cf69789..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/split-send.md +++ /dev/null @@ -1,6 +0,0 @@ -# Send and Receive in Different Tasks -If you need to split the different actions of your client across different tasks, you can do so like this: - -```rust, noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/parallel_sending_and_receiving.rs}} -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/storage.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/storage.md deleted file mode 100644 index bc68bca9ff..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/storage.md +++ /dev/null @@ -1,6 +0,0 @@ -# Manually Handled Storage -If you're integrating mixnet functionality into an existing app and want to integrate saving client configs and keys into your existing storage logic, you can manually perform the actions taken automatically above (`examples/manually_handle_keys_and_config.rs`) - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/manually_handle_storage.rs}} -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/examples/surbs.md b/documentation/old_docs/dev-portal/src/sdk/rust/examples/surbs.md deleted file mode 100644 index d3b6b2da1b..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/examples/surbs.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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.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: - -```rust,noplayground -{{#include ../../../../../../sdk/rust/nym-sdk/examples/surb_reply.rs}} -``` diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/message-helpers.md b/documentation/old_docs/dev-portal/src/sdk/rust/message-helpers.md deleted file mode 100644 index e7ce201fa7..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/message-helpers.md +++ /dev/null @@ -1,70 +0,0 @@ -# Message Helpers - -## Handling incoming messages -As seen in the [Chain querier tutorial](https://github.com/nymtech/developer-tutorials/blob/0130ee5a61cd6801bdcfc84608b2a520b5392714/rust/chain-query-service/) when listening out for a response to a sent message (e.g. if you have sent a request to a service, and are awaiting the response) you will want to await [non-empty messages (if you don't know why, read the info on this here)](troubleshooting.md#client-receives-empty-messages-when-listening-for-response). This can be done with something like the helper functions [here](https://github.com/nymtech/developer-tutorials/blob/0130ee5a61cd6801bdcfc84608b2a520b5392714/rust/chain-query-service/src/lib.rs#L71): - -```rust -use nym_sdk::mixnet::ReconstructedMessage; - -pub async fn wait_for_non_empty_message( - client: &mut MixnetClient, -) -> anyhow::Result { - while let Some(mut new_message) = client.wait_for_messages().await { - if !new_message.is_empty() { - return Ok(new_message.pop().unwrap()); - } - } - - bail!("did not receive any non-empty message") -} - -pub fn handle_response(message: ReconstructedMessage) -> anyhow::Result { - ResponseTypes::try_deserialize(message.message) -} - -// Note here that the only difference between handling a request and a response -// is that a request will have a sender_tag to parse. -// -// This is used for anonymous replies with SURBs. -pub fn handle_request( - message: ReconstructedMessage, -) -> anyhow::Result<(RequestTypes, Option)> { - let request = RequestTypes::try_deserialize(message.message)?; - Ok((request, message.sender_tag)) -} -``` - -The above helper functions are used as such by the client in tutorial example: it sends a message to the service (what the message is isn't important - just that your client has sent a message _somewhere_ and you are awaiting a response), waits for a _non_empty_ message, then handles it (then logs it - but you can do whatever you want, parse it, etc): - -```rust -// [snip] - -// Send serialised request to service via mixnet what is await-ed here is -// placing the message in the client's message queue, NOT the sending itself. -let _ = client - .send_message(sp_address, message.serialize(), Default::default()) - .await; - -// Await a non-empty message -let received = wait_for_non_empty_message(client).await?; - -// Handle the response received (the non-empty message awaited above) -let sp_response = handle_response(received)?; - -// Match JSON -> ResponseType -let res = match sp_response { - crate::ResponseTypes::Balance(response) => { - println!("{:#?}", response); - response.balance - } -}; - -// [snip] -``` -([repo code on Github here](https://github.com/nymtech/developer-tutorials/blob/0130ee5a61cd6801bdcfc84608b2a520b5392714/rust/chain-query-service/src/client.rs#L19)) - -## Iterating over incoming messages -It is recommended to use `nym_client.next().await` over `nym_client.wait_for_messages().await` as the latter will return one message at a time which will probably be easier to deal with. See the [parallel send and receive example](https://github.com/nymtech/nym/blob/2993e85c7a17bd5b68171751a48b731b2394ee03/sdk/rust/nym-sdk/examples/parallel_sending_and_receiving.rs#L23-L25) for an example. - -## Remember to disconnect your client -You should always **manually disconnect your client** with `client.disconnect().await` as seen in the code examples. This is important as your client is writing to a local DB and dealing with SURB storage. diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/message-types.md b/documentation/old_docs/dev-portal/src/sdk/rust/message-types.md deleted file mode 100644 index c5adf83377..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/message-types.md +++ /dev/null @@ -1,5 +0,0 @@ -# Message Types -[//]: # (TODO expand! ) -There are two methods for sending messages through the mixnet using your client: -* `send_plain_message()` is the most simple: pass the recipient address and the message you wish to send as a string (this was previously `send_str()`). This is a nicer-to-use wrapper around `send_message()`. -* `send_message()` allows you to also define the amount of SURBs to send along with your message (which is sent as bytes). diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/rust.md b/documentation/old_docs/dev-portal/src/sdk/rust/rust.md deleted file mode 100644 index 3062e1ff32..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/rust.md +++ /dev/null @@ -1,48 +0,0 @@ -# Rust SDK -The Rust SDK allows developers building applications in Rust to import and interact with Nym clients as they would any other dependency, instead of running the client as a separate process on their machine. This makes both developing and running applications much easier, reducing complexity in the development process (not having to restart another client in a separate console window/tab) and being able to have a single binary for other people to use. - -Currently developers can use the Rust SDK to import either websocket client ([`nym-client`](../../clients/websocket-client.md)) or [`socks-client`](../../clients/socks5-client.md) functionality into their Rust code. - -In the future the SDK will be made up of several components, each of which will allow developers to interact with different parts of Nym infrastructure. - -| Component | Functionality | Released | -|-----------|---------------------------------------------------------------------------------------|----------| -| Mixnet | Create / load clients & keypairs, subscribe to Mixnet events, send & receive messages | ✔️ | -| Coconut | Create & verify Coconut credentials | 🛠️ | -| Validator | Sign & broadcast Nyx blockchain transactions, query the blockchain | ❌ | - -The `mixnet` component currently exposes the logic of two clients: the [websocket client](../../clients/websocket-client.md), and the [socks](../../clients/socks5-client.md) client. - -The `coconut` component is currently being worked on. Right now it exposes logic allowing for the creation of coconut credentials on the Sandbox testnet. - -### Development status -The SDK is still somewhat a work in progress: interfaces are fairly stable but still may change in subsequent releases. - -### Installation -The `nym-sdk` crate is **not yet available via [crates.io](https://crates.io)**. As such, in order to import the crate you must specify the Nym monorepo in your `Cargo.toml` file: - -```toml -nym-sdk = { git = "https://github.com/nymtech/nym" } -``` - -By default the above command will import the current `HEAD` of the default branch, which in our case is `develop`. Assuming instead you wish to pull in another branch (e.g. `master` or a particular release) you can specify this like so: - -```toml -# importing HEAD of master branch -nym-sdk = { git = "https://github.com/nymtech/nym", branch = "master" } -# importing HEAD of the third release of 2023, codename 'kinder' -nym-sdk = { git = "https://github.com/nymtech/nym", branch = "release/2023.3-kinder" } -``` - -You can also define a particular git commit to use as your import like so: - -```toml -nym-sdk = { git = "https://github.com/nymtech/nym", rev = "85a7ec9f02ca8262d47eebb6c3b19d832341b55d" } -``` - -Since the `HEAD` of `master` is always the most recent release, we recommend developers use that for their imports, unless they have a reason to pull in a specific historic version of the code. - -### Generate Crate Docs -In order to generate the crate docs run `cargo doc --open` from `nym/sdk/rust/nym-sdk/` - - diff --git a/documentation/old_docs/dev-portal/src/sdk/rust/troubleshooting.md b/documentation/old_docs/dev-portal/src/sdk/rust/troubleshooting.md deleted file mode 100644 index 458a4eaab4..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/rust/troubleshooting.md +++ /dev/null @@ -1,115 +0,0 @@ -# Troubleshooting -Below are several common issues or questions you may have. - -If you come across something that isn't explained here, [PRs are welcome](https://github.com/nymtech/nym/issues/new/choose). - -## Verbose `task client is being dropped` logging -### On client shutdown (expected) -If this is happening at the end of your code when disconnecting your client, this is fine; we just have a verbose client! When calling `client.disconnect().await` this is simply informing you that the client is shutting down. - -On client shutdown / disconnect this is to be expected - this can be seen in many of the code examples as well. We use the [`nym_bin_common::logging`](https://github.com/nymtech/nym/blob/develop/common/bin-common/src/logging/mod.rs) import to set logging in our example code. This defaults to `INFO` level. - -If you wish to quickly lower the verbosity of your client process logs when developing you can prepend your command with `RUST_LOG=`. - -If you want to run the `builder.rs` example with only `WARN` level logging and below: - -```sh -cargo run --example builder -``` - -Becomes: - -```sh -RUST_LOG=warn cargo run --example builder -``` - -You can also make the logging _more_ verbose with: - -```sh -RUST_LOG=debug cargo run --example builder -``` - -### Not on client shutdown (unexpected) -If this is happening unexpectedly then you might be shutting your client process down too early. See the [accidentally killing your client process](#accidentally-killing-your-client-process-too-early) below for possible explanations and how to fix this issue. - -[//]: # (TODO note on poisson dance and not immediately killing client process) -## Accidentally killing your client process too early -If you are seeing either of the following errors when trying to run a client, specifically sending a message, then you may be accidentally killing your client process. - -```sh - 2023-11-02T10:31:03.930Z INFO TaskClient-BaseNymClient-real_traffic_controller-ack_control-action_controller > the task client is getting dropped - 2023-11-02T10:31:04.625Z INFO TaskClient-BaseNymClient-received_messages_buffer-request_receiver > the task client is getting dropped - 2023-11-02T10:31:04.626Z DEBUG nym_client_core::client::real_messages_control::acknowledgement_control::input_message_listener > InputMessageListener: Exiting - 2023-11-02T10:31:04.626Z INFO TaskClient-BaseNymClient-real_traffic_controller-ack_control-input_message_listener > the task client is getting dropped - 2023-11-02T10:31:04.626Z INFO TaskClient-BaseNymClient-real_traffic_controller-reply_control > the task client is getting dropped - 2023-11-02T10:31:04.626Z DEBUG nym_client_core::client::real_messages_control > The reply controller has finished execution! - 2023-11-02T10:31:04.626Z DEBUG nym_client_core::client::real_messages_control::acknowledgement_control > The input listener has finished execution! - 2023-11-02T10:31:04.626Z INFO nym_task::manager > All registered tasks succesfully shutdown -``` - -```sh - 2023-11-02T11:22:08.408Z ERROR TaskClient-BaseNymClient-topology_refresher > Assuming this means we should shutdown... - 2023-11-02T11:22:08.408Z ERROR TaskClient-BaseNymClient-mix_traffic_controller > Polling shutdown failed: channel closed - 2023-11-02T11:22:08.408Z INFO TaskClient-BaseNymClient-gateway_transceiver-child > the task client is getting dropped - 2023-11-02T11:22:08.408Z ERROR TaskClient-BaseNymClient-mix_traffic_controller > Assuming this means we should shutdown... -thread 'tokio-runtime-worker' panicked at 'action control task has died: TrySendError { kind: Disconnected }', /home/.local/share/cargo/git/checkouts/nym-fbd2f6ea2e760da9/a800cba/common/client-core/src/client/real_messages_control/message_handler.rs:634:14 -note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace - 2023-11-02T11:22:08.477Z INFO TaskClient-BaseNymClient-real_traffic_controller-ack_control-input_message_listener > the task client is getting dropped - 2023-11-02T11:22:08.477Z ERROR TaskClient-BaseNymClient-real_traffic_controller-ack_control-input_message_listener > Polling shutdown failed: channel closed - 2023-11-02T11:22:08.477Z ERROR TaskClient-BaseNymClient-real_traffic_controller-ack_control-input_message_listener > Assuming this means we should shutdown... -``` - -Using the following piece of code as an example: - -```rust -use nym_sdk::mixnet::{MixnetClient, MixnetMessageSender, Recipient}; -use clap::Parser; - -#[derive(Debug, Clone, Parser)] -enum Opts { - Client { - recipient: Recipient - } -} - -#[tokio::main] -async fn main() { - let opts: Opts = Parser::parse(); - nym_bin_common::logging::setup_logging(); - - let mut nym_client = MixnetClient::connect_new().await.expect("Could not build Nym client"); - - match opts { - Opts::Client { recipient } => { - nym_client.send_plain_message(recipient, "some message string").await.expect("send failed"); - } - } -} -``` - -This is a simplified snippet of code for sending a simple hardcoded message with the following command: - -```sh -cargo run client -``` - -You might assume that `send`-ing your message would _just work_ as `nym_client.send_plain_message()` is an async function; you might expect that the client will block until the message is actually sent into the mixnet, then shutdown. - -However, this is not true. - -**This will only block until the message is put into client's internal queue**. Therefore in the above example, the client is being shut down before the message is _actually sent to the mixnet_; after being placed in the client's internal queue, there is still work to be done under the hood, such as route encrypting the message and placing it amongst the stream of cover traffic. - -The simple solution? Make sure the program/client stays active, either by calling `sleep`, or listening out for new messages. As sending a one-shot message without listening out for a response is likely not what you'll be doing, then you will be then awaiting a response (see the [message helpers page](message-helpers.md) for an example of this). - -Furthermore, you should always **manually disconnect your client** with `client.disconnect().await` as seen in the code examples. This is important as your client is writing to a local DB and dealing with SURB storage. - -## Client receives empty messages when listening for response -If you are sending out a message, it makes sense for your client to then listen out for incoming messages; this would probably be the reply you get from the service you've sent a message to. - -You might however be receiving messages without data attached to them / empty payloads. This is most likely because your client is receiving a message containing a [SURB request](https://nymtech.net/docs/architecture/traffic-flow.html#private-replies-using-surbs) - a SURB requesting more SURB packets to be sent to the service, in order for them to have enough packets (with a big enough overall payload) to split the entire response to your initial request across. - -Whether the `data` of a SURB request being empty is a feature or a bug is to be decided - there is some discussion surrounding whether we can use SURB requests to send additional data to streamline the process of sending large replies across the mixnet. - -You can find a few helper functions [here](message-helpers.md) to help deal with this issue in the meantime. - -> If you can think of a more succinct or different way of handling this do reach out - we're happy to hear other opinions \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/sdk/typescript.md b/documentation/old_docs/dev-portal/src/sdk/typescript.md deleted file mode 100644 index ee67c3939a..0000000000 --- a/documentation/old_docs/dev-portal/src/sdk/typescript.md +++ /dev/null @@ -1,4 +0,0 @@ -# Typescript SDK -The Typescript SDK allows developers to start building browser-based mixnet applications quickly, by simply importing the SDK into their code via NPM as they would any other Typescript library. - -If you'd like to learn more, build apps or integrate Nym components using the TS SDK, visit the dedicated [TS SDK Handbook](https://sdk.nymtech.net/). diff --git a/documentation/old_docs/dev-portal/src/shipyard/challenges-overview.md b/documentation/old_docs/dev-portal/src/shipyard/challenges-overview.md deleted file mode 100644 index 4e02f5a797..0000000000 --- a/documentation/old_docs/dev-portal/src/shipyard/challenges-overview.md +++ /dev/null @@ -1,53 +0,0 @@ -# Hackathon Challenges -There are a few different challenges to choose from, each with different approaches. It is also recommended to check out the _**Examples**_ directory above for inspiration. - -## Tooling challenge -The tooling challenge involves creating tooling for users, operators, or developers of Nym. - -### Examples of user-centric tools: -- Facilitate onboarding new users more easily to staking their Nym, and understanding the pros and cons, as well as finding a good node to stake on. Examples of tools like this: - - [ExploreNym dashboard](https://explorenym.net/) - -- Show information on a dashboard about the network. NOTE due to the amount of dashboards currently available, we expect a good justification for why / something to set this apart from existing ones e.g. it is presenting information that is not already presented, or it is presented in a different manner, such as a TUI or CLI app instead of a web dashboard - maybe an onion service, or no-JS site for those who do not wish to enable Javascript in their day-to-day browsing. Examples of tools like this: - - [NTV's node dashboard](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1) - - [IsNymUp dashboard](https://isnymup.com/) - -### Examples of operator-centric tooling: -- An APY calculator for determining different financial outcomes of running a node in different situations. - -- Scripting for updating and maintaining nodes. Examples of tools like this: - - [ExploreNym's bash scripts](https://github.com/ExploreNYM/bash-tool) - -- Scripting for packaging node binaries for different OSes. - -### Examples of developer-centric tooling: -- Tooling for use in development: are there pain points you’ve found when developing apps with Nym that you have created scripts/hacks/workarounds for? Is there a pain point that you’ve thought ‘oh it would be great if I could just do X’? These are often the best places to start for building out developer tooling - if you’ve run into this issue, it's very likely someone else already has, or will! - -- Interacting with one of the SDKs via FFI: perhaps you’re a Go developer who would love to have the functionality of one of the Nym SDKs. Building an FFI tool might be something that would make your life easier, and can be shared with other developers in your situation. - -## Integrations challenge -Integration options for Nym are currently relatively restrictive due to the manner in which Nym handles sending and receiving traffic (as unordered Sphinx packets). This challenge will involve (most likely) implementing custom logic for handling Nym traffic for an existing application. - -There are several potential avenues developers can take here: -- If your application (or the application you wish to modify) is written in either Javascript or Typescript, and relies on the `fetch` library to make API calls, then you can use its drop-in replacement: [`mixfetch`](). Perhaps you wish to interact with Coingecko, or a private search engine like Kagi without leaking your IP and metadata, or an RPC endpoint. - - Example with [NTV’s privacy-preserving Coingecko API](https://github.com/notrustverify/mixfetch-examples) - - [Mixfetch docs examples](https://github.com/nymtech/nym/tree/develop/sdk/typescript/examples) - -- If you instead have an application that is able to use any of the SOCKS5, 4a, or 4 protocols (a rule of thumb: if it can communicate over Tor, it will) then you can experiment with using Nym as the transport layer. - - For Rustaceans, check out our [socks5 rust sdk example](https://nymtech.net/docs/sdk/rust.html#socks-client-example). - - For those of you who aren’t Crustaceans, then you will have to run the [Socks Client]() alongside your application as a separate process. _NOTE If you are taking this route, please make sure to include detailed documentation on how you expect users to do this, as well as including any process management tools, scripts, and configs (e.g. if you use systemd then include the configuration file for the client, as well as initialisation logic) that may streamline this process._ - - [NTV's PasteNym backend](https://github.com/notrustverify/pastenym) is a great example of an application with this architecture. - -- Nym is not only useful for blockchain-related apps, but for anything that requires network level privacy! Email clients, messaging clients, and decentralised storage are all key elements of the privacy-enabled web. Several of these sorts of apps can be found in the [community apps page](../community-resources/community-applications-and-guides.md). - -- There is currently a proof of concept using Rust Libp2p with Nym as a transport layer. Perhaps you can think of an app that uses Gossipsub for p2p communication could benefit from network-level privacy. - - [GossipSub chat example](https://github.com/nymtech/nym/tree/develop/sdk/rust/nym-sdk/examples/libp2p_chat) - - [Chainsafe's Lighthouse Nym PoC](https://github.com/ChainSafe/lighthouse/blob/nym/USE_NYM.md#usage) - -- Alternatively if you know of an app that is written in Rust or TS and could benefit from using Nym, you could fork and modify it using the SDKs. Applications such as: - - Magic Wormhole (has a [rust implementation](https://github.com/magic-wormhole/magic-wormhole.rs)) - - [Qual](https://github.com/qaul/qaul.net) (uses Rust Libp2p) - - [Syncthing](https://github.com/syncthing/syncthing) - -### MiniApp challenge -Write an app, either using one of the SDKs or a standalone client (harder). Think of what you can ‘nymify’ e.g. a version of the [TorBirdy](https://support.torproject.org/glossary/torbirdy/) extension that uses Nym instead of Tor. This is very similar to the Integration challenge in terms of the different potential _architectures_ and approaches, but just for new applications. diff --git a/documentation/old_docs/dev-portal/src/shipyard/general.md b/documentation/old_docs/dev-portal/src/shipyard/general.md deleted file mode 100644 index f07f3f22ac..0000000000 --- a/documentation/old_docs/dev-portal/src/shipyard/general.md +++ /dev/null @@ -1,16 +0,0 @@ -# General Info & Resources -Discussions and announcements will be taking place in the [builders channel on Matrix](https://matrix.to/#/#shipyardbuilders:nymtech.chat). This channel can be used for all discussions. - -There will be daily office horse between 12-14:00 CET. - -This is an open call and questions will be answered on a first come first serve basis. - -The timetable can be found on the [Shipyard website](https://nymtech.net/learn/shipyard). - -## Links -- You can find **code examples**, **tutorials**, & **quickstart** information here, on the Developer Portal. -- [Rust SDK docs](https://nymtech.net/docs/sdk/rust.html) -- [Typescript SDK docs](https://sdk.nymtech.net) -- [Platform docs](https://nymtech.net/docs) -- [NoTrustVerify's Awesome Nym list](https://github.com/notrustverify/awesome-nym) -- [Builders channel Matrix](https://matrix.to/#/#shipyardbuilders:nymtech.chat) diff --git a/documentation/old_docs/dev-portal/src/shipyard/guidelines.md b/documentation/old_docs/dev-portal/src/shipyard/guidelines.md deleted file mode 100644 index 1f4a901f7a..0000000000 --- a/documentation/old_docs/dev-portal/src/shipyard/guidelines.md +++ /dev/null @@ -1,15 +0,0 @@ -# Submission Guidelines -We expect to see the following for submissions: -- Working code demos hosted publicly (Gitlab, Github, some other git instance). -- Quality > quantity here: we’d prefer to see a contained, working, and well documented Proof of Concept over a sprawling and messy app that does more but is poorly explained and presented. _The repo must be open source and able to be used and modified by others. The license is up to you._ -- If you already have existing apps / projects you are more than welcome to extend them, instead of starting from scratch - we will only be looking at the NEW additions to make this fair. If you are doing this, make sure to write a detailed account of what it is you;ve added to the existing project, preferably with the possibility to see the ‘old’ version as well as the new one. -- Proper documentation: - - If an app / tool: - - How do you install and run the code? How is it to be used? - - An overview of the application architecture: what is it doing? Is it relying on other services? - - If a UI-based solution: - - How to run it locally? We are happy to also accept staging deployments as part of the submission (e.g. via Vercel) but this does not replace being able to run it locally. -- Please make sure that your application works on commonly reproducible system environments (e.g. if you’re developing on Artix Linux please check for the necessary dependencies for more common-place OSes such as Debian, or Arch). If you are developing on Windows please make sure that it works on non-Windows machines also. Where possible please try to include build and install instructions for a variety of OSes. - -## How to submit? -Please follow the instructions [here](https://github.com/nymtech/nym/discussions/4143). \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/shipyard/infra.md b/documentation/old_docs/dev-portal/src/shipyard/infra.md deleted file mode 100644 index 73c3afadb3..0000000000 --- a/documentation/old_docs/dev-portal/src/shipyard/infra.md +++ /dev/null @@ -1,12 +0,0 @@ -# A Note on Infrastructure -If you are writing an application that requires sending messages through the mixnet, then you will either be relying on existing infrastructure nodes (network requesters), or writing your own custom service (for example, the service written as part of the Rust SDK tutorial). - -If you are relying on network requesters then chances are that the IPs or domains your app relies on will not already be on the whitelist. Ideally, you would [run your own,](https://nymtech.net/operators/nodes/network-requester-setup.html) but we will also run a few nodes in ‘open proxy’ mode and share the addresses so that you can use them when beginning to develop. - -## Node Details: -- NR1 - - Location: Singapore - - Nym Address: `FDeWfd8q686PWLXJDCqNJTCbydTk1KSux5HVftimsPyx.9XyThN4yh92eTMuLp1NvWicRZob8Ei5xpba9dvcMLxcN@9Byd9VAtyYMnbVAcqdoQxJnq76XEg2dbxbiF5Aa5Jj9J` -- NR2 - - Location: Frankfurt - - Nym Address: `BNypKaGiGY8GNRN4gpV95GcaVS8n7CrHuoZNgQ2ezqv2.ACpaixzuaSzuMajVQj6aR7cbpbvp676tm21MiLbX1gni@678qVUJ21uwxZBhp3r56z7GRf6gMh3NYDHruTegPtgMf` \ No newline at end of file diff --git a/documentation/old_docs/dev-portal/src/tutorials/coming-soon.md b/documentation/old_docs/dev-portal/src/tutorials/coming-soon.md deleted file mode 100644 index a435e701ef..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/coming-soon.md +++ /dev/null @@ -1,11 +0,0 @@ -# Stub: Updates Coming Soon! - -There is a lot of development work ongoing with our clients; as such the old tutorials that were here got quite out of date. - -However, you can still access the old [tutorial codebases](https://github.com/nymtech/developer-tutorials) as well as the markdown files in the `tutorial-archives/` directory in the [developer portal docs repo](https://github.com/nymtech/nym/tree/develop/documentation/dev-portal/src/tutorials) if you want. - -More up to date tutorials will be coming soon for using RPC and gRPC, `mixfetch`, as well as using the [FFI libraries](https://github.com/nymtech/nym/tree/develop/sdk/ffi) for interacting with the Mixnet via C++ and Go. - -> Developers who are searching for example code can use the following list as the current 'best practices': -> * Generic traffic transport: the [`zcash-rpc-demo`](https://github.com/nymtech/nym-zcash-rpc-demo) repo, although here used to only pipe RPC traffic, is a proof of concept 'generic' mixnet piping example which exposes a TPC Socket on the client side for incoming traffic, pipes this through the mixnet, and then streams TCP packets 'out' the other side. -> * In-browser usage: see the [browser examples](../examples/browser-only.md) page for examples using `mixFetch`. diff --git a/documentation/old_docs/dev-portal/src/tutorials/telegram.md b/documentation/old_docs/dev-portal/src/tutorials/telegram.md deleted file mode 100644 index 7d1b447ffc..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/telegram.md +++ /dev/null @@ -1,43 +0,0 @@ -# Telegram NymConnect Integration - -*This is a shortened version of a [Nym Community post](https://blog.nymtech.net/how-to-use-telegram-in-iraq-with-nymconnect-106a3b8dd050) written by Saliveja.* - -![](../images/telegram.png) - -The purpose of the following manual is not to promote Telegram but so people can use it with the Nym mixnet if they wish to, should a situation ask for that. This privacy-enhances Telegram at the network level and allows users to access the application from locations like where the application was banned. - -See also: [Element (Matrix) over the Nym mixnet](./matrix.md): private, decentralised and secure messaging. - -## Setup & Run - -Here’s how to configure Telegram with NymConnect: - -1. **Download and install NymConnect(https://nymtech.net/download-nymconnect/).** - For more releases, check out [Github](https://github.com/nymtech/nym/tags). NymConnect is available for Linux, Windows, and MacOS. - On Linux make sure NymConnect is executable. Opening a terminal in the same directory and run: - ```sh - chmod +x ./ - ``` -2. **Start NymConnect** - Telegram is added to NymConnect by default. -3. **Click connect - the host and port will now be displayed.** -4. **Click on host or port to copy** the value to the clipboard. -5. **Open the Telegram proxy settings.** - Linux: Telegram -> Settings -> Advanced -> Connection type -> Use custom proxy - MacOS: Telegram -> Settings -> Advanced -> Data & Storage -> Connection Type -> Use custom Proxy - Windows: Telegram -> Settings -> Data and Storage -> Use proxy -6. **Add a proxy** with the Add proxy button. -7. **Select SOCKS5** and make sure the port details are the same as those generated by NymConnect. Alternatively, follow this link: https://t.me/socks?server=127.0.0.1&port=1080 -8. **Save the proxy settings** in Telegram. -9. **Telegram is now running through the Nym Mixnet and is privacy-enhanced!** - This allows you to connect from regions which blocked Telegram. -10. Note if you remain idle on Telegram for a while you might lose connectivity and your messages might not get through via SOCKS5 proxy. If that happens reconnect your NymConnect and reset the proxy again. - - -Follow this [video](https://youtu.be/quj8H2qeOwY?t=97) to see the steps on Telegram setup. - - -**Now your Telegram runs over NymConnect.** - -NymConnect is currently available for several applications and service providers. Support for more apps is on the way. For any bug reports or feedback please reach out to us on Telegram or our [Discord](https://nymtech.net/go/discord) server. - diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/client-src.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/client-src.md deleted file mode 100644 index 85e1d368fb..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/client-src.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Client pt2 diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/client.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/client.md deleted file mode 100644 index c6db01fb6a..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/client.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Client diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/intro.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/intro.md deleted file mode 100644 index 627054da8d..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/intro.md +++ /dev/null @@ -1 +0,0 @@ -# Blockchain Service pt1 diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/lib.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/lib.md deleted file mode 100644 index 4be852e7ae..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/lib.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Lib diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/overview.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/overview.md deleted file mode 100644 index e7bbb2f8f1..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/overview.md +++ /dev/null @@ -1 +0,0 @@ -# Tutorial Overview diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/preparing-env.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/preparing-env.md deleted file mode 100644 index ea95eb3fa8..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/preparing-env.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Environment diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/querying.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/querying.md deleted file mode 100644 index 6830e38016..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/querying.md +++ /dev/null @@ -1 +0,0 @@ -# Querying the Chain diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/service-src.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/service-src.md deleted file mode 100644 index cc140cc11f..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/service-src.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Service pt2 diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/service.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/service.md deleted file mode 100644 index 1090443702..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/cosmos-service/service.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Service diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/rust-sdk.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/rust-sdk.md deleted file mode 100644 index 5aef071e46..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/rust-sdk.md +++ /dev/null @@ -1 +0,0 @@ -# Rust SDK diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/overview.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/overview.md deleted file mode 100644 index e7bbb2f8f1..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/overview.md +++ /dev/null @@ -1 +0,0 @@ -# Tutorial Overview diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/preparating-env.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/preparating-env.md deleted file mode 100644 index df2ffc650c..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/preparating-env.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your User Client Environment diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/preparating-env2.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/preparating-env2.md deleted file mode 100644 index 5d9a9d20c7..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/preparating-env2.md +++ /dev/null @@ -1 +0,0 @@ -# Preparing Your Service Provider Environment diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/sending-message.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/sending-message.md deleted file mode 100644 index 05f320eeae..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/sending-message.md +++ /dev/null @@ -1 +0,0 @@ -# Sending a Message Through the Mixnet diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/service-provider.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/service-provider.md deleted file mode 100644 index e69d01ee83..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/service-provider.md +++ /dev/null @@ -1 +0,0 @@ -# Building Your Service Provider diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/simple-service-provider.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/simple-service-provider.md deleted file mode 100644 index 246eebb2f9..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/simple-service-provider.md +++ /dev/null @@ -1 +0,0 @@ -# Simple Service Provider diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/user-client.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/user-client.md deleted file mode 100644 index d8c44a4841..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/simple-service-provider/user-client.md +++ /dev/null @@ -1 +0,0 @@ -# Building Your User Client diff --git a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/typescript.md b/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/typescript.md deleted file mode 100644 index 42c9775801..0000000000 --- a/documentation/old_docs/dev-portal/src/tutorials/tutorial-archives/typescript.md +++ /dev/null @@ -1 +0,0 @@ -# Typescript diff --git a/documentation/old_docs/dev-portal/themes/css/chrome.css b/documentation/old_docs/dev-portal/themes/css/chrome.css deleted file mode 100644 index e16262342c..0000000000 --- a/documentation/old_docs/dev-portal/themes/css/chrome.css +++ /dev/null @@ -1,608 +0,0 @@ -/* CSS for UI elements (a.k.a. chrome) */ - -@import 'variables.css'; - -html { - scrollbar-color: var(--scrollbar) var(--bg); -} -#searchresults a, -.content a:link, -a:visited, -a > .hljs { - color: var(--links); -} - -/* - body-container is necessary because mobile browsers don't seem to like - overflow-x on the body tag when there is a tag. -*/ -#body-container { - /* - This is used when the sidebar pushes the body content off the side of - the screen on small screens. Without it, dragging on mobile Safari - will want to reposition the viewport in a weird way. - */ - overflow-x: clip; -} - -/* Menu Bar */ - -#menu-bar, -#menu-bar-hover-placeholder { - z-index: 101; - margin: auto calc(0px - var(--page-padding)); -} -#menu-bar { - position: relative; - display: flex; - flex-wrap: wrap; - background-color: var(--bg); - border-block-end-color: var(--bg); - border-block-end-width: 1px; - border-block-end-style: solid; -} -#menu-bar.sticky, -.js #menu-bar-hover-placeholder:hover + #menu-bar, -.js #menu-bar:hover, -.js.sidebar-visible #menu-bar { - position: -webkit-sticky; - position: sticky; - top: 0 !important; -} -#menu-bar-hover-placeholder { - position: sticky; - position: -webkit-sticky; - top: 0; - height: var(--menu-bar-height); -} -#menu-bar.bordered { - border-block-end-color: var(--table-border-color); -} -#menu-bar i, #menu-bar .icon-button { - position: relative; - padding: 0 8px; - z-index: 10; - line-height: var(--menu-bar-height); - cursor: pointer; - transition: color 0.5s; -} -@media only screen and (max-width: 420px) { - #menu-bar i, #menu-bar .icon-button { - padding: 0 5px; - } -} - -.icon-button { - border: none; - background: none; - padding: 0; - color: inherit; -} -.icon-button i { - margin: 0; -} - -.right-buttons { - margin: 0 15px; -} -.right-buttons a { - text-decoration: none; -} - -.left-buttons { - display: flex; - margin: 0 5px; -} -.no-js .left-buttons button { - display: none; -} - -.menu-title { - position: absolute; - left: 50%; - display: inline-block; - font-weight: 200; - font-size: 2.4rem; - line-height: var(--menu-bar-height); - text-align: center; - margin: 0; - flex: 1; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; -} -.js .menu-title { - cursor: pointer; -} - -.menu-bar, -.menu-bar:visited, -.nav-chapters, -.nav-chapters:visited, -.mobile-nav-chapters, -.mobile-nav-chapters:visited, -.menu-bar .icon-button, -.menu-bar a i { - color: var(--icons); -} - -.menu-bar i:hover, -.menu-bar .icon-button:hover, -.nav-chapters:hover, -.mobile-nav-chapters i:hover { - color: var(--icons-hover); -} - -/* Nav Icons */ - -.nav-chapters { - font-size: 2.5em; - text-align: center; - text-decoration: none; - - position: fixed; - top: 0; - bottom: 0; - margin: 0; - max-width: auto; - min-width: auto; - - display: flex; - justify-content: center; - align-content: center; - flex-direction: column; - - transition: color 0.5s, background-color 0.5s; -} - -.nav-chapters:hover { - text-decoration: none; - background-color: var(--theme-hover); - transition: background-color 0.15s, color 0.15s; -} - -.nav-wrapper { - margin-block-start: 50px; - display: none; -} - -.mobile-nav-chapters { - font-size: 2.5em; - text-align: center; - text-decoration: none; - width: 90px; - border-radius: 5px; - background-color: var(--sidebar-bg); -} - -/* Only Firefox supports flow-relative values */ -.previous { float: left; } -[dir=rtl] .previous { float: right; } - -/* Only Firefox supports flow-relative values */ -.next { - float: right; - right: var(--page-padding); -} -[dir=rtl] .next { - float: left; - right: unset; - left: var(--page-padding); -} - -/* Use the correct buttons for RTL layouts*/ -[dir=rtl] .previous i.fa-angle-left:before {content:"\f105";} -[dir=rtl] .next i.fa-angle-right:before { content:"\f104"; } - -@media only screen and (max-width: 1080px) { - .nav-wide-wrapper { display: none; } - .nav-wrapper { display: block; } -} - -/* sidebar-visible */ -@media only screen and (max-width: 1380px) { - #sidebar-toggle-anchor:checked ~ .page-wrapper .nav-wide-wrapper { display: none; } - #sidebar-toggle-anchor:checked ~ .page-wrapper .nav-wrapper { display: block; } -} - -/* Inline code */ - -:not(pre) > .hljs { - display: inline; - padding: 0.1em 0.3em; - border-radius: 3px; -} - -:not(pre):not(a) > .hljs { - color: var(--inline-code-color); - overflow-x: initial; -} - -a:hover > .hljs { - text-decoration: underline; -} - -pre { - position: relative; -} -pre > .buttons { - position: absolute; - z-index: 100; - right: 0px; - top: 2px; - margin: 0px; - padding: 2px 0px; - - color: var(--sidebar-fg); - cursor: pointer; - visibility: hidden; - opacity: 0; - transition: visibility 0.1s linear, opacity 0.1s linear; -} -pre:hover > .buttons { - visibility: visible; - opacity: 1 -} -pre > .buttons :hover { - color: var(--sidebar-active); - border-color: var(--icons-hover); - background-color: var(--theme-hover); -} -pre > .buttons i { - margin-inline-start: 8px; -} -pre > .buttons button { - cursor: inherit; - margin: 0px 5px; - padding: 3px 5px; - font-size: 14px; - - border-style: solid; - border-width: 1px; - border-radius: 4px; - border-color: var(--icons); - background-color: var(--theme-popup-bg); - transition: 100ms; - transition-property: color,border-color,background-color; - color: var(--icons); -} -@media (pointer: coarse) { - pre > .buttons button { - /* On mobile, make it easier to tap buttons. */ - padding: 0.3rem 1rem; - } - - .sidebar-resize-indicator { - /* Hide resize indicator on devices with limited accuracy */ - display: none; - } -} -pre > code { - display: block; - padding: 1rem; -} - -/* FIXME: ACE editors overlap their buttons because ACE does absolute - positioning within the code block which breaks padding. The only solution I - can think of is to move the padding to the outer pre tag (or insert a div - wrapper), but that would require fixing a whole bunch of CSS rules. -*/ -.hljs.ace_editor { - padding: 0rem 0rem; -} - -pre > .result { - margin-block-start: 10px; -} - -/* Search */ - -#searchresults a { - text-decoration: none; -} - -mark { - border-radius: 2px; - padding-block-start: 0; - padding-block-end: 1px; - padding-inline-start: 3px; - padding-inline-end: 3px; - margin-block-start: 0; - margin-block-end: -1px; - margin-inline-start: -3px; - margin-inline-end: -3px; - background-color: var(--search-mark-bg); - transition: background-color 300ms linear; - cursor: pointer; -} - -mark.fade-out { - background-color: rgba(0,0,0,0) !important; - cursor: auto; -} - -.searchbar-outer { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); -} - -#searchbar { - width: 100%; - margin-block-start: 5px; - margin-block-end: 0; - margin-inline-start: auto; - margin-inline-end: auto; - padding: 10px 16px; - transition: box-shadow 300ms ease-in-out; - border: 1px solid var(--searchbar-border-color); - border-radius: 3px; - background-color: var(--searchbar-bg); - color: var(--searchbar-fg); -} -#searchbar:focus, -#searchbar.active { - box-shadow: 0 0 3px var(--searchbar-shadow-color); -} - -.searchresults-header { - font-weight: bold; - font-size: 1em; - padding-block-start: 18px; - padding-block-end: 0; - padding-inline-start: 5px; - padding-inline-end: 0; - color: var(--searchresults-header-fg); -} - -.searchresults-outer { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); - border-block-end: 1px dashed var(--searchresults-border-color); -} - -ul#searchresults { - list-style: none; - padding-inline-start: 20px; -} -ul#searchresults li { - margin: 10px 0px; - padding: 2px; - border-radius: 2px; -} -ul#searchresults li.focus { - background-color: var(--searchresults-li-bg); -} -ul#searchresults span.teaser { - display: block; - clear: both; - margin-block-start: 5px; - margin-block-end: 0; - margin-inline-start: 20px; - margin-inline-end: 0; - font-size: 0.8em; -} -ul#searchresults span.teaser em { - font-weight: bold; - font-style: normal; -} - -/* Sidebar */ - -.sidebar { - position: fixed; - left: 0; - top: 0; - bottom: 0; - width: var(--sidebar-width); - font-size: 1em; - box-sizing: border-box; - -webkit-overflow-scrolling: touch; - overscroll-behavior-y: contain; - background-color: var(--sidebar-bg); - color: var(--sidebar-fg); -} -[dir=rtl] .sidebar { left: unset; right: 0; } -.sidebar-resizing { - -moz-user-select: none; - -webkit-user-select: none; - -ms-user-select: none; - user-select: none; -} -.no-js .sidebar, -.js:not(.sidebar-resizing) .sidebar { - transition: transform 0.3s; /* Animation: slide away */ -} -.sidebar code { - line-height: 2em; -} -.sidebar .sidebar-scrollbox { - overflow-y: auto; - position: absolute; - top: 0; - bottom: 0; - left: 0; - right: 0; - padding: 10px 10px; -} -.sidebar .sidebar-resize-handle { - position: absolute; - cursor: col-resize; - width: 0; - right: calc(var(--sidebar-resize-indicator-width) * -1); - top: 0; - bottom: 0; - display: flex; - align-items: center; -} - -.sidebar-resize-handle .sidebar-resize-indicator { - width: 100%; - height: 12px; - background-color: var(--icons); - margin-inline-start: var(--sidebar-resize-indicator-space); -} - -[dir=rtl] .sidebar .sidebar-resize-handle { - left: calc(var(--sidebar-resize-indicator-width) * -1); - right: unset; -} -.js .sidebar .sidebar-resize-handle { - cursor: col-resize; - width: calc(var(--sidebar-resize-indicator-width) - var(--sidebar-resize-indicator-space)); -} -/* sidebar-hidden */ -#sidebar-toggle-anchor:not(:checked) ~ .sidebar { - transform: translateX(calc(0px - var(--sidebar-width) - var(--sidebar-resize-indicator-width))); - z-index: -1; -} -[dir=rtl] #sidebar-toggle-anchor:not(:checked) ~ .sidebar { - transform: translateX(calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width))); -} -.sidebar::-webkit-scrollbar { - background: var(--sidebar-bg); -} -.sidebar::-webkit-scrollbar-thumb { - background: var(--scrollbar); -} - -/* sidebar-visible */ -#sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: translateX(calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width))); -} -[dir=rtl] #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: translateX(calc(0px - var(--sidebar-width) - var(--sidebar-resize-indicator-width))); -} -@media only screen and (min-width: 620px) { - #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: none; - margin-inline-start: calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width)); - } - [dir=rtl] #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: none; - } -} - -.chapter { - list-style: none outside none; - padding-inline-start: 0; - line-height: 2em; -} - -.chapter ol { - width: 100%; -} - -.chapter li { - display: flex; - color: var(--sidebar-non-existant); -} -.chapter li a { - display: block; - padding: 0; - text-decoration: none; - color: var(--sidebar-fg); -} - -.chapter li a:hover { - color: var(--sidebar-active); -} - -.chapter li a.active { - color: var(--sidebar-active); -} - -.chapter li > a.toggle { - cursor: pointer; - display: block; - margin-inline-start: auto; - padding: 0 10px; - user-select: none; - opacity: 0.68; -} - -.chapter li > a.toggle div { - transition: transform 0.5s; -} - -/* collapse the section */ -.chapter li:not(.expanded) + li > ol { - display: none; -} - -.chapter li.chapter-item { - line-height: 1.5em; - margin-block-start: 0.6em; -} - -.chapter li.expanded > a.toggle div { - transform: rotate(90deg); -} - -.spacer { - width: 100%; - height: 3px; - margin: 5px 0px; -} -.chapter .spacer { - background-color: var(--sidebar-spacer); -} - -@media (-moz-touch-enabled: 1), (pointer: coarse) { - .chapter li a { padding: 5px 0; } - .spacer { margin: 10px 0; } -} - -.section { - list-style: none outside none; - padding-inline-start: 20px; - line-height: 1.5em; -} - -/* Theme Menu Popup */ - -.theme-popup { - position: absolute; - left: 10px; - top: var(--menu-bar-height); - z-index: 1000; - border-radius: 4px; - font-size: 0.7em; - color: var(--fg); - background: var(--theme-popup-bg); - border: 1px solid var(--theme-popup-border); - margin: 0; - padding: 0; - list-style: none; - display: none; - /* Don't let the children's background extend past the rounded corners. */ - overflow: hidden; -} -[dir=rtl] .theme-popup { left: unset; right: 10px; } -.theme-popup .default { - color: var(--icons); -} -.theme-popup .theme { - width: 100%; - border: 0; - margin: 0; - padding: 2px 20px; - line-height: 25px; - white-space: nowrap; - text-align: start; - cursor: pointer; - color: inherit; - background: inherit; - font-size: inherit; -} -.theme-popup .theme:hover { - background-color: var(--theme-hover); -} - -.theme-selected::before { - display: inline-block; - content: "✓"; - margin-inline-start: -14px; - width: 14px; -} diff --git a/documentation/old_docs/dev-portal/themes/css/general.css b/documentation/old_docs/dev-portal/themes/css/general.css deleted file mode 100644 index df8c1d12d2..0000000000 --- a/documentation/old_docs/dev-portal/themes/css/general.css +++ /dev/null @@ -1,234 +0,0 @@ -/* Base styles and content styles */ - -@import 'variables.css'; - -:root { - /* Browser default font-size is 16px, this way 1 rem = 10px */ - font-size: 70%; - color-scheme: var(--color-scheme); -} - -html { - font-family: "Open Sans", sans-serif; - color: var(--fg); - background-color: var(--bg); - text-size-adjust: none; - -webkit-text-size-adjust: none; -} - -body { - margin: 0; - font-size: 1.5rem; - overflow-x: hidden; -} - -code { - font-family: var(--mono-font) !important; - font-size: 0.9em; - direction: ltr !important; -} - -/* make long words/inline code not x overflow */ -main { - overflow-wrap: break-word; -} - -/* make wide tables scroll if they overflow */ -.table-wrapper { - overflow-x: auto; -} - -/* Don't change font size in headers. */ -h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { - font-size: unset; -} - -.left { float: left; } -.right { float: right; } -.boring { opacity: 0.6; } -.hide-boring .boring { display: none; } -.hidden { display: none !important; } - -h2, h3 { margin-block-start: 2.5em; } -h4, h5 { margin-block-start: 2em; } - -.header + .header h3, -.header + .header h4, -.header + .header h5 { - margin-block-start: 1em; -} - -h1:target::before, -h2:target::before, -h3:target::before, -h4:target::before, -h5:target::before, -h6:target::before { - display: inline-block; - content: "»"; - margin-inline-start: -30px; - width: 30px; -} - -/* This is broken on Safari as of version 14, but is fixed - in Safari Technology Preview 117 which I think will be Safari 14.2. - https://bugs.webkit.org/show_bug.cgi?id=218076 -*/ -:target { - /* Safari does not support logical properties */ - scroll-margin-top: calc(var(--menu-bar-height) + 0.5em); -} - -.page { - outline: 0; - padding: 0 var(--page-padding); - margin-block-start: calc(0px - var(--menu-bar-height)); /* Compensate for the #menu-bar-hover-placeholder */ -} -.page-wrapper { - box-sizing: border-box; - background-color: var(--bg); -} -.no-js .page-wrapper, -.js:not(.sidebar-resizing) .page-wrapper { - transition: margin-left 0.3s ease, transform 0.3s ease; /* Animation: slide away */ -} -[dir=rtl] .js:not(.sidebar-resizing) .page-wrapper { - transition: margin-right 0.3s ease, transform 0.3s ease; /* Animation: slide away */ -} - -.content { - overflow-y: auto; - padding: 0 10px; -} -.content main { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); -} -.content p { line-height: 1.45em; } -.content ol { line-height: 1.45em; } -.content ul { line-height: 1.45em; } -.content a { text-decoration: none; } -.content a:hover { text-decoration: underline; } -.content img, .content video { max-width: 100%; } -.content .header:link, -.content .header:visited { - color: var(--fg); -} -.content .header:link, -.content .header:visited:hover { - text-decoration: none; -} - -table { - margin: 0 auto; - border-collapse: collapse; -} -table td { - padding: 3px 20px; - border: 1px var(--table-border-color) solid; -} -table thead { - background: var(--table-header-bg); -} -table thead td { - font-weight: 700; - border: none; -} -table thead th { - padding: 3px 20px; -} -table thead tr { - border: 1px var(--table-header-bg) solid; -} -/* Alternate background colors for rows */ -table tbody tr:nth-child(2n) { - background: var(--table-alternate-bg); -} - - -blockquote { - margin: 20px 0; - padding: 0 20px; - color: var(--fg); - background-color: var(--quote-bg); - border-block-start: .1em solid var(--quote-border); - border-block-end: .1em solid var(--quote-border); -} - -.warning { - margin: 20px; - padding: 0 20px; - border-inline-start: 2px solid var(--warning-border); -} - -.warning:before { - position: absolute; - width: 3rem; - height: 3rem; - margin-inline-start: calc(-1.5rem - 21px); - content: "ⓘ"; - text-align: center; - background-color: var(--bg); - color: var(--warning-border); - font-weight: bold; - font-size: 2rem; -} - -blockquote .warning:before { - background-color: var(--quote-bg); -} - -kbd { - background-color: var(--table-border-color); - border-radius: 4px; - border: solid 1px var(--theme-popup-border); - box-shadow: inset 0 -1px 0 var(--theme-hover); - display: inline-block; - font-size: var(--code-font-size); - font-family: var(--mono-font); - line-height: 10px; - padding: 4px 5px; - vertical-align: middle; -} - -:not(.footnote-definition) + .footnote-definition, -.footnote-definition + :not(.footnote-definition) { - margin-block-start: 2em; -} -.footnote-definition { - font-size: 0.9em; - margin: 0.5em 0; -} -.footnote-definition p { - display: inline; -} - -.tooltiptext { - position: absolute; - visibility: hidden; - color: #fff; - background-color: #333; - transform: translateX(-50%); /* Center by moving tooltip 50% of its width left */ - left: -8px; /* Half of the width of the icon */ - top: -35px; - font-size: 0.8em; - text-align: center; - border-radius: 6px; - padding: 5px 8px; - margin: 5px; - z-index: 1000; -} -.tooltipped .tooltiptext { - visibility: visible; -} - -.chapter li.part-title { - color: var(--sidebar-fg); - margin: 5px 0px; - font-weight: bold; -} - -.result-no-output { - font-style: italic; -} diff --git a/documentation/old_docs/dev-portal/themes/css/variables.css b/documentation/old_docs/dev-portal/themes/css/variables.css deleted file mode 100644 index 51b94cfc5a..0000000000 --- a/documentation/old_docs/dev-portal/themes/css/variables.css +++ /dev/null @@ -1,287 +0,0 @@ - -/* Globals */ - -:root { - --sidebar-width: 280px; - --sidebar-resize-indicator-width: 8px; - --sidebar-resize-indicator-space: 2px; - --page-padding: 15px; - --content-max-width: 80%; - --menu-bar-height: 40px; - --mono-font: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace; - --code-font-size: 0.875em /* please adjust the ace font size accordingly in editor.js */ - --pagetoc-width: 13%; - --pagetoc-fontsize: 14.5px; -} - -@media only screen and (max-width:1439px) { - :root{ - --content-max-width: 98%; - } -} - -/* Themes */ - -.ayu { - --bg: hsl(210, 25%, 8%); - --fg: #c5c5c5; - - --sidebar-bg: #14191f; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #5c6773; - --sidebar-active: #ffb454; - --sidebar-spacer: #2d334f; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #b7b9cc; - - --links: #0096cf; - - --inline-code-color: #ffb454; - - --theme-popup-bg: #14191f; - --theme-popup-border: #5c6773; - --theme-hover: #191f26; - - --quote-bg: hsl(226, 15%, 17%); - --quote-border: hsl(226, 15%, 22%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(210, 25%, 13%); - --table-header-bg: hsl(210, 25%, 28%); - --table-alternate-bg: hsl(210, 25%, 11%); - - --searchbar-border-color: #848484; - --searchbar-bg: #424242; - --searchbar-fg: #fff; - --searchbar-shadow-color: #d4c89f; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #252932; - --search-mark-bg: #e3b171; - - --color-scheme: dark; -} - -.coal { - --bg: hsl(200, 7%, 8%); - --fg: #98a3ad; - - --sidebar-bg: #292c2f; - --sidebar-fg: #a1adb8; - --sidebar-non-existant: #505254; - --sidebar-active: #3473ad; - --sidebar-spacer: #393939; - - --scrollbar: var(--sidebar-fg); - - --icons: #43484d; - --icons-hover: #b3c0cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #141617; - --theme-popup-border: #43484d; - --theme-hover: #1f2124; - - --quote-bg: hsl(234, 21%, 18%); - --quote-border: hsl(234, 21%, 23%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(200, 7%, 13%); - --table-header-bg: hsl(200, 7%, 28%); - --table-alternate-bg: hsl(200, 7%, 11%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #b7b7b7; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #98a3ad; - --searchresults-li-bg: #2b2b2f; - --search-mark-bg: #355c7d; - - --color-scheme: dark; -} - -.light { - --bg: hsl(0, 0%, 100%); - --fg: hsl(0, 0%, 0%); - - --sidebar-bg: #fafafa; - --sidebar-fg: hsl(0, 0%, 0%); - --sidebar-non-existant: #aaaaaa; - --sidebar-active: #1f1fff; - --sidebar-spacer: #f4f4f4; - - --scrollbar: #8F8F8F; - - --icons: #747474; - --icons-hover: #000000; - - --links: #1f1fff; - - --inline-code-color: #F42C4C; - - --theme-popup-bg: #fafafa; - --theme-popup-border: #cccccc; - --theme-hover: #e6e6e6; - - --quote-bg: hsl(197, 37%, 96%); - --quote-border: hsl(197, 37%, 91%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(0, 0%, 95%); - --table-header-bg: hsl(0, 0%, 80%); - --table-alternate-bg: hsl(0, 0%, 97%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #fafafa; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #e4f2fe; - --search-mark-bg: #a2cff5; - - --color-scheme: light; -} - -.navy { - --bg: hsl(226, 23%, 11%); - --fg: #bcbdd0; - - --sidebar-bg: #282d3f; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #505274; - --sidebar-active: #2b79a2; - --sidebar-spacer: #2d334f; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #b7b9cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #161923; - --theme-popup-border: #737480; - --theme-hover: #282e40; - - --quote-bg: hsl(226, 15%, 17%); - --quote-border: hsl(226, 15%, 22%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(226, 23%, 16%); - --table-header-bg: hsl(226, 23%, 31%); - --table-alternate-bg: hsl(226, 23%, 14%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #aeaec6; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #5f5f71; - --searchresults-border-color: #5c5c68; - --searchresults-li-bg: #242430; - --search-mark-bg: #a2cff5; - - --color-scheme: dark; -} - -.rust { - --bg: hsl(60, 9%, 87%); - --fg: #262625; - - --sidebar-bg: #3b2e2a; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #505254; - --sidebar-active: #e69f67; - --sidebar-spacer: #45373a; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #262625; - - --links: #2b79a2; - - --inline-code-color: #6e6b5e; - - --theme-popup-bg: #e1e1db; - --theme-popup-border: #b38f6b; - --theme-hover: #99908a; - - --quote-bg: hsl(60, 5%, 75%); - --quote-border: hsl(60, 5%, 70%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(60, 9%, 82%); - --table-header-bg: #b3a497; - --table-alternate-bg: hsl(60, 9%, 84%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #fafafa; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #dec2a2; - --search-mark-bg: #e69f67; - - --color-scheme: light; -} - -@media (prefers-color-scheme: dark) { - .light.no-js { - --bg: hsl(200, 7%, 8%); - --fg: #98a3ad; - - --sidebar-bg: #292c2f; - --sidebar-fg: #a1adb8; - --sidebar-non-existant: #505254; - --sidebar-active: #3473ad; - --sidebar-spacer: #393939; - - --scrollbar: var(--sidebar-fg); - - --icons: #43484d; - --icons-hover: #b3c0cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #141617; - --theme-popup-border: #43484d; - --theme-hover: #1f2124; - - --quote-bg: hsl(234, 21%, 18%); - --quote-border: hsl(234, 21%, 23%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(200, 7%, 13%); - --table-header-bg: hsl(200, 7%, 28%); - --table-alternate-bg: hsl(200, 7%, 11%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #b7b7b7; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #98a3ad; - --searchresults-li-bg: #2b2b2f; - --search-mark-bg: #355c7d; - } -} diff --git a/documentation/old_docs/dev-portal/themes/custom.css b/documentation/old_docs/dev-portal/themes/custom.css deleted file mode 100644 index 6613d3e08b..0000000000 --- a/documentation/old_docs/dev-portal/themes/custom.css +++ /dev/null @@ -1,57 +0,0 @@ -:root { - --mono-font: Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace; -} - -.coal { - --fg: #f2f2f2; - --sidebar-fg: #f2f2f2; - --sidebar-active: #fb6e4e; - --icons-hover: #fb6e4e; - --links: #fb6e4e; - - ::selection { - color: #121726; - background-color: #c5573d; - } - - select option { - background-color: #121726; - } -} - -.light { - --sidebar-active: #fb6e4e; - --icons-hover: #fb6e4e; - --links: #fb6e4e; - - ::selection { - color: #f2f2f2; - background-color: #c5573d; - } -} - -/*properly centering the title given the additional header items*/ -.menu-title { - left: 45%; -} - -.menu-bar .a:hover, - -/*necessary because of ^*/ -.right-buttons { - position: absolute; - right: 0; -} - -select { - font-size: 16px; -} - - - -footer { - font-size: 0.8em; - text-align: center; - border-top: 1px solid black; - padding: 5px 0; -} diff --git a/documentation/old_docs/dev-portal/themes/index.hbs b/documentation/old_docs/dev-portal/themes/index.hbs deleted file mode 100644 index d0bb54d0c3..0000000000 --- a/documentation/old_docs/dev-portal/themes/index.hbs +++ /dev/null @@ -1,358 +0,0 @@ - - - - - - {{ title }} - {{#if is_print }} - - {{/if}} - {{#if base_url}} - - {{/if}} - - - - {{> head}} - - - - - - {{#if favicon_svg}} - - {{/if}} - {{#if favicon_png}} - - {{/if}} - - - - {{#if print_enable}} - - {{/if}} - - - - {{#if copy_fonts}} - - {{/if}} - - - - - - - - {{#each additional_css}} - - {{/each}} - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
- -
- {{> header}} - - - - {{#if search_enabled}} - - {{/if}} - - - - -
-
-
-
- -
-
- - {{{ content }}} -
-
-
- - -
-
- - - -
- - {{#if live_reload_endpoint}} - - - {{/if}} - - {{#if playground_line_numbers}} - - {{/if}} - - {{#if playground_copyable}} - - {{/if}} - - {{#if playground_js}} - - - - - - {{/if}} - - {{#if search_js}} - - - - {{/if}} - - - - - - - {{#each additional_js}} - - {{/each}} - - {{#if is_print}} - {{#if mathjax_support}} - - {{else}} - - {{/if}} - {{/if}} - - -
- - diff --git a/documentation/old_docs/dev-portal/themes/mdbook-admonish.css b/documentation/old_docs/dev-portal/themes/mdbook-admonish.css deleted file mode 100644 index 45aeff0511..0000000000 --- a/documentation/old_docs/dev-portal/themes/mdbook-admonish.css +++ /dev/null @@ -1,348 +0,0 @@ -@charset "UTF-8"; -:is(.admonition) { - display: flow-root; - margin: 1.5625em 0; - padding: 0 1.2rem; - color: var(--fg); - page-break-inside: avoid; - background-color: var(--bg); - border: 0 solid black; - border-inline-start-width: 0.4rem; - border-radius: 0.2rem; - box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1); -} -@media print { - :is(.admonition) { - box-shadow: none; - } -} -:is(.admonition) > * { - box-sizing: border-box; -} -:is(.admonition) :is(.admonition) { - margin-top: 1em; - margin-bottom: 1em; -} -:is(.admonition) > .tabbed-set:only-child { - margin-top: 0; -} -html :is(.admonition) > :last-child { - margin-bottom: 1.2rem; -} - -a.admonition-anchor-link { - display: none; - position: absolute; - left: -1.2rem; - padding-right: 1rem; -} -a.admonition-anchor-link:link, a.admonition-anchor-link:visited { - color: var(--fg); -} -a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover { - text-decoration: none; -} -a.admonition-anchor-link::before { - content: "§"; -} - -:is(.admonition-title, summary.admonition-title) { - position: relative; - min-height: 4rem; - margin-block: 0; - margin-inline: -1.6rem -1.2rem; - padding-block: 0.8rem; - padding-inline: 4.4rem 1.2rem; - font-weight: 700; - background-color: rgba(68, 138, 255, 0.1); - print-color-adjust: exact; - -webkit-print-color-adjust: exact; - display: flex; -} -:is(.admonition-title, summary.admonition-title) p { - margin: 0; -} -html :is(.admonition-title, summary.admonition-title):last-child { - margin-bottom: 0; -} -:is(.admonition-title, summary.admonition-title)::before { - position: absolute; - top: 0.625em; - inset-inline-start: 1.6rem; - width: 2rem; - height: 2rem; - background-color: #448aff; - print-color-adjust: exact; - -webkit-print-color-adjust: exact; - mask-image: url('data:image/svg+xml;charset=utf-8,'); - -webkit-mask-image: url('data:image/svg+xml;charset=utf-8,'); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-size: contain; - content: ""; -} -:is(.admonition-title, summary.admonition-title):hover a.admonition-anchor-link { - display: initial; -} - -details.admonition > summary.admonition-title::after { - position: absolute; - top: 0.625em; - inset-inline-end: 1.6rem; - height: 2rem; - width: 2rem; - background-color: currentcolor; - mask-image: var(--md-details-icon); - -webkit-mask-image: var(--md-details-icon); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-size: contain; - content: ""; - transform: rotate(0deg); - transition: transform 0.25s; -} -details[open].admonition > summary.admonition-title::after { - transform: rotate(90deg); -} - -:root { - --md-details-icon: url("data:image/svg+xml;charset=utf-8,"); -} - -:root { - --md-admonition-icon--admonish-note: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-abstract: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-info: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-tip: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-success: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-question: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-warning: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-failure: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-danger: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-bug: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-example: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-quote: url("data:image/svg+xml;charset=utf-8,"); -} - -:is(.admonition):is(.admonish-note) { - border-color: #448aff; -} - -:is(.admonish-note) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(68, 138, 255, 0.1); -} -:is(.admonish-note) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #448aff; - mask-image: var(--md-admonition-icon--admonish-note); - -webkit-mask-image: var(--md-admonition-icon--admonish-note); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-abstract, .admonish-summary, .admonish-tldr) { - border-color: #00b0ff; -} - -:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 176, 255, 0.1); -} -:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00b0ff; - mask-image: var(--md-admonition-icon--admonish-abstract); - -webkit-mask-image: var(--md-admonition-icon--admonish-abstract); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-info, .admonish-todo) { - border-color: #00b8d4; -} - -:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 184, 212, 0.1); -} -:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00b8d4; - mask-image: var(--md-admonition-icon--admonish-info); - -webkit-mask-image: var(--md-admonition-icon--admonish-info); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-tip, .admonish-hint, .admonish-important) { - border-color: #00bfa5; -} - -:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 191, 165, 0.1); -} -:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00bfa5; - mask-image: var(--md-admonition-icon--admonish-tip); - -webkit-mask-image: var(--md-admonition-icon--admonish-tip); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-success, .admonish-check, .admonish-done) { - border-color: #00c853; -} - -:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 200, 83, 0.1); -} -:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00c853; - mask-image: var(--md-admonition-icon--admonish-success); - -webkit-mask-image: var(--md-admonition-icon--admonish-success); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-question, .admonish-help, .admonish-faq) { - border-color: #64dd17; -} - -:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(100, 221, 23, 0.1); -} -:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #64dd17; - mask-image: var(--md-admonition-icon--admonish-question); - -webkit-mask-image: var(--md-admonition-icon--admonish-question); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-warning, .admonish-caution, .admonish-attention) { - border-color: #ff9100; -} - -:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 145, 0, 0.1); -} -:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff9100; - mask-image: var(--md-admonition-icon--admonish-warning); - -webkit-mask-image: var(--md-admonition-icon--admonish-warning); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-failure, .admonish-fail, .admonish-missing) { - border-color: #ff5252; -} - -:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 82, 82, 0.1); -} -:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff5252; - mask-image: var(--md-admonition-icon--admonish-failure); - -webkit-mask-image: var(--md-admonition-icon--admonish-failure); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-danger, .admonish-error) { - border-color: #ff1744; -} - -:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 23, 68, 0.1); -} -:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff1744; - mask-image: var(--md-admonition-icon--admonish-danger); - -webkit-mask-image: var(--md-admonition-icon--admonish-danger); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-bug) { - border-color: #f50057; -} - -:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(245, 0, 87, 0.1); -} -:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #f50057; - mask-image: var(--md-admonition-icon--admonish-bug); - -webkit-mask-image: var(--md-admonition-icon--admonish-bug); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-example) { - border-color: #7c4dff; -} - -:is(.admonish-example) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(124, 77, 255, 0.1); -} -:is(.admonish-example) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #7c4dff; - mask-image: var(--md-admonition-icon--admonish-example); - -webkit-mask-image: var(--md-admonition-icon--admonish-example); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-quote, .admonish-cite) { - border-color: #9e9e9e; -} - -:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(158, 158, 158, 0.1); -} -:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #9e9e9e; - mask-image: var(--md-admonition-icon--admonish-quote); - -webkit-mask-image: var(--md-admonition-icon--admonish-quote); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -.navy :is(.admonition) { - background-color: var(--sidebar-bg); -} - -.ayu :is(.admonition), -.coal :is(.admonition) { - background-color: var(--theme-hover); -} - -.rust :is(.admonition) { - background-color: var(--sidebar-bg); - color: var(--sidebar-fg); -} -.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited { - color: var(--sidebar-fg); -} diff --git a/documentation/old_docs/dev-portal/themes/pagetoc.css b/documentation/old_docs/dev-portal/themes/pagetoc.css deleted file mode 100644 index a68e5b8e21..0000000000 --- a/documentation/old_docs/dev-portal/themes/pagetoc.css +++ /dev/null @@ -1,47 +0,0 @@ -/* src: https://github.com/JorelAli/mdBook-pagetoc */ - -@media only screen and (max-width:1439px) { - .sidetoc { - display: none; - } -} - -@media only screen and (min-width:1440px) { - main { - position: relative; - } - .sidetoc { - margin-left: auto; - margin-right: auto; - /* left: calc(90% + (var(--content-min-width))/4 - 110px); */ - left: 101%; - position: absolute; - font-size: var(--pagetoc-fontsize); - } - .pagetoc { - position: fixed; - width: var(--pagetoc-width); - } - .pagetoc a { - border-left: 1px solid var(--sidebar-bg); - /* color: var(--fg); */ - /* color: var(--sidebar-fg); */ - color: var(--links); - display: block; - padding-bottom: 5px; - padding-top: 5px; - padding-left: 10px; - text-align: left; - text-decoration: none; - font-weight: normal; - background: var(--sidebar-bg); - } - .pagetoc a:hover, - .pagetoc a.active { - background: var(--sidebar-bg); - /* color: var(--sidebar-fg); */ - color: var(--sidebar-active); - font-weight: bold; - font-size: var(--pagetoc-fontsize); - } -} diff --git a/documentation/old_docs/dev-portal/themes/pagetoc.js b/documentation/old_docs/dev-portal/themes/pagetoc.js deleted file mode 100644 index b11052427e..0000000000 --- a/documentation/old_docs/dev-portal/themes/pagetoc.js +++ /dev/null @@ -1,68 +0,0 @@ -// src: https://github.com/JorelAli/mdBook-pagetoc - -// Un-active everything when you click it -Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.addEventHandler("click", function() { - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.classList.remove("active"); - }); - el.classList.add("active"); - }); -}); - -var updateFunction = function() { - - var id; - var elements = document.getElementsByClassName("header"); - Array.prototype.forEach.call(elements, function(el, i) { - if (window.pageYOffset >= el.offsetTop) { - id = el; - } - }); - - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.classList.remove("active"); - }); - - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - if (id.href.localeCompare(el.href) == 0) { - el.classList.add("active"); - } - }); -}; - -// Populate sidebar on load -window.addEventListener('load', function() { - var pagetoc = document.getElementsByClassName("pagetoc")[0]; - var elements = document.getElementsByClassName("header"); - Array.prototype.forEach.call(elements, function(el, i) { - var link = document.createElement("a"); - - // Indent shows hierarchy - var indent = ""; - switch (el.parentElement.tagName) { - case "H2": - indent = "20px"; - break; - case "H3": - indent = "40px"; - break; - case "H4": - indent = "60px"; - break; - default: - break; - } - - link.appendChild(document.createTextNode(el.text)); - link.style.paddingLeft = indent; - link.href = el.href; - pagetoc.appendChild(link); - }); - updateFunction.call(); -}); - - - -// Handle active elements on scroll -window.addEventListener("scroll", updateFunction); diff --git a/documentation/old_docs/docs/.gitignore b/documentation/old_docs/docs/.gitignore deleted file mode 100644 index dbccb28516..0000000000 --- a/documentation/old_docs/docs/.gitignore +++ /dev/null @@ -1,14 +0,0 @@ -# mdbook files -book/ - -# Compiled assets -.sass-cache -_site - -# Developing -todo.md -.idea - -# OSX -.DS_Store - diff --git a/documentation/old_docs/docs/LICENSE b/documentation/old_docs/docs/LICENSE deleted file mode 100644 index 261eeb9e9f..0000000000 --- a/documentation/old_docs/docs/LICENSE +++ /dev/null @@ -1,201 +0,0 @@ - Apache License - Version 2.0, January 2004 - http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - "Contribution" shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, "submitted" - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but not limited to - communication on electronic mailing lists, source code control systems, - and issue tracking systems that are managed by, or on behalf of, the - Licensor for the purpose of discussing and improving the Work, but - excluding communication that is conspicuously marked or otherwise - designated in writing by the copyright owner as "Not a Contribution." - - "Contributor" shall mean Licensor and any individual or Legal Entity - on behalf of whom a Contribution has been received by Licensor and - subsequently incorporated within the Work. - - 2. Grant of Copyright License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - copyright license to reproduce, prepare Derivative Works of, - publicly display, publicly perform, sublicense, and distribute the - Work and such Derivative Works in Source or Object form. - - 3. Grant of Patent License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - (except as stated in this section) patent license to make, have made, - use, offer to sell, sell, import, and otherwise transfer the Work, - where such license applies only to those patent claims licensable - by such Contributor that are necessarily infringed by their - Contribution(s) alone or by combination of their Contribution(s) - with the Work to which such Contribution(s) was submitted. If You - institute patent litigation against any entity (including a - cross-claim or counterclaim in a lawsuit) alleging that the Work - or a Contribution incorporated within the Work constitutes direct - or contributory patent infringement, then any patent licenses - granted to You under this License for that Work shall terminate - as of the date such litigation is filed. - - 4. Redistribution. You may reproduce and distribute copies of the - Work or Derivative Works thereof in any medium, with or without - modifications, and in Source or Object form, provided that You - meet the following conditions: - - (a) You must give any other recipients of the Work or - Derivative Works a copy of this License; and - - (b) You must cause any modified files to carry prominent notices - stating that You changed the files; and - - (c) You must retain, in the Source form of any Derivative Works - that You distribute, all copyright, patent, trademark, and - attribution notices from the Source form of the Work, - excluding those notices that do not pertain to any part of - the Derivative Works; and - - (d) If the Work includes a "NOTICE" text file as part of its - distribution, then any Derivative Works that You distribute must - include a readable copy of the attribution notices contained - within such NOTICE file, excluding those notices that do not - pertain to any part of the Derivative Works, in at least one - of the following places: within a NOTICE text file distributed - as part of the Derivative Works; within the Source form or - documentation, if provided along with the Derivative Works; or, - within a display generated by the Derivative Works, if and - wherever such third-party notices normally appear. The contents - of the NOTICE file are for informational purposes only and - do not modify the License. You may add Your own attribution - notices within Derivative Works that You distribute, alongside - or as an addendum to the NOTICE text from the Work, provided - that such additional attribution notices cannot be construed - as modifying the License. - - You may add Your own copyright statement to Your modifications and - may provide additional or different license terms and conditions - for use, reproduction, or distribution of Your modifications, or - for any such Derivative Works as a whole, provided Your use, - reproduction, and distribution of the Work otherwise complies with - the conditions stated in this License. - - 5. Submission of Contributions. Unless You explicitly state otherwise, - any Contribution intentionally submitted for inclusion in the Work - by You to the Licensor shall be under the terms and conditions of - this License, without any additional terms or conditions. - Notwithstanding the above, nothing herein shall supersede or modify - the terms of any separate license agreement you may have executed - with Licensor regarding such Contributions. - - 6. Trademarks. This License does not grant permission to use the trade - names, trademarks, service marks, or product names of the Licensor, - except as required for reasonable and customary use in describing the - origin of the Work and reproducing the content of the NOTICE file. - - 7. Disclaimer of Warranty. Unless required by applicable law or - agreed to in writing, Licensor provides the Work (and each - Contributor provides its Contributions) on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - implied, including, without limitation, any warranties or conditions - of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A - PARTICULAR PURPOSE. You are solely responsible for determining the - appropriateness of using or redistributing the Work and assume any - risks associated with Your exercise of permissions under this License. - - 8. Limitation of Liability. In no event and under no legal theory, - whether in tort (including negligence), contract, or otherwise, - unless required by applicable law (such as deliberate and grossly - negligent acts) or agreed to in writing, shall any Contributor be - liable to You for damages, including any direct, indirect, special, - incidental, or consequential damages of any character arising as a - result of this License or out of the use or inability to use the - Work (including but not limited to damages for loss of goodwill, - work stoppage, computer failure or malfunction, or any and all - other commercial damages or losses), even if such Contributor - has been advised of the possibility of such damages. - - 9. Accepting Warranty or Additional Liability. While redistributing - the Work or Derivative Works thereof, You may choose to offer, - and charge a fee for, acceptance of support, warranty, indemnity, - or other liability obligations and/or rights consistent with this - License. However, in accepting such obligations, You may act only - on Your own behalf and on Your sole responsibility, not on behalf - of any other Contributor, and only if You agree to indemnify, - defend, and hold each Contributor harmless for any liability - incurred by, or claims asserted against, such Contributor by reason - of your accepting any such warranty or additional liability. - - END OF TERMS AND CONDITIONS - - APPENDIX: How to apply the Apache License to your work. - - To apply the Apache License to your work, attach the following - boilerplate notice, with the fields enclosed by brackets "[]" - replaced with your own identifying information. (Don't include - the brackets!) The text should be enclosed in the appropriate - comment syntax for the file format. We also recommend that a - file or class name and description of purpose be included on the - same "printed page" as the copyright notice for easier - identification within third-party archives. - - Copyright [yyyy] [name of copyright owner] - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. diff --git a/documentation/old_docs/docs/README.md b/documentation/old_docs/docs/README.md deleted file mode 100644 index 472f219c97..0000000000 --- a/documentation/old_docs/docs/README.md +++ /dev/null @@ -1,42 +0,0 @@ -# Nym Documentation -Documentation for the Nym privacy platform built using the [mdBook](https://rust-lang.github.io/mdBook/) docs framework. - -Documentation can be viewed at https://nymtech.net/docs - -## Contributing -Contributions to our documentation are very welcome. Please work on your contribution in either a `feature/` or `chore/` branch from `master` and target your pull request at `master`. - -Since these docs autogenerate command output and import docs from binaries in `target/release` on `build` make sure you're branching off of `master` when making your branch. - -Changes merged to `master` will be autodeployed to the production site. - -### Contributing a new translation -To contribute tranlsations in a new language, please get in touch via [Matrix](https://matrix.to/#/#general:nymtech.chat) or [Discord](https://nymtech.net/go/discord). - -### Variables -There are some variables that are shared across the entire docs site, such as the current latest software version. - -Variables are denoted in the `.md` files wrapped in `{{}}` (e.g `{{wallet_release_version}}`), and are located in the `book.toml` file under the `[preprocessor.variables.variables]` heading. If you are changing something like the software release version, minimum code versions in prerequisites, etc, **check in here first!** - -### Diagrams -Most diagrams are simply ascii. Copies are kept in `/diagrams/` for ease of reproducability. Created using [textik](https://textik.com/#). - -### Importing files and auto-generated command output - -Example files are inserted as per normal with mdbook. - -Some binary command outputs are generated using the [`cmdrun`](https://docs.rs/mdbook-cmdrun/latest/mdbook_cmdrun/) mdbook plugin. - -## Building -When working locally, it is recommended that you use `mdbook serve` to have a local version of the docs served on `localhost:3000`, with hot reloading on any changes made to files in the `src/` directory. - -You can find other commands in the [mdBook CLI tool docs](https://rust-lang.github.io/mdBook/cli/index.html). - -### I tried to edit files in `theme/` and they aren't taking effect / `mdbook serve` causes a looping reload on file changes after changing fields in `[preprocessor.theme]` config - -Looping reload is a known issue with the `mdbook-theme` preprocessor used for the table of contents and layout of these docs. As outlined in the `mdbook-theme` [readme](https://github.com/zjp-CN/mdbook-theme#avoid-repeating-call-on-this-tool-when-mdbook-watch) one way to mitigate this is to set `turn-off = true` under `[preprocessor.theme]`. This means that `mdbook serve` or `mdbook watch` ignores changes to the `theme/` directory, which is the source of the looping reload. If you have changed or commented out this line, reintroduce it to remove the looping reload. If you are trying to edit the theme of the docs and want to apply the change, see [here](https://github.com/zjp-CN/mdbook-theme#avoid-repeating-call-on-this-tool-when-mdbook-watch) for more info on how to remove the block, change the theme, and reintroduce the block. - -### Checking the mdBook version -To check the version of mdBook installed on your system, you can use the `mdbook --version` command. This will print the version number of mdBook installed on your system in the terminal. - -The latest release of the binary of the pre-compiled binaries can be found on [GitHub](https://github.com/rust-lang/mdBook/releases). diff --git a/documentation/old_docs/docs/book.toml b/documentation/old_docs/docs/book.toml deleted file mode 100644 index 9fe3643036..0000000000 --- a/documentation/old_docs/docs/book.toml +++ /dev/null @@ -1,117 +0,0 @@ -[book] -title = "Nym Docs" -authors = ["Max Hampshire, Serinko, Alexia Lorenza Martinel"] -description = "Nym technical documentation" -language = "en" -multilingual = false # for the moment - ideally work on chinese, brazillian portugese, spanish next -src = "src" - -[rust] -edition = "2018" - -################# -# PREPROCESSORS # -################# - -[preprocessor.theme] -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`. -# this is because of a bug in the `mdbook-theme` plugin -turn-off = true - -[preprocessor.admonish] -command = "mdbook-admonish" -assets_version = "3.0.2" # do not edit: managed by `mdbook-admonish install` - -# https://gitlab.com/tglman/mdbook-variables/ -[preprocessor.variables.variables] -minimum_rust_version = "1.66" -wallet_release_version = "1.2.8" -# nym-vpn related variables -nym_vpn_latest_binary_url = "https://github.com/nymtech/nym/releases/tag/nym-vpn-alpha-0.0.3" -nym_vpn_form_url = "https://opnform.com/forms/nymvpn-user-research-at-37c3-yccqko-2" - -[preprocessor.last-changed] -command = "mdbook-last-changed" -renderer = ["html"] - -# used for grabbing output of binary commands for automation https://github.com/FauconFan/mdbook-cmdrun -[preprocessor.cmdrun] - -# more pre-processor plugins to look into from https://github.com/rust-lang/mdBook/wiki/Third-party-plugins & https://lib.rs/keywords/mdbook-preprocessor -# mdbook-i18n - -######### -# BUILD # -######### - -[build] -build-dir = "book" # the directory where the output is placed -create-missing = true # whether or not to create missing pages -use-default-preprocessors = true # use the default preprocessors -extra-watch-dirs = [] # directories to watch for triggering builds - -########## -# OUTPUT # -########## - -[output.html] -theme = "themes" -default-theme = "coal" -preferred-dark-theme = "coal" -curly-quotes = true -copy-fonts = true -no-section-label = false -additional-css = [ - "./themes/custom.css", - "./themes/mdbook-admonish.css", - "./themes/pagetoc.css", -] -additional-js = ["./themes/pagetoc.js"] -git-repository-url = "https://github.com/nymtech/nym/documentation/" -git-repository-icon = "fa-github" -input-404 = "not-found.md" - -[output.html.fold] -enable = true # whether or not to enable section folding -level = 0 # the depth to start folding - -# controlling rust sample code blocks -[output.html.playground] -editable = false # allows editing the source code -copyable = true # include the copy button for copying code snippets -copy-js = true # includes the JavaScript for the code editor -line-numbers = true # displays line numbers for editable code -runnable = true # displays a run button for rust code - -# options for the built in text search -[output.html.search] -enable = true # enables the search feature -limit-results = 30 # maximum number of search results -teaser-word-count = 30 # number of words used for a search result teaser -use-boolean-and = true # multiple search terms must all match -boost-title = 2 # ranking boost factor for matches in headers -boost-hierarchy = 1 # ranking boost factor for matches in page names -boost-paragraph = 1 # ranking boost factor for matches in text -expand = true # partial words will match longer terms -heading-split-level = 3 # link results to heading levels -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" -"/clients/websocket-client.html" = "https://nymtech.net/developers/clients/websocket-client.html" -"/use-apps/blockstream-green" = "https://nymtech.net/developers/clients/socks5/usage.html" -"/use-apps/telegram" = "https://nymtech.net/developers/archive/nym-connect.html#telegram-via-nymconnect" - diff --git a/documentation/old_docs/docs/diagrams/mixnet-traffic-flow.md b/documentation/old_docs/docs/diagrams/mixnet-traffic-flow.md deleted file mode 100644 index 235e047fc0..0000000000 --- a/documentation/old_docs/docs/diagrams/mixnet-traffic-flow.md +++ /dev/null @@ -1,35 +0,0 @@ - - - - +----------+ +----------+ +----------+ - | Mix Node |<-----------> | Mix Node |<----------->| Mix Node | - | Layer 1 | | Layer 2 | | Layer 3 | - +----------+ +----------+ +----------+ - ^ ^ - | | - | | - v v - +--------------+ +-------------------------+ - | Your gateway | | Service / app's gateway | - +--------------+ +-------------------------+ - ^ ^ - | | - | | - | | - | | - v v - +-------------------+ +-------------------+ - | +---------------+ | | +---------------+ | - | | Nym client | | | | Nym Client | | - | +---------------+ | | +---------------+ | - | ^ | | ^ | - | | | | | | - | | | | | | - | | | | | | - | v | | v | - | +---------------+ | | +---------------+ | - | | Your app code | | | | Service Code | | - | +---------------+ | | +---------------+ | - +-------------------+ +-------------------+ - Your Local Machine Service Provider Machine - \ No newline at end of file diff --git a/documentation/old_docs/docs/diagrams/package-retransmission.md b/documentation/old_docs/docs/diagrams/package-retransmission.md deleted file mode 100644 index 7ee9a320de..0000000000 --- a/documentation/old_docs/docs/diagrams/package-retransmission.md +++ /dev/null @@ -1,14 +0,0 @@ - - +-------------------+ +-------------------+ - | +---------------+ | | | Packet lost in transmission - no ack recieved! - | | Nym client | | | |-------------X - | +-------^-------+ |Send 100 packets | | - | | |----------------->| Gateway your | Resend packet +------------------+ etc... - | | | | client is |------------------>| |------------------> - | | | | connected to | | Mix node layer 1 | - | v | Send 100 acks | |<------------------| | - | +---------------+ |<-----------------| | Send ack +------------------+ - | | Your app code | | | | - | +---------------+ | | | - +-------------------+ +-------------------+ - Your Local Machine diff --git a/documentation/old_docs/docs/diagrams/socks-client-flow.md b/documentation/old_docs/docs/diagrams/socks-client-flow.md deleted file mode 100644 index 952061daee..0000000000 --- a/documentation/old_docs/docs/diagrams/socks-client-flow.md +++ /dev/null @@ -1,43 +0,0 @@ - External Systems: - - +--------------------+ - |------>| Monero blockchain | - | +--------------------+ - | +--------------------+ - |------>| Email server | - | +--------------------+ - | +--------------------+ - |------>| RPC endpoint | - | +--------------------+ - | +--------------------+ - |------>| Website | - | +--------------------+ - | +--------------------+ - +----------------------------------+ |------>| etc... | - | Mixnet: | | +--------------------+ - | * Gateway your client is | | - | connected to | +--------------------+ | - | * Mix nodes 1 -> 3 |<---------->| Network requester |<----+ - | * Gateway that network | +--------------------+ - | requester is connected to | - +----------------------------------+ - ^ - | - | - | - | - v - +-------------------+ - | +---------------+ | - | | Nym client | | - | +---------------+ | - | ^ | - | | | - | | | - | | | - | v | - | +---------------+ | - | | Your app code | | - | +---------------+ | - +-------------------+ - Your Local Machine \ No newline at end of file diff --git a/documentation/old_docs/docs/diagrams/templates/local-machine.md b/documentation/old_docs/docs/diagrams/templates/local-machine.md deleted file mode 100644 index fa63a5cbff..0000000000 --- a/documentation/old_docs/docs/diagrams/templates/local-machine.md +++ /dev/null @@ -1,14 +0,0 @@ -+-------------------+ -| +---------------+ | -| | Nym client | | -| +---------------+ | -| ^ | -| | | -| | | -| | | -| v | -| +---------------+ | -| | Your app code | | -| +---------------+ | -+-------------------+ - Your Local Machine \ No newline at end of file diff --git a/documentation/old_docs/docs/diagrams/templates/service-machine.md b/documentation/old_docs/docs/diagrams/templates/service-machine.md deleted file mode 100644 index f9acb9d1e9..0000000000 --- a/documentation/old_docs/docs/diagrams/templates/service-machine.md +++ /dev/null @@ -1,15 +0,0 @@ -+-------------------+ -| +---------------+ | -| | Nym client | | -| +---------------+ | -| ^ | -| | | -| | | -| | | -| v | -| +---------------+ | -| | Service code | | -| +---------------+ | -+-------------------+ - Service Machine - \ No newline at end of file diff --git a/documentation/old_docs/docs/last-changed.css b/documentation/old_docs/docs/last-changed.css deleted file mode 100644 index 0c4228de32..0000000000 --- a/documentation/old_docs/docs/last-changed.css +++ /dev/null @@ -1,6 +0,0 @@ -footer { - font-size: 0.8em; - text-align: center; - border-top: 1px solid black; - padding: 5px 0; - } \ No newline at end of file diff --git a/documentation/old_docs/docs/src/SUMMARY.md b/documentation/old_docs/docs/src/SUMMARY.md deleted file mode 100644 index 6ca7e2d156..0000000000 --- a/documentation/old_docs/docs/src/SUMMARY.md +++ /dev/null @@ -1,45 +0,0 @@ -# -# Summary -[Introduction](introduction.md) - -# Architecture -- [Network Overview](architecture/network-overview.md) -- [Nym vs Other Systems](architecture/nym-vs-others.md) -- [Mixnet Traffic Flow](architecture/traffic-flow.md) -- [Addressing System](architecture/addressing-system.md) - -# Binaries -- [Pre-built Binaries](binaries/pre-built-binaries.md) - - [Binary Initialisation and Configuration](binaries/init-and-config.md) -- [Building from Source](binaries/building-nym.md) - -# Nodes -- [Node Types (Previously Setup Guides)](nodes/overview.md) - -# Wallet -- [Desktop Wallet](wallet/desktop-wallet.md) -- [CLI Wallet](wallet/cli-wallet.md) - -# Explorers -- [Mixnet Explorer](explorers/mixnet-explorer.md) - -# Nyx Blockchain -- [Interacting with Nyx Chain and Smart Contracts](nyx/interacting-with-chain.md) -- [Smart Contracts](nyx/smart-contracts.md) - - [Mixnet Contract](nyx/mixnet-contract.md) - - [Vesting Contract](nyx/vesting-contract.md) -- [RPC Nodes](nyx/rpc-node.md) -- [Ledger Live Support](nyx/ledger-live.md) - -# Coconut -- [Coconut](coconut.md) -- [Bandwidth Credentials](bandwidth-credentials.md) - -# Tools -- [NymCLI](tools/nym-cli.md) - ---- -# Misc. -- [Code of Conduct](coc.md) -- [Licensing](licensing.md) ---- diff --git a/documentation/old_docs/docs/src/architecture/addressing-system.md b/documentation/old_docs/docs/src/architecture/addressing-system.md deleted file mode 100644 index 3fbbdd89b4..0000000000 --- a/documentation/old_docs/docs/src/architecture/addressing-system.md +++ /dev/null @@ -1,17 +0,0 @@ -# Addressing System - -When a Nym client is initalised, it generates and stores its own public/private keypair locally. When the client starts, it automatically connects to the Nym network and finds out what Nym infrastructure exists. It then chooses and connects to a specific Gateway node via websocket. - -All apps in the Nym network therefore have an address, in the format: - -``` -user-identity-key.user-encryption-key@gateway-identity-key -``` - -Which in practice, looks something like this: - -``` -DguTcdkWWtDyUFLvQxRdcA8qZhardhE1ZXy1YCC7Zfmq.Dxreouj5RhQqMb3ZaAxgXFdGkmfbDKwk457FdeHGKmQQ@4kjgWmFU1tcGAZYRZR57yFuVAexjLbJ5M7jvo3X5Hkcf -``` - -This is obviously not very user-friendly and the moment, and will be developed on in the coming months. \ No newline at end of file diff --git a/documentation/old_docs/docs/src/architecture/network-overview.md b/documentation/old_docs/docs/src/architecture/network-overview.md deleted file mode 100644 index 69c19aaa03..0000000000 --- a/documentation/old_docs/docs/src/architecture/network-overview.md +++ /dev/null @@ -1,49 +0,0 @@ -# Network Overview - -Nym is a privacy platform. It provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous access control using blinded, re-randomizable, decentralized credentials. Our goal is to allow developers to build new applications, or upgrade existing apps, with privacy features unavailable in other systems. - -The Nym platform knits together several privacy technologies, integrating them into a system of cooperating networked nodes. - -At a high level, our technologies include: - -* a **mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the **Loopix** design. -* a privacy enhancing signature scheme called **Coconut**. Coconut allows a shift in thinking about resource access control, from an identity-based paradigm based on _who you are_ to a privacy-preserving paradigm based on _right to use_. -* **Sphinx**, a way of transmitting armoured, layer-encrypted information packets which are indistinguishable from each other at a binary level. -* the **Nyx** blockchain, a general-purpose CosmWasm-enabled smart contract platform, and the home of the smart contracts which keep track of the mixnet. - -The most important thing to note is that these technologies ensure privacy at two different levels of the stack: **network data transmission**, and **transactions**. - -Here's an overview diagram of the different types of nodes making up the network: - -![Nym Platform](../images/nym-platform-dark.png) - -Developers can think of the network as being comprised of **infrastructure nodes** and **clients** for interacting with this infrastructure via **P**rivacy-**e**nhanced **app**lications (PEApps). - -## Mixnet Infrastructure -The mixnet - the different pieces of software that your traffic will pass through when using an privacy-enhanced app (PEApp) - is made up of several different types of nodes: - -* **Mix Nodes** provide network security for network content _and_ metadata, making it impossible to see who is communicating with who, by performing packet-mixing on traffic travelling through the network. - -* **Gateways** act as message storage for clients which may go offline and come back online again, and defend against denial of service attacks. The default gateway implementation included in the Nym platform code holds packets for later retrieval. For many applications (such as simple chat), this is usable out of the box, as it provides a place that potentially offline clients can retrieve packets from. The access token allows clients to pull messages from the gateway node. - -* **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the network requester binary. - -* **Nyx Blockchain Validators** secure the network with proof-of-stake Sybil defenses, determine which nodes are included within the network, and work together to create Coconut threshold credentials which provide anonymous access to data and resources. They also produce blocks and secure the Nyx Blockchain. Initially, this chain was used only to house the CosmWasm smart contracts keeping track of Nym's network topology, token vesting contracts, and the `NYM` token itself. In recent months, we've decided to expand the role of Nyx and instead expand its role by making it an open smart contract platform for anyone to upload CosmWasm smart contracts to. Validators also provide privacy-enhanced credentials based on the testimony of a set of decentralized, blockchain-based issuing authorities. Nym validators use the [Coconut](https://arxiv.org/abs/1802.07344) [signature scheme](https://en.wikipedia.org/wiki/Digital_signature) to issue credentials. This allows privacy apps to generate anonymous resource claims through decentralised authorities, then use them with Service Providers. - -## Privacy-enhanced applications (PEApps) -PEApps use a Nym client to connect to the network in order to get the available Network Topology for traffic routing, and send/receive packets to other users and services. Clients, in order to send traffic through the mixnet, connect to gateways. Since applications may go online and offline, a client's gateway provides a sort of mailbox where apps can receive their messages. - -Nym clients connect to gateways. Messages are automatically piped to connected clients and deleted from the gateway's disk storage. If a client is offline when a message arrives, it will be stored for later retrieval. When the client connects, all messages will be delivered, and deleted from the gateway's disk. - -When it starts up, a client registers itself with a gateway, and the gateway returns an access token. The access token plus the gateway's IP can then be used as a form of addressing for delivering packets. - -There are two basic kinds of privacy enhanced applications: - -* **Client apps** running on mobile or desktop devices. These will typically expose a user interface (UI) to a human user. These might be existing apps such as crypto wallets that communicate with Nym via our SOCKS5 proxy, or entirely new apps. -* **Service Providers**, which will usually run on a server, and take actions on behalf of users without knowing who they are. - -Service Providers (SPs) may interact with external systems on behalf of a user. For example, an SP might submit a Bitcoin, Ethereum or Cosmos transaction, proxy a network request, talk to a chat server, or provide anonymous access to a medical system such as a [privacy-friendly coronavirus tracker](https://constructiveproof.com/posts/2020-04-24-coronavirus-tracking-app-privacy/). - -There is also a special category of Service Provider, namely SPs that do not visibly interact with any external systems. You might think of these as crypto-utopiapps: they're doing something, but it's not possible from outside to say with any certainty what their function is, or who is interacting with them. - -All apps talk with gateways using Sphinx packets and a small set of simple control messages. These messages are sent to gateways over websockets. Each app client has a long-lived relationship with its gateway; Nym defines messages for clients registering and authenticating with gateways, as well as sending encrypted Sphinx packets. diff --git a/documentation/old_docs/docs/src/architecture/network-rewards.md b/documentation/old_docs/docs/src/architecture/network-rewards.md deleted file mode 100644 index 3f6d2bb93a..0000000000 --- a/documentation/old_docs/docs/src/architecture/network-rewards.md +++ /dev/null @@ -1,45 +0,0 @@ -# Network Rewards - -Node operator and delegator rewards are determined according to the principles laid out in the section 6 of [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf). - -Below is a TLDR of the variables and formulas involved in calculating these rewards per epoch. The initial reward pool contains 250 million NYM, leaving a circulating supply of 750 million NYM. - -|Symbol|Definition| -|---|---| -||global share of rewards available, starts at 2% of the reward pool. -||node reward for mixnode `i`. -||ratio of total node stake (node bond + all delegations) to the token circulating supply. -||ratio of stake operator has pledged to their node to the token circulating supply. -||fraction of total effort undertaken by node `i`. -||number of nodes stakeholders are incentivised to create, set by the validators, a matter of governance. Currently determined by the reward set size. -||Sybil attack resistance parameter - the higher this parameter is set the stronger the reduction in competitivness gets for a Sybil attacker. -||declared profit margin of operator `i`. -||uptime of node `i`, scaled to 0 - 1, for the rewarding epoch -||cost of operating node `i` for the duration of the rewarding eopoch. - -Node reward for node `i` is determined as: - - - - -where: - - - - -and - - - - -Operator of node `i` is credited with the following amount: - - - - -Delegate with stake `s` recieves: - - - - -where `s'` is stake `s` scaled over total token circulating supply. diff --git a/documentation/old_docs/docs/src/architecture/nym-vs-others.md b/documentation/old_docs/docs/src/architecture/nym-vs-others.md deleted file mode 100644 index de654675ed..0000000000 --- a/documentation/old_docs/docs/src/architecture/nym-vs-others.md +++ /dev/null @@ -1,40 +0,0 @@ -# Nym vs Other Systems - -### Why use Nym: Understanding the Significance of Nym - -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. - -> 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 - -The most popular network-level privacy solution currently is the VPN (virtual private network), which provides network-level protection via an encrypted tunnel between a user’s computer and one run by a VPN provider. VPNs are often misconfigured, however, and even when configured correctly, don’t offer real privacy or adequate resistance to censorship. - -VPN providers can also fully observe all network traffic between users and the public internet, knowing exactly what services its users are accessing at a given time. The user must trust that the VPN provider is not using their information in a malicious manner or keeping logs. - -The Nym mixnet is an anonymous overlay network that provides strong network-level anonymity, even in the face of powerful systems capable of passively monitoring the entire network. The mixnet is decentralized, with no trusted third parties, and so does not require a trusted provider like a VPN. More importantly, Nym provides superior privacy to VPNs and can support high-quality of service and low latency through incentives. - -### Nym vs Tor - -Tor is the best-known anonymous overlay network today. Unlike VPNs, Tor provides a ‘circuit’ of three hops that provides better privacy than single-node VPNs, so any single node in Tor can’t deanonymize traffic. Tor’s onion-routing encrypts traffic between each hop so that only the final hop, the Tor ‘exit node’, can decrypt the package. - -However, Tor’s anonymity properties can be defeated by an entity that is capable of monitoring the entire network’s ‘entry’ and ‘exit’ nodes, because while onion-routing encrypts traffic, Tor does not add timing obfuscation or use decoy traffic to obfuscate the traffic patterns which can be used to deanonymize users. Although these kinds of attacks were thought to be unrealistic when Tor was invented, in the era of powerful government agencies and private companies, these kinds of attacks are a real threat. Tor’s design is also based on a centralized directory authority for routing. - -While Tor may be the best existing solution for general-purpose web-browsing that accesses the entire internet, it is inarguable that mixnets are better than Tor for message-passing systems such as cryptocurrency transactions and secure messaging, and we believe well designed incentives can also enable the use of Nym as a general purpose decentralized VPN. The Nym mixnet provides superior privacy by making packets indistinguishable from each other, adding cover traffic, and providing timing obfuscation. Unlike both previous mixnet designs and Tor, the Nym mixnet decentralizes its shared operations using blockchain technology and uses incentives to both scale and provide censorship-resistance. - -### Nym vs I2P - -I2P (‘Invisible Internet Project’) replaces Tor’s directory authority with a distributed hash table for routing. How to design a secure and private distributed hash table is still an open research question, and I2P is open to a number of attacks that isolate, misdirect, or deanonymize users. Like Tor, I2P is based on ‘security by obscurity’, where it is assumed that no adversary can watch the entire network. While security by obscurity may have been cutting-edge at the turn of the millennium, such an approach is rapidly showing its age. - -Nym’s cutting-edge mixnet design guarantees network anonymity and resistance to surveillance even in the face of powerful deanonymizing attacks. Unlike I2P, Nym adds decoy traffic and timing obfuscation. Rather than a centralized directory authority or distributed hash table, Nym uses blockchain technology and economic incentives to decentralize its network.The Nym mixnet can anonymize metadata even against government agencies or private companies who can monitor network links and observe the incoming and outgoing traffic of all clients and servers. - -### Nym vs Facebook Connect - -The Nym credential system decentralizes the functions of systems like Facebook Connect while adding privacy. Personal data has become a toxic asset, even to companies who base their entire business around it, as evidenced by the hack of Facebook’s OAuth identity system in 2018 and the subsequent release of the data of 50 million users. - -Unlike Facebook Connect and similar OAuth-based services like Sign in with Google, traditional usernames and passwords, or even public/private key pairs, Nym credentials allow users to authenticate and authorize data sharing without unwillingly revealing any information to a third party. There is no central third party in charge of the credentials, and users remain totally in control of their own data, disclosing it only to those who they want to. A user can store their data wherever they want (including on their own devices), and unlike alternatives like W3C’s DIDs, a user does not store anything on the blockchain, offering better privacy. diff --git a/documentation/old_docs/docs/src/architecture/traffic-flow.md b/documentation/old_docs/docs/src/architecture/traffic-flow.md deleted file mode 100644 index 863a03f577..0000000000 --- a/documentation/old_docs/docs/src/architecture/traffic-flow.md +++ /dev/null @@ -1,104 +0,0 @@ -# Mixnet Traffic Flow - -## Technical Motivations -When you send data across the internet, it can be recorded by a wide range of observers: your ISP, internet infrastructure providers, large tech companies, and governments. - -Even if the content of a network request is encrypted, observers can still see that data was transmitted, its size, frequency of transmission, and gather metadata from unencrypted parts of the data (such as IP routing information). Adversaries may then combine all the leaked information to probabilistically de-anonymize users. - -The Nym mixnet provides very strong security guarantees against this sort of surveillance. It _packetises_ and _mixes_ together IP traffic from many users inside the _mixnet_. - -> If you're into comparisons, the Nym mixnet is conceptually similar to other systems such as Tor, but provides improved protections against end-to-end timing attacks which can de-anonymize users. When Tor was first fielded, in 2002, those kinds of attacks were regarded as science fiction. But the future is now here. - -## Mixnet Traffic Flow -The Nym mixnet re-orders encrypted, indistinguishable [Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) packets as they travel through the gateways and mix nodes. - -Traffic to send through the mixnet is broken up into uniformly-sized packets, encrypted in the Sphinx packet format according to the route the packet will take, and sent through the mixnet to be mixed among other real traffic and fake - but identical - 'dummy traffic'. - -At each 'hop' (i.e. as a packet is forwarded from one node in the sequence to another) a layer of decryption is removed from the Sphinx packet, revealing the address of the next hop, and another Sphinx packet. The packet is then held by the node for a variable amount of time, before being forwarded on to the next node in the route. - -Traffic always travels through the nodes of the mixnet like such: - -``` - - +----------+ +----------+ +----------+ - | Mix Node |<-----------> | Mix Node |<----------->| Mix Node | - | Layer 1 | | Layer 2 | | Layer 3 | - +----------+ +----------+ +----------+ - ^ ^ - | | - | | - v v - +--------------+ +-----------------+ - | Your gateway | | Service gateway | - +--------------+ +-----------------+ - ^ ^ - | | - | | - v v - +-------------------+ +-------------------+ - | +---------------+ | | +---------------+ | - | | Nym client | | | | Nym Client | | - | +---------------+ | | +---------------+ | - | ^ | | ^ | - | | | | | | - | | | | | | - | v | | v | - | +---------------+ | | +---------------+ | - | | Your app code | | | | Service Code | | - | +---------------+ | | +---------------+ | - +-------------------+ +-------------------+ - Your Local Machine** Service Provider Machine** - - -** note that depending on the technical setup, the Nym client running on these machines may -be either a seperate process or embedded in the same process as the app code via one of our SDKs. - -``` - - -From your Nym client, your encrypted traffic is sent to: -* the gateway your client has registered with, -* a mix node on layer 1 of the Mixnet, -* a mix node on layer 2 of the Mixnet, -* a mix node on layer 3 of the Mixnet, -* the recipient's gateway, which forwards it finally to... -* the recipient's Nym client, which communicates with an application. - -> If the recipient's Nym client is offline at the time then the packets will be held by the Gateway their Nym client has registered with until they come online. - -Whatever is on the 'other side' of the mixnet from your client, all traffic will travel this way through the mixnet. If you are sending traffic to a service external to Nym (such as a chat application's servers) then your traffic will be sent from the recieving Nym client to an application that will proxy it 'out' of the mixnet to these servers, shielding your metadata from them. P2P (peer-to-peer) applications, unlike the majority of apps, might want to keep all of their traffic entirely 'within' the mixnet, as they don't have to necessarily make outbound network requests to application servers. They would simply have their local application code communicate with their Nym clients, and not forward traffic anywhere 'outside' of the mixnet. - -## Acks & Package Retransmission -Whenever a hop is completed, the receiving node will send back an acknowledgement ('ack') so that the sending node knows that the packet was received. If it does not receive an ack after sending, it will resend the packet, as it assumes that the packet was dropped for some reason. This is done under the hood by the binaries themselves, and is never something that developers and node operators have to worry about dealing with themselves. - -Packet retransmission means that if a client sends 100 packets to a gateway, but only receives an acknowledgement ('ack') for 95 of them, it will resend those 5 packets to the gateway again, to make sure that all packets are received. All nodes in the mixnet support packet retransmission. - -``` - - +-------------------+ +-------------------+ - | +---------------+ | | | Packet lost in transmission - no ack recieved! - | | Nym client | | | |-----------------? - | +-------^-------+ |Send 100 packets | | - | | |----------------->| Gateway your | Resend packet +------------------+ etc... - | | | | client is |------------------>| |------------------> - | | | | connected to | | Mix node layer 1 | - | v | Send 100 acks | |<------------------| | - | +---------------+ |<-----------------| | Send ack +------------------+ - | | Your app code | | | | - | +---------------+ | | | - +-------------------+ +-------------------+ - Your Local Machine - -``` - -## Private Replies using SURBs -SURBs ('Single Use Reply Blocks') allow apps to reply to other apps anonymously. - -It will often be the case that a client app wants to interact with a service of some kind, or a P2P application on someone else's machine. It sort of defeats the purpose of the whole system if your client app needs to reveal its own gateway public key and client public key in order to get a response from the service/app. - -Luckily, SURBs allow for anonymous replies. A SURB is a layer encrypted set of Sphinx headers detailing a reply path ending in the original app's address. SURBs are encrypted by the client, so the recieving service/app can attach its response and send back the resulting Sphinx packet, but it **never has sight of who it is replying to**. - -MultiSURBs were implemented in `v1.1.4`. Clients, when sending a message to another client, attach a bundle of SURBs which can be used by the receiver to construct large anonymous replies, such as files. If a reply is too large still (i.e. it would use more SURBs than sent with the original message), the receiver will use a SURB to ask the sender for more SURBs. - -What this means in practice is that files can now be sent via anonymous replies! - diff --git a/documentation/old_docs/docs/src/bandwidth-credentials.md b/documentation/old_docs/docs/src/bandwidth-credentials.md deleted file mode 100644 index c3d61e4797..0000000000 --- a/documentation/old_docs/docs/src/bandwidth-credentials.md +++ /dev/null @@ -1,80 +0,0 @@ -# Bandwidth Credentials - -You can now try using Nym Bandwidth Credentials in our [Sandbox testnet environment](https://sandbox-explorer.nymtech.net). - -Create a `sandbox.env` file with the following details: - -``` -CONFIGURED=true - -NETWORK_NAME=sandbox - -RUST_LOG=info -RUST_BACKTRACE=1 - -BECH32_PREFIX=nymt -MIX_DENOM=unymt -MIX_DENOM_DISPLAY=nymt -STAKE_DENOM=unyxt -STAKE_DENOM_DISPLAY=nyxt -DENOMS_EXPONENT=6 - -REWARDING_VALIDATOR_ADDRESS="nymt1mxuweurc066kprnngtm8zmvam7m2nw26yatpmv" -MIXNET_CONTRACT_ADDRESS="nymt1dlsvvgey26ernlj0sq2afjluh3qd4ap0k9eerekfkw5algqrwqksaf2qf7" -VESTING_CONTRACT_ADDRESS="nymt19g9xuqrvz2frv905v3fc7puryfypluhg383q9zwsmedrlqekfgys62ykm4" -MULTISIG_CONTRACT_ADDRESS="nymt142dkm8xe9f0ytyarp7ww4kvclva65705jphxsk9exn3nqdsm8jkqnp06ac" -COCONUT_BANDWIDTH_CONTRACT_ADDRESS="nymt1ty0frysegskh6ndm3v96z5xdq66qzcu0aw7xcxlgp54jg0mjwlgqplc6v0" -COCONUT_DKG_CONTRACT_ADDRESS="nymt1gwk6muhmzeuxje7df7rjvqwl2vex0kj4t2hwuzmyx5k62kfusu5qk4k5z4" -GROUP_CONTRACT_ADDRESS="nymt14ry36mwauycz08v8ndcujghxz4hmua5epxcn0mamlr3suqe0l2qsqx5ya2" - -STATISTICS_SERVICE_DOMAIN_ADDRESS="http://0.0.0.0" -NYXD="https://rpc.sandbox.nymtech.net" -NYM_API="https://sandbox-validator1-api.nymtech.net/api" -``` - -Create an account on Sandbox using the nym-cli: - -```./nym-cli --config-env-file sandbox.env account create``` - -You will need `nymt` funds sent to this account. Get in touch via Nym [Telegram](https://t.me/nymchan) or [Discord](https://nymtech.net/go/discord) and we can send them to you. - -Next, you init the nym-client with the enabled credentials mode set to true: - -```./nym-client --config-env-file sandbox.env init --id --enabled-credentials-mode true``` - -Using the new credentials binary, purchase some credentials for the client. The recovery directory is a directory where the credentials will be temporarily stored in case the request fails. - -```./credential --config-env-file sandbox.env run --client-home-directory --nyxd-url https://rpc.sandbox.nymtech.net --mnemonic "" --amount 50 --recovery-dir ``` - -You can redeem this now by running the nym-client, in enabled credentials mode: - -```./nym-client --config-env-file sandbox.env run --id --enabled-credentials-mode true``` - -Run the network requester which can be downloaded [here](https://github.com/nymtech/nym/releases/download/nym-binaries-v1.1.9/nym-network-requester) - - `./nym-network-requester run` - -> You need to run this version for now, as the `nym-client` functionality was recently integrated into the `network-requester` binary but for the moment cannot support coconut credentials natively. - -Now time to init the socks5 client: - -`./nym-socks5-client --config-env-file sandbox.env init --id --provider --enabled-credentials-mode true` - -Purchase credentials for this now too: - -`./credential --config-env-file sandbox.env run --client-home-directory --nyxd-url https://rpc.sandbox.nymtech.net --mnemonic "" --amount 100 --recovery-dir ` - -Run the socks5 client: - -`./nym-socks5-client --config-env-file sandbox.env run --id --enabled-credentials-mode true` - -NOTE - -You can check to see if credentials have been correctly purchased by installing sqlite, and proceeding to do the following: - -``` -sqlite3 ~/.nym/socks5-clients//data/credentials_database.db -select * from coconut_credentials; -``` - -Keep in mind 1GB = 1NYM diff --git a/documentation/old_docs/docs/src/binaries/building-nym.md b/documentation/old_docs/docs/src/binaries/building-nym.md deleted file mode 100644 index 5b713c3f6d..0000000000 --- a/documentation/old_docs/docs/src/binaries/building-nym.md +++ /dev/null @@ -1,70 +0,0 @@ -# Building from Source - -> Nym runs on Mac OS X, Linux, and Windows. All nodes **except the Desktop Wallet and NymConnect** on Windows should be considered experimental - it works fine if you're an app developer but isn't recommended for running nodes. - -## Building Nym -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](https://nymtech.net/operators/nodes/validator-setup.html) instead.** - -## Prerequisites -- Debian/Ubuntu: `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq`, `git` - -``` -apt install pkg-config build-essential libssl-dev curl jq git -``` - -- Arch/Manjaro: `base-devel` - -``` -pacman -S base-devel -``` - -- Mac OS X: `pkg-config` , `brew`, `openss1`, `protobuf`, `curl`, `git` -Running the following the script installs Homebrew and the above dependencies: - -``` -/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" -``` - -- `Rust & cargo >= {{minimum_rust_version}}` - -We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old. - -If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms. - -## Download and build Nym binaries -The following commands will compile binaries into the `nym/target/release` directory: - -```sh -rustup update -git clone https://github.com/nymtech/nym.git -cd nym - -git reset --hard # in case you made any changes on your branch -git pull # in case you've checked it out before - -git checkout master # master branch has the latest release version: `develop` will most likely be incompatible with deployed public networks - -cargo build --release # build your binaries with **mainnet** configuration -``` - -Quite a bit of stuff gets built. The key working parts are: - -* [Nym Node](https://nymtech.net/operators/nodes/nym-node.html): `nym-node` -* [Validator](https://nymtech.net/operators/nodes/validator-setup.html) -* [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](https://nymtech.net/operators/nodes/nym-api.html): `nym-api` -* [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](https://nymtech.net/docs/wallet/desktop-wallet.html) -* [Network Explorer UI](https://nymtech.net/docs/explorers/mixnet-explorer.html) - -> 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/old_docs/docs/src/binaries/init-and-config.md b/documentation/old_docs/docs/src/binaries/init-and-config.md deleted file mode 100644 index 7c519a5889..0000000000 --- a/documentation/old_docs/docs/src/binaries/init-and-config.md +++ /dev/null @@ -1,20 +0,0 @@ -# Binary Initialisation and Configuration - -All Nym binaries must first be made executable and initialised with `init` before being `run`. - -To make a binary executable, open terminal in the same directory and run: - -```sh -chmod +x -# for example: chmod +x nym-mixnode -``` - -The `init` command is usually where you pass flags specifying configuration arguments such as the gateway you wish to communicate with, the ports you wish your binary to listen on, etc. - -The `init` command will also create the necessary keypairs and configuration files at `~/.nym///` if these files do not already exist. **It will not overwrite existing keypairs if they are present.** - -You can reconfigure your binaries at any time by editing the config file located at `~/.nym///config/config.toml` and restarting the binary process. - -Once you have run `init`, you can start your binary with the `run` command, usually only accompanied by the `id` of the binary that you specified. - -This `id` is **never** transmitted over the network, and is used to select which local config and key files to use for startup. diff --git a/documentation/old_docs/docs/src/binaries/pre-built-binaries.md b/documentation/old_docs/docs/src/binaries/pre-built-binaries.md deleted file mode 100644 index 269c26276c..0000000000 --- a/documentation/old_docs/docs/src/binaries/pre-built-binaries.md +++ /dev/null @@ -1,6 +0,0 @@ -# Pre-built Binaries - -The [Github releases page](https://github.com/nymtech/nym/releases) has pre-built binaries which should work on Ubuntu 20.04 and other Debian-based systems, but at this stage cannot be guaranteed to work everywhere. - -If the pre-built binaries don't work or are unavailable for your system, you will need to build the platform yourself. - diff --git a/documentation/old_docs/docs/src/binaries/version-compatiblity.md b/documentation/old_docs/docs/src/binaries/version-compatiblity.md deleted file mode 100644 index e96a68e3ce..0000000000 --- a/documentation/old_docs/docs/src/binaries/version-compatiblity.md +++ /dev/null @@ -1,40 +0,0 @@ - - -# Version Compatibility Table - -There are numerous components to Nym which are released independently of one another aside from when breaking changes occur in the [core platform code](https://github.com/nymtech/nym/) - mix nodes, gateways, network requesters, and clients. - -Whilst in general it recommended to be running the most recent version of any software, if you cannot do that for whatever reason this table will tell you which versions of different components are mutually compatible with which platform code releases. - - -| Core Platform | SDK | Wallet | NymConnect | Network Explorer | Mixnet contract | Vesting contract | -| ---------------- | ------------- | --------------- | --------------- | ---------------- | --------------- | ---------------- | -| 1.1.13 - 1.1.14* | 1.1.7 | 1.1.12 - 1.1.13 | 1.1.12 - 1.1.13 | 1.1.2 | 1.2.0 - 1.3.0 | 1.2.0 - 1.3.0 | -| 1.1.1 - 1.1.12 | 1.1.4 - 1.1.7 | 1.1.0 - 1.1.12 | 1.1.1 - 1.1.12 | 1.1.0 - 1.1.2 | 1.1.0 - 1.1.3 | 1.1.0 - 1.1.3 | -| 1.1.0 - 1.1.1 | 1.1.4 | 1.1.0 | 1.1.0 - 1.1.1 | 1.1.0 | 1.1.0 | 1.1.0 | -| 1.1.0 | x | 1.1.0 | 1.1.0 | 1.1.0 | 1.1.0 | 1.1.0 | - -`*` the `nym-mixnode` binary is currently one point ahead of the main platform release version - -> There are seperate changelogs for [`NymConnect`](https://github.com/nymtech/nym/blob/release/{{platform_release_version}}/nym-connect/CHANGELOG.md) and the [`Desktop Wallet`](https://github.com/nymtech/nym/blob/release/{{platform_release_version}}/nym-wallet/CHANGELOG.md). The changelog referenced below is for the core platform code. - -| Platform release changelog | -| ---------------------------------------------------------------------------------------- | -| 1.1.14 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.14/CHANGELOG.md)) | -| 1.1.13 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.13/CHANGELOG.md)) | -| 1.1.12 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.12/CHANGELOG.md)) | -| 1.1.11 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.11/CHANGELOG.md)) | -| 1.1.10 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.10/CHANGELOG.md)) | -| 1.1.9 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.9/CHANGELOG.md)) | -| 1.1.8 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.8/CHANGELOG.md)) | -| 1.1.7 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.7/CHANGELOG.md)) | -| 1.1.6 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.6/CHANGELOG.md)) | -| 1.1.5 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.5/CHANGELOG.md)) | -| 1.1.4 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.4/CHANGELOG.md)) | -| 1.1.3 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.3/CHANGELOG.md)) | -| 1.1.2 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.2/CHANGELOG.md)) | -| 1.1.1 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.1/CHANGELOG.md)) | -| 1.1.0 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.0/CHANGELOG.md)) | -| 1.0.2 ([CHANGELOG](https://github.com/nymtech/nym/blob/nym-binaries-1.0.2/CHANGELOG.md)) | -| 1.0.1 ([CHANGELOG](https://github.com/nymtech/nym/blob/nym-binaries-1.0.1/CHANGELOG.md)) | -| 1.0.0 ([CHANGELOG](https://github.com/nymtech/nym/blob/nym-binaries-1.0.0/CHANGELOG.md)) | diff --git a/documentation/old_docs/docs/src/coconut.md b/documentation/old_docs/docs/src/coconut.md deleted file mode 100644 index 0eb9f654c5..0000000000 --- a/documentation/old_docs/docs/src/coconut.md +++ /dev/null @@ -1,60 +0,0 @@ -# Coconut - -> Coconut is in active development - stay tuned for code and integration examples - -Coconut is a cryptographic signature scheme that produces privacy-enhanced credentials. It lets application programmers who are concerned with resource access control to think and code in a new way. - -Most of the time, when we build system security, we think of _who_ questions: - -- Has Alice identified herself (authentication)? -- Is Alice allowed to take a specific action (authorisation)? - -Coconut fundamentally changes these questions. Rather than asking _who_ a user is, it allows application designers to ask different questions, mostly centered around questions of _rights_: - -- Does the entity taking this action have a right to do X? - -This allows a different kind of security. Many of the computer systems we talk to every day don't need to know _who we are_, they only need to know if we have a _right to use_ the system. Coconut allows signing authorities and validators to work together to determine whether a given private key holder has a right to take an action. The credentials are generated cooperatively by decentralised, trustless systems. - -Once the credentials are generated, they can be _re-randomized:_ entirely new credentials, which no one has ever seen before, can be presented to service providers, and magically validated without being linkable back to the credential originally given out by validators. - -These properties allow Coconut credentials to act as something like a decentralized and fully private version of OAuth credentials, or like cryptographic bearer tokens generated by decentralised systems. The tokens can be mutated so that they are not traceable, but still verified with the original permissions intact. - -Users present cryptographic claims encoded inside the credentials to get secure access to resources despite the systems verifying credential usage not being able to know who they are. - -### Re-randomisation vs pseudonymity - -We stand on the shoulders of giants. Ten years ago, Bitcoin showed the way forward by allowing people to control resource access without recourse to _who_ questions. Rather, in Bitcoin and succeeding blockchains, a private key proves a _right to use_. - -But as we can now see, private keys in blockchain systems act only as a minor barrier to finding out _who_ is accessing resources. A Bitcoin or Ethereum private key is effectively a long-lived pseudonym which is easily traceable through successive transactions. - -Coconut allows us to build truly private systems rather than pseudonymous ones. - -### How does Coconut work? - -Just like normal credentials, Nym's Coconut credentials can be signed with a secret key and later verified by anybody with the correct public key. But Nym credentials have additional superpowers when compared to "normal" signature schemes like RSA or DSA. - -Specifically, Coconut is a blinded, re-randomizable, selective disclosure threshold credential signature scheme. That's quite a mouthful, so let's break it down into its component parts. - -Let's say you have a `message` with the content `This credential controls X` in hand. In addition to the normal `sign(message, secretKey)` and `verify(message, publicKey)` functions present in other signature schemes, Coconut adds the following: - -1. _[Blind signatures](https://en.wikipedia.org/wiki/Blind_signature)_ - disguises message content so that the signer can't see what they're signing. This defends users against signers: the entity that signed can't identify the user who created a given credential, since they've never seen the message they're signing before it's been _blinded_ (turned into gobbledygook). Coconut uses zero-knowledge proofs so that the signer can sign confidently without seeing the unblinded content of the message. - -2. _Re-randomizable signatures_ - take a signature, and generate a brand new signature that is valid for the same underlying message `This credential controls X`. The new bitstring in the re-randomized signature is equivalent to the original signature but not linkable to it. So a user can "show" a credential multiple times, and each time it appears to be a new credential, which is unlinkable to any previous "show". But the underlying content of the re-randomized credential is the same (including for things like double-spend protection). This once again protects the user against the signer, because the signer can't trace the signed message that they gave back to the user when it is presented. It also protects the user against the relying party that accepts the signed credential. The user can show re-randomized credentials repeatedly, and although the underlying message is the same in all cases, there's no way of tracking them by watching the user present the same credential multiple times. - -3. _Selective disclosure of attributes_ - allows someone with the public key to verify some, but not all, parts of a message. So you could for instance selectively reveal parts of a signed message to some people, but not to others. This is a very powerful property of Coconut, potentially leading to diverse applications: voting systems, selective revelation of medical data, privacy-friendly KYC systems, etc. - -4. _[Threshold issuance](https://en.wikipedia.org/wiki/Threshold_cryptosystem)_ - allows signature generation to be split up across multiple nodes and decentralized, so that either all signers need to sign (_n of n_ where _n_ is the number of signers) or only a threshold number of signers need to sign a message (_t of n_ where _t_ is the threshold value). - -Taken together, these properties provide privacy for applications when it comes to generating and using signatures for cryptographic claims. If you compare it to existing tech, you might think of it as a sort of supercharged decentralized privacy-friendly [JWT](https://jwt.io/). - -A slightly expanded view of Coconut is available [in this blog post](https://medium.com/nymtech/nyms-coconut-credentials-an-overview-4aa4e922cd51). - -### Using Coconut for blockchain transaction privacy - -In the context of a blockchain currency system, Coconut allows us to create a privacy-enhanced Coconut credential which provably represents an amount under control of a given entity. The credential can then be "spent" anonymously, as if it were the original value. Double-spending protections apply to the credential, so it can only be spent once. Nyx Validators can then unlock the value so it can be redeemed by the party holding the credential. - -Although there's still work to be done to integrate it against various blockchains, in principle Coconut can anonymise blockchain transactions in any system which provides multi-sig. We're working on [Cosmos](https://cosmos.network) integration at the moment. Bitcoin and Ethereum are also obvious targets here. - -Coconut is simple and flexible, and can ensure privacy for more than coin transfers; it can provide privacy for more complex smart contracts as well. - -Finally, it should be mentioned that Coconut can be applied to both blockchain and non-blockchain systems - it's a general purpose technology. diff --git a/documentation/old_docs/docs/src/explorers/mixnet-explorer.md b/documentation/old_docs/docs/src/explorers/mixnet-explorer.md deleted file mode 100644 index 2aa52c4aaf..0000000000 --- a/documentation/old_docs/docs/src/explorers/mixnet-explorer.md +++ /dev/null @@ -1,201 +0,0 @@ -# Mixnet Explorer - -The Nym Network Explorer lets you explore the Nym network. We have open-sourced the explorer so that anyone can run an instance of it, further decentralising the network! - -### Prerequisites -- `git` - -``` -sudo apt update -sudo apt install git -``` - -Verify `git` is installed with: - -``` -git version -# Should return: git version X.Y.Z -``` - -- (Debian/Ubuntu) `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq` - -``` -sudo apt update -sudo apt install pkg-config build-essential libssl-dev curl jq -``` - -- `NodeJS` (use `nvm install` to automatically install the correct version) and `npm` - -- `Rust & cargo >= {{minimum_rust_version}}` - -We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old. - -If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms. - - -### Local Development -Complete the steps in the [building nym](../binaries/building-nym.md) 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: - -``` -nvm install # install relevant nodejs and npm versions -npm install -npm run start -``` - -`eslint` and `prettier` are already configured. - -You can lint the code by running: - -``` -npm run lint -``` - -> This command will only **show** linting errors and will not fix them! - -To fix all linting errors automatically run: - -``` -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](../binaries/building-nym.md) 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. - -#### Building the Explorer UI -Build the UI with these commands from within the `explorer` directory: - -``` -nvm install # install relevant nodejs and npm versions -npm install -npm run build -``` - -The output will be in the `dist` directory. - -This can then be either served directly from the `nym` directory, or from its own directory if you wish. See the template nginx config below for more on how to host this. - -#### Building the Explorer API -The Explorer API was built in the previous step with `cargo build`. - -### Automating the explorer with systemd -You will most likely want to automate the Explorer-API restarting if your server reboots. Below is a systemd unit file to place at `/etc/systemd/system/nym-explorer-api.service`: - -```ini -[Unit] -Description=Nym Explorer API (1.1.0) -StartLimitIntervalSec=350 -StartLimitBurst=10 - -[Service] -User=nym -Type=simple -Environment="API_STATE_FILE=/home/nym/network-explorer/explorer-api-state.json" -Environment="GEO_IP_SERVICE_API_KEY=c69155d0-25f6-11ec-80bc-75e5dbd322c3" -ExecStart=explorer/api/location -Restart=on-failure -RestartSec=30 - -[Install] -WantedBy=multi-user.target -``` - -Proceed to start it with: - -``` -systemctl daemon-reload # to pickup the new unit file -systemctl enable nymd # to enable the service -systemctl start nymd # to actually start the service -journalctl -f # to monitor system logs showing the service start -``` - -### Installing and configuring nginx for HTTPS -#### Setup -[Nginx](https://www.nginx.com/resources/glossary/nginx/#:~:text=NGINX%20is%20open%20source%20software,%2C%20media%20streaming%2C%20and%20more.&text=In%20addition%20to%20its%20HTTP,%2C%20TCP%2C%20and%20UDP%20servers.) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security. - -Install `nginx` and allow the 'Nginx Full' rule in your firewall: - -``` -sudo ufw allow 'Nginx Full' -``` - -Check nginx is running via systemctl: - -``` -systemctl status nginx -``` - -Which should return: - -``` -● nginx.service - A high performance web server and a reverse proxy server - Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) - Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago - Docs: man:nginx(8) - Main PID: 2369 (nginx) - Tasks: 2 (limit: 1153) - CGroup: /system.slice/nginx.service - ├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; - └─2380 nginx: worker process -``` - -#### Configuration -Replace the default nginx configuration at `/etc/nginx/sites-available/` with: - -``` -server { - listen 80; - listen [::]:80; - server_name domain; - root html_location; - location / { - try_files /$uri /$uri/index.html /index.html =404; - } - - location /api { - proxy_pass http://127.0.0.1:8000; - rewrite /api/(.*) /$1 break; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - } -} -``` - -Followed by: - -``` -sudo apt install certbot nginx python3 -certbot --nginx -d nym-validator.yourdomain.com -m you@yourdomain.com --agree-tos --noninteractive --redirect -``` - -```admonish caution -If using a VPS running Ubuntu 20: replace `certbot nginx python3` with `python3-certbot-nginx` -``` - -### Configure your firewall -The following commands will allow you to set up a firewall using `ufw`. - -``` -# check if you have ufw installed -ufw version -# if it is not installed, install with -sudo apt install ufw -y -# enable ufw -sudo ufw enable -# check the status of the firewall -sudo ufw status -``` - -Now open the ports: - -``` -sudo ufw allow 22,80,443/tcp -# check the status of the firewall -sudo ufw status -``` \ No newline at end of file diff --git a/documentation/old_docs/docs/src/images/FAVICON.png b/documentation/old_docs/docs/src/images/FAVICON.png deleted file mode 100644 index f66101ce3d..0000000000 Binary files a/documentation/old_docs/docs/src/images/FAVICON.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/FAVICON_DARK.png b/documentation/old_docs/docs/src/images/FAVICON_DARK.png deleted file mode 100644 index d7dea7c016..0000000000 Binary files a/documentation/old_docs/docs/src/images/FAVICON_DARK.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/application-flow/send-to-gateway-dark.png b/documentation/old_docs/docs/src/images/application-flow/send-to-gateway-dark.png deleted file mode 100644 index 81fc8623e2..0000000000 Binary files a/documentation/old_docs/docs/src/images/application-flow/send-to-gateway-dark.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/application-flow/send-to-gateway.png b/documentation/old_docs/docs/src/images/application-flow/send-to-gateway.png deleted file mode 100644 index 20d28894d0..0000000000 Binary files a/documentation/old_docs/docs/src/images/application-flow/send-to-gateway.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/application-flow/simplest-request-dark.png b/documentation/old_docs/docs/src/images/application-flow/simplest-request-dark.png deleted file mode 100644 index b87d9d47fd..0000000000 Binary files a/documentation/old_docs/docs/src/images/application-flow/simplest-request-dark.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/application-flow/simplest-request.png b/documentation/old_docs/docs/src/images/application-flow/simplest-request.png deleted file mode 100644 index 9483930d0f..0000000000 Binary files a/documentation/old_docs/docs/src/images/application-flow/simplest-request.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/application-flow/sp-request-dark.png b/documentation/old_docs/docs/src/images/application-flow/sp-request-dark.png deleted file mode 100644 index 6eacac4b3c..0000000000 Binary files a/documentation/old_docs/docs/src/images/application-flow/sp-request-dark.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/application-flow/sp-request.png b/documentation/old_docs/docs/src/images/application-flow/sp-request.png deleted file mode 100644 index cb5fe31ea4..0000000000 Binary files a/documentation/old_docs/docs/src/images/application-flow/sp-request.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/archive/mixnet.png b/documentation/old_docs/docs/src/images/archive/mixnet.png deleted file mode 100644 index 507e183bee..0000000000 Binary files a/documentation/old_docs/docs/src/images/archive/mixnet.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/archive/nym-testnet.png b/documentation/old_docs/docs/src/images/archive/nym-testnet.png deleted file mode 100644 index 28cef4a208..0000000000 Binary files a/documentation/old_docs/docs/src/images/archive/nym-testnet.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/archive/validators.png b/documentation/old_docs/docs/src/images/archive/validators.png deleted file mode 100644 index 9054129bf9..0000000000 Binary files a/documentation/old_docs/docs/src/images/archive/validators.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/conversation.gif b/documentation/old_docs/docs/src/images/conversation.gif deleted file mode 100644 index 3744c7edb3..0000000000 Binary files a/documentation/old_docs/docs/src/images/conversation.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/dashboard.gif b/documentation/old_docs/docs/src/images/dashboard.gif deleted file mode 100644 index 01f7f5eedc..0000000000 Binary files a/documentation/old_docs/docs/src/images/dashboard.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/download-wallet.png b/documentation/old_docs/docs/src/images/download-wallet.png deleted file mode 100644 index b66b6238b2..0000000000 Binary files a/documentation/old_docs/docs/src/images/download-wallet.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/gateway-bonded.png b/documentation/old_docs/docs/src/images/gateway-bonded.png deleted file mode 100644 index e12dc54311..0000000000 Binary files a/documentation/old_docs/docs/src/images/gateway-bonded.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/keybase-demo.gif b/documentation/old_docs/docs/src/images/keybase-demo.gif deleted file mode 100644 index 949b61979f..0000000000 Binary files a/documentation/old_docs/docs/src/images/keybase-demo.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/keybase-settings.gif b/documentation/old_docs/docs/src/images/keybase-settings.gif deleted file mode 100644 index c2a0defb93..0000000000 Binary files a/documentation/old_docs/docs/src/images/keybase-settings.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-connect-app.png b/documentation/old_docs/docs/src/images/nym-connect-app.png deleted file mode 100644 index 8016c69dfb..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-connect-app.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-connect.gif b/documentation/old_docs/docs/src/images/nym-connect.gif deleted file mode 100644 index f281ed8a18..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-connect.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-logo.svg b/documentation/old_docs/docs/src/images/nym-logo.svg deleted file mode 100644 index 9b11e2716e..0000000000 --- a/documentation/old_docs/docs/src/images/nym-logo.svg +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/documentation/old_docs/docs/src/images/nym-mac-install-drag.png b/documentation/old_docs/docs/src/images/nym-mac-install-drag.png deleted file mode 100644 index f1e46c0b4a..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-mac-install-drag.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-mac-warning.png b/documentation/old_docs/docs/src/images/nym-mac-warning.png deleted file mode 100644 index 1d0a0d5fe2..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-mac-warning.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-platform-dark-old.png b/documentation/old_docs/docs/src/images/nym-platform-dark-old.png deleted file mode 100644 index 499c53df6c..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-platform-dark-old.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-platform-dark.png b/documentation/old_docs/docs/src/images/nym-platform-dark.png deleted file mode 100644 index a6ded75c4a..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-platform-dark.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-platform.png b/documentation/old_docs/docs/src/images/nym-platform.png deleted file mode 100644 index 7810064102..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-platform.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-socks5-architecture-dark.png b/documentation/old_docs/docs/src/images/nym-socks5-architecture-dark.png deleted file mode 100644 index 9c1faad152..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-socks5-architecture-dark.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-socks5-architecture.png b/documentation/old_docs/docs/src/images/nym-socks5-architecture.png deleted file mode 100644 index 2453ea53dc..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-socks5-architecture.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/nym-token-flow.png b/documentation/old_docs/docs/src/images/nym-token-flow.png deleted file mode 100644 index eb026e2325..0000000000 Binary files a/documentation/old_docs/docs/src/images/nym-token-flow.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/send-a-packet.gif b/documentation/old_docs/docs/src/images/send-a-packet.gif deleted file mode 100644 index c6341b4405..0000000000 Binary files a/documentation/old_docs/docs/src/images/send-a-packet.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/traffic-flow-dark.png b/documentation/old_docs/docs/src/images/traffic-flow-dark.png deleted file mode 100644 index 01e28b4da4..0000000000 Binary files a/documentation/old_docs/docs/src/images/traffic-flow-dark.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/traffic-flow.png b/documentation/old_docs/docs/src/images/traffic-flow.png deleted file mode 100644 index 26865a9616..0000000000 Binary files a/documentation/old_docs/docs/src/images/traffic-flow.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-proxy-settings/blockstream-green.gif b/documentation/old_docs/docs/src/images/wallet-proxy-settings/blockstream-green.gif deleted file mode 100644 index 33e2725c29..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-proxy-settings/blockstream-green.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-proxy-settings/electrum.gif b/documentation/old_docs/docs/src/images/wallet-proxy-settings/electrum.gif deleted file mode 100644 index bbf2602539..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-proxy-settings/electrum.gif and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-screenshots/bonding.png b/documentation/old_docs/docs/src/images/wallet-screenshots/bonding.png deleted file mode 100644 index b5cef3bb89..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-screenshots/bonding.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-screenshots/node_settings.png b/documentation/old_docs/docs/src/images/wallet-screenshots/node_settings.png deleted file mode 100644 index 69568ce6a5..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-screenshots/node_settings.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-sign.png b/documentation/old_docs/docs/src/images/wallet-sign.png deleted file mode 100644 index 63a76aaf4d..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-sign.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning1.png b/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning1.png deleted file mode 100644 index 04cf7ece46..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning1.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning2.png b/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning2.png deleted file mode 100644 index 8bcf9ccae7..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning2.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning3.png b/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning3.png deleted file mode 100644 index c189f79308..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/mac_warning3.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning1.png b/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning1.png deleted file mode 100644 index b85d34c643..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning1.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning2.png b/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning2.png deleted file mode 100644 index 8a5c2da559..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning2.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning3.png b/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning3.png deleted file mode 100644 index 2dde65cee3..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning3.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning4.png b/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning4.png deleted file mode 100644 index 0254b0bbdc..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning4.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning5.png b/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning5.png deleted file mode 100644 index 80c709ddd0..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warning5.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warningv1-0-2.png b/documentation/old_docs/docs/src/images/wallet-warnings/windows_warningv1-0-2.png deleted file mode 100644 index 77713ae6c7..0000000000 Binary files a/documentation/old_docs/docs/src/images/wallet-warnings/windows_warningv1-0-2.png and /dev/null differ diff --git a/documentation/old_docs/docs/src/introduction.md b/documentation/old_docs/docs/src/introduction.md deleted file mode 100644 index 189badbd0e..0000000000 --- a/documentation/old_docs/docs/src/introduction.md +++ /dev/null @@ -1,32 +0,0 @@ -# Introduction - -This is Nym's technical documentation, containing information and setup guides about the various pieces of Nym software such as different Mixnet infrastructure nodes, application clients, and existing applications like the desktop wallet and Mixnet explorer. - -If you are new to Nym and want to learn about the Mixnet, explore kickstart options and demos, learn how to integrate with the network, and follow developer tutorials check out the [Developer Portal](https://nymtech.net/developers/) where you can find also our [FAQ section](https://nymtech.net/developers/faq/general-faq.html). - -If you are looking for information and setup guides for the various pieces of Nym Mixnet infrastructure (Mix Nodes, Gateways and Network Requesters) and Nyx blockchain validators see the [Operators Guides](https://nymtech.net/operators) book. - -If you're specifically looking for TypeScript/JavaScript related information such as SDKs to build your own tools, step-by-step tutorials, live playgrounds and more - check out the [TS SDK Handbook](https://sdk.nymtech.net/). - -## Popular pages -**Network Architecture:** -* [Network Overview](./architecture/network-overview.md) -* [Mixnet Traffic Flow](./architecture/traffic-flow.md) - -**SDK examples:** -* [Typescript SDK](https://sdk.nymtech.net/) -* [Rust SDK](sdk/rust/rust.md) - -**Nyx** -* [Interacting with the Nyx chain](./nyx/interacting-with-chain.md) -* [Ledger Live setup](./nyx/ledger-live.md) -* [RPC Node](./nyx/rpc-node.md) - -**Client setup and usage guides:** -* [Websocket client](./clients/websocket-client.md) -* [Socks5 client](./clients/socks5-client.md) -* [Webassembly client](./clients/webassembly-client.md) - -**Wallets** -* [Desktop](./wallet/desktop-wallet.md) -* [CLI](./wallet/cli-wallet.md) diff --git a/documentation/old_docs/docs/src/licensing.md b/documentation/old_docs/docs/src/licensing.md deleted file mode 100644 index b569231b75..0000000000 --- a/documentation/old_docs/docs/src/licensing.md +++ /dev/null @@ -1,11 +0,0 @@ -# Licensing - -As a general approach, licensing is as follows this pattern: - -*

Nym Documentation by Nym Technologies is licensed under CC BY-NC-SA 4.0

- -* Nym applications and binaries are [GPL-3.0-only](https://www.gnu.org/licenses/) - -* Used libraries and different components are [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) or [MIT](https://mit-license.org/) - -For accurate information, please check individual files. diff --git a/documentation/old_docs/docs/src/nodes/gateway.md b/documentation/old_docs/docs/src/nodes/gateway.md deleted file mode 100644 index ffdee59f7c..0000000000 --- a/documentation/old_docs/docs/src/nodes/gateway.md +++ /dev/null @@ -1,11 +0,0 @@ -# Gateways - -> The gateway setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/gateway-setup.html). - -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](../architecture/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. - -## Further Reading -* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4.2 -* [Nym Blog: Gateways to Privacy](https://blog.nymtech.net/gateways-to-privacy-51196005bf5) diff --git a/documentation/old_docs/docs/src/nodes/mixnode.md b/documentation/old_docs/docs/src/nodes/mixnode.md deleted file mode 100644 index 8565f7be0a..0000000000 --- a/documentation/old_docs/docs/src/nodes/mixnode.md +++ /dev/null @@ -1,17 +0,0 @@ -# Mix Nodes - -> The mix node setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/mix-node-setup.html). - -Mix nodes are the backbone of the mixnet. These are the nodes that perform 'mix mining', otherwise known simply as 'mixing'. - -Mix nodes, after receiving a packet, decrypt its outer 'layer' and hold it for a variable amount of time before passing it to its next destination - either another mix node, or a gateway. In doing so, they 'mix' packets by sending them to their next destination in a different order than they were received. - -Mix nodes are rewarded according to their quality of service, and the probability of their inclusion in the active set (i.e. the nodes that mix traffic for the next epoch) is also affected by this (as well as their delegation-based reputation - see the [Mix node deepdive](#further-reading) below for more on this). - -## (Coming soon) Mixing: a Step-by-Step Breakdown - -## Further reading -* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4 -* [Nym Blog: Mix node deepdive](https://blog.nymtech.net/nym-mixnodes-deep-dive-d2b91917f097) -* [Mixnet Traffic Flow overview](../architecture/traffic-flow.md) -* [Reward Sharing for Mixnets](https://nymtech.net/nym-cryptoecon-paper.pdf) diff --git a/documentation/old_docs/docs/src/nodes/network-requester.md b/documentation/old_docs/docs/src/nodes/network-requester.md deleted file mode 100644 index da9fff6a64..0000000000 --- a/documentation/old_docs/docs/src/nodes/network-requester.md +++ /dev/null @@ -1,22 +0,0 @@ -# Network Requester - -> The network requester setup and maintenance guide has moved to the [Operator Guides book](https://nymtech.net/operators/nodes/network-requester-setup.html). - -Network requesters are the first instance of the catch-all term 'service', or 'service providers'. In essence, think of services as being the part of the mixnet infrastructure that let you _do_ something, such as access emails, messaging service backends, or blockchains via the mixnet. - -## Domain filtering -Network requesters, in essence, act as a form of proxy (somewhat analagous to a Tor exit node). If you have access to a server, you can run the network requester, which allows Nym users to send outbound requests from their local machine through the mixnet to a server, which then makes the request on their behalf, shielding them (and their metadata) from clearnet, untrusted and unknown infrastructure, such as email or message client servers. - -By default the network requester is **not** an open proxy (although it can be used as one). It uses a whitelist for outbound requests. - -Any request to a URL which is not on this local list (modified by the node operator) or [Nym's default list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) will be blocked. - -This default whitelist is useful for knowing that the majority of Network requesters are able to support certain apps 'out of the box', and the local whitelist allows operators to include their own whitelisted domains. - -> Substantial changes are on the horizon concerning how Network Requesters manage incoming requests - if you are an operator and have experience running software such as Tor exit nodes or p2p nodes get in touch via our [Matrix server](https://matrix.to/#/#dev:nymtech.chat). - -## (Coming soon) Consuming credentials for anonymous service payment - -## Further reading -* [Nym Blog: Network Requester deepdive](https://blog.nymtech.net/tech-deepdive-network-requesters-e5359a6cc31c) -* [Nym Blog: Choose Your Character](https://blog.nymtech.net/choose-your-character-an-overview-of-nym-network-actors-19e6a9808540) diff --git a/documentation/old_docs/docs/src/nodes/overview.md b/documentation/old_docs/docs/src/nodes/overview.md deleted file mode 100644 index ec0d801583..0000000000 --- a/documentation/old_docs/docs/src/nodes/overview.md +++ /dev/null @@ -1,7 +0,0 @@ -# Node Types - -```admonish info -We are working on a detailed description of how each component of Nym Mixnet and Nyx blockchain functions, as well as references to any literature and technical specs. - -Meanwhile please refer to our [**Operators Guide**](https://nymtech.net/operators) book. -``` diff --git a/documentation/old_docs/docs/src/nodes/validator.md b/documentation/old_docs/docs/src/nodes/validator.md deleted file mode 100644 index 855cf21700..0000000000 --- a/documentation/old_docs/docs/src/nodes/validator.md +++ /dev/null @@ -1,12 +0,0 @@ -# Validators - -> The validator setup and maintenance guide has moved to the [Operator Guides book](https://nymtech.net/operators/nodes/validator-setup.html). - -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](../nyx/mixnet-contract.md) and [Vesting](../nyx/vesting-contract.md) 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. -* Our [quarterly update](https://blog.nymtech.net/quarterly-token-economic-parameter-update-b2862948710f) on token economics from July 2023. -* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 3.1 \ No newline at end of file diff --git a/documentation/old_docs/docs/src/not-found.md b/documentation/old_docs/docs/src/not-found.md deleted file mode 100644 index af87d6dd59..0000000000 --- a/documentation/old_docs/docs/src/not-found.md +++ /dev/null @@ -1,11 +0,0 @@ -# Page Not Found - -You seem to have followed a link to a page that no longer exists. Our documentation is changing and growing over time, so this page has most likely been moved somewhere else. - -For node setup guides, see the [Operator Guides book](https://nymtech.net/operators). - -For developer tutorials, app guides, and demo and community apps, see the [Developer Portal](https://nymtech.net/developers). - -If you are looking for information on network architecture traffic flow, clients, the SDKs, or interacting with the Nyx blockchain, check the sitemap on the left hand side of the screen. - -If you still can't find what you're looking for get in touch with us via [Matrix](https://matrix.to/#/#nym-community:nymtech.chat). \ No newline at end of file diff --git a/documentation/old_docs/docs/src/nyx/interacting-with-chain.md b/documentation/old_docs/docs/src/nyx/interacting-with-chain.md deleted file mode 100644 index 5ebd5484bd..0000000000 --- a/documentation/old_docs/docs/src/nyx/interacting-with-chain.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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`](../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](../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. - -You can use the instructions on how to do this on from the [`gaiad` docs page](https://hub.cosmos.network/main/delegators/delegator-guide-cli.html#querying-the-state), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html). - - diff --git a/documentation/old_docs/docs/src/nyx/ledger-live.md b/documentation/old_docs/docs/src/nyx/ledger-live.md deleted file mode 100644 index 968dd2e25b..0000000000 --- a/documentation/old_docs/docs/src/nyx/ledger-live.md +++ /dev/null @@ -1,79 +0,0 @@ -# Ledger Live Support - -Use the following instructions to interact with the Nyx blockchain - either with deployed smart contracts, or just to send tokens - using your Ledger device to sign transactions. - -## Prerequisites -* Download and install [Ledger Live](https://www.ledger.com/ledger-live). -* Compile the `nyxd` binary as per the instructions [here](https://nymtech.net/operators/nodes/validator-setup.html#building-the-nym-validator). Stop after you can successfully run `nyxd` and get the helptext in your console output. - -## Prepare your Ledger App -* Plug in your Ledger device -* Install the `Cosmos (ATOM)` app by following the instructions [here](https://hub.cosmos.network/main/resources/ledger.html). This app allows you to interact with **any** Cosmos SDK chain - you can manage your ATOM, OSMOSIS, NYM tokens, etc. -* On the device, navigate to the Cosmos app and open it - -## Create a keypair -Add a reference to the ledger device on your local machine by running the following command in the same directory as your `nyxd` binary: - -``` -nyxd keys add ledger_account --ledger -``` - -## Command help with `nyxd` -More information about each command is available by consulting the help section (`--help`) at each layer of `nyxd`'s commands: - -``` -# logging top level command help -nyxd --help - -# logging top level command help for transaction commands -nyxd tx --help - -# logging top level command help for transaction commands utilising the 'bank' module -nyxd tx bank --help -``` - -## Sending tokens between addresses -Perform a transaction from the CLI with `nyxd`, appending the `--ledger` option to the command. - -As an example, the below command will send 1 `NYM` from the ledger account to the `$DESTINATION_ACCOUNT`: - -``` -nyxd tx bank send ledger_account $DESTINATION_ACCOOUNT 1000000unym --ledger --node https://rpc.dev.nymte.ch:443 -``` - -> When a command is run, the transaction will appear on the Ledger device and will require physical confirmation from the device before being signed. - -## Nym-specific transactions -Nym-specific commands and queries, like bonding a mix node or delegating unvested tokens, are available in the `wasm` module, and follow the following pattern: - -``` -# Executing commands -nyxd tx wasm execute $CONTRACT_ADDRESS $JSON_MSG - -# Querying the state of a smart contract -nyxd query wasm contract-state smart $CONTRACT_ADDRESS $JSON_MSG -``` - -You can find the value of `$CONTRACT_ADDRESS` in the [`network defaults`](https://github.com/nymtech/nym/blob/release/v1.1.7/common/network-defaults/src/mainnet.rs) file. - -The value of `$JSON_MSG` will be a blog of `json` formatted as defined for each command and query. You can find these definitions for the mixnet smart contract [here](https://github.com/nymtech/nym/blob/develop/common/cosmwasm-smart-contracts/mixnet-contract/src/msg.rs) and for the vesting contract [here](https://github.com/nymtech/nym/blob/develop/common/cosmwasm-smart-contracts/vesting-contract/src/messages.rs) under `ExecuteMsg` and `QueryMsg`. - -### Example command execution: -#### Delegate to a mix node -You can delegate to a mix node from the CLI using `nyxd` and signing the transaction with your ledger by filling in the values of this example: -``` -CONTRACT_ADDRESS=mixnet_contract_address - -./nyxd tx wasm execute $CONTRACT_ADDRESS '{"delegate_to_mixnode":{"mix_identity":"MIX_NODE_IDENTITY","amount":{"amount":"100000000000","denom":"unym"}}}' --ledger --from admin --node https://rpc.dev.nymte.ch:443 --gas-prices 0.025unymt --gas auto -b block -``` - -> By replacing the value of `CONTRACT_ADDRESS` with the address of the vesting contract, you could use the above command to use tokens held in the vesting contract. - -#### Query a vesting schedule -You can query for (e.g.) seeing the current vesting period of an address by filling in the values of the following: -``` -CONTRACT_ADDRESS=vesting_contract_address - -nyxd query wasm contract-state smart $CONTRACT_ADDRESS '{"get_current_vesting_period"}:{"address": "address_to_query_for"}' --ledger --from admin --node https://rpc.dev.nymte.ch:443 --chain-id qa-net --gas-prices 0.025unymt --gas auto -b block -``` - diff --git a/documentation/old_docs/docs/src/nyx/mixnet-contract.md b/documentation/old_docs/docs/src/nyx/mixnet-contract.md deleted file mode 100644 index 48b63281fc..0000000000 --- a/documentation/old_docs/docs/src/nyx/mixnet-contract.md +++ /dev/null @@ -1,13 +0,0 @@ -# Mixnet Contract - -The Mixnet smart contract is a core piece of the Nym system, functioning as the mixnet directory and keeping track of delegations and rewards: the core functionality required by an incentivised mixnet. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/mixnet). - -### Functionality -The Mixnet contract has multiple functions: -* storing bonded mix node and gateway information (and removing this on unbonding). -* providing the network-topology to the (cached) validator API endpoint used by clients on startup for routing information. -* storing delegation and bond amounts. -* storing reward amounts. - -The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values. - diff --git a/documentation/old_docs/docs/src/nyx/rpc-node.md b/documentation/old_docs/docs/src/nyx/rpc-node.md deleted file mode 100644 index 352b689bed..0000000000 --- a/documentation/old_docs/docs/src/nyx/rpc-node.md +++ /dev/null @@ -1,9 +0,0 @@ -# RPC Nodes - -RPC Nodes (which might otherwise be referred to as 'Lite Nodes' or just 'Full Nodes') differ from Validators in that they hold a copy of the Nyx blockchain, but do **not** participate in consensus / block-production. - -You may want to set up an RPC Node for querying the blockchain, or in order to have an endpoint that your app can use to send transactions. - -In order to set up an RPC Node, simply follow the instructions to set up a [Validator](https://nymtech.net/operators/nodes/validator-setup.html), but **exclude the `nyxd tx staking create-validator` command**. - -If you want to fast-sync your node, check out the Polkachu snapshot and their other [resources](https://polkachu.com/seeds/nym). diff --git a/documentation/old_docs/docs/src/nyx/smart-contracts.md b/documentation/old_docs/docs/src/nyx/smart-contracts.md deleted file mode 100644 index 7c1182e79a..0000000000 --- a/documentation/old_docs/docs/src/nyx/smart-contracts.md +++ /dev/null @@ -1,9 +0,0 @@ -# Smart Contracts - -The Nyx blockchain is based on [CosmWasm](https://cosmwasm.com/). It allows users to code smart contracts in a safe subset of the Rust programming language, easily export them to WebAssembly, and upload them to the blockchain. Information about the chain can be found on the [Nyx blockchain explorer](https://nym.explorers.guru/). - -There are currently two smart contracts on the Nyx chain: -* the [Mixnet contract](./mixnet-contract.md) which manages the network topology of the mixnet, tracking delegations and rewarding. -* the [Vesting contract](./vesting-contract.md) which manages `NYM` token vesting functionality. - -> Users will soon be able to create and upload their own CosmWasm smart contracts to Nyx and take advantage of applications such as the Coconut Credential Scheme - more to be announced regarding this very soon. diff --git a/documentation/old_docs/docs/src/nyx/vesting-contract.md b/documentation/old_docs/docs/src/nyx/vesting-contract.md deleted file mode 100644 index cbc5bfbcee..0000000000 --- a/documentation/old_docs/docs/src/nyx/vesting-contract.md +++ /dev/null @@ -1,11 +0,0 @@ -# Vesting Contract - -The vesting contract allows for the creation of vesting accounts, allowing `NYM` tokens to vest over time, and for users to minimally interact with the Mixnet using their unvested tokens. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/vesting). - -### Functionality -The Vesting contract has multiple functions: -* Creating and storing vesting `NYM` token vesting accounts. -* Interacting with the Mixnet using vesting (i.e. non-transferable) tokens, allowing users to delegate their unvested tokens. - -The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values. - diff --git a/documentation/old_docs/docs/src/tools/nym-cli.md b/documentation/old_docs/docs/src/tools/nym-cli.md deleted file mode 100644 index b6ed36bfa7..0000000000 --- a/documentation/old_docs/docs/src/tools/nym-cli.md +++ /dev/null @@ -1,339 +0,0 @@ -# Nym-CLI - -## What is this tool for? -This is a CLI tool for interacting with: - -* the Nyx blockchain (account management, querying the chain state, etc) -* the smart contracts deployed on Nyx (bonding and un-bonding mixnodes, collecting rewards, etc) - -It provides a convenient wrapper around the `nymd` client, and has similar functionality to the `nyxd` binary for querying the chain or executing smart contract methods. - -## Building -The `nym-cli` binary can be built by running `cargo build --release` in the `nym/tools/nym-cli` directory. - -### Usage -You can see all available commands with: - -``` -./nym-cli --help -``` - -~~~admonish example collapsible=true title="Console output" -``` - -nym-cli -A client for interacting with Nym smart contracts and the Nyx blockchain - -USAGE: - nym-cli [OPTIONS] - -OPTIONS: - --config-env-file - Overrides configuration as a file of environment variables. Note: individual env vars - take precedence over this file. - - -h, --help - Print help information - - --mixnet-contract-address - Overrides the mixnet contract address provided either as an environment variable or in a - config file - - --mnemonic - Provide the mnemonic for your account. You can also provide this is an env var called - MNEMONIC. - - --nymd-url - Overrides the nymd URL provided either as an environment variable NYMD_VALIDATOR or in a - config file - - --validator-api-url - Overrides the validator API URL provided either as an environment variable API_VALIDATOR - or in a config file - - --vesting-contract-address - Overrides the vesting contract address provided either as an environment variable or in - a config file - -subcommands: - account Query and manage Nyx blockchain accounts - block Query chain blocks - cosmwasm Manage and execute WASM smart contracts - generate-fig Generates shell completion - help Print this message or the help of the given subcommand(s) - mixnet Manage your mixnet infrastructure, delegate stake or query the directory - signature Sign and verify messages - tx Query for transactions - vesting-schedule Create and query for a vesting schedule -``` -~~~ - -## Example Usage -Below we have listed some example commands for some of the features listed above. - -If ever in doubt what you need to type, or if you want to see alternative parameters for a command, use the `nym-cli --help` to view all available options. - -``` -./nym-cli account create --help -``` - -~~~admonish example collapsible=true title="Console output" -``` - -Create a new mnemonic - note, this account does not appear on the chain until the account id is used in a transaction - -USAGE: - nym-cli account create [OPTIONS] - -OPTIONS: - --config-env-file - Overrides configuration as a file of environment variables. Note: individual env vars take precedence over this file. - --h, --help - Print help information - - --mixnet-contract-address - Overrides the mixnet contract address provided either as an environment variable or in a - config file - - --mnemonic - Provide the mnemonic for your account. You can also provide this is an env var called - MNEMONIC. - - --nymd-url - Overrides the nymd URL provided either as an environment variable NYMD_VALIDATOR or in a - config file - - --validator-api-url - Overrides the validator API URL provided either as an environment variable API_VALIDATOR - or in a config file - - --vesting-contract-address - Overrides the vesting contract address provided either as an environment variable or in - a config file - - --word-count -``` -~~~ - -### Create account - -Creates an account with a random Mnemonic and a new address. - -``` -./nym-cli account create - -# Result: -# 1. Mnemonic -assist jungle spoil domain saddle energy box carpet toy resist castle faith talent note outdoor inform cage lecture syrup trigger dress oppose slender museum -# 2. Address -n132tpw4kkfas7ah0vmq78dwurhxljf2f869tlf5 -``` -> NEVER share your mnemonic with anyone. Keep it stored in a safe and secure location. - -### Check the current balance of an account - -Queries the existing balance of an account. - -``` -# Using adddress below for example purposes. -./nym-cli account balance n1hzn28p2c6pzr98r85jp3h53fy8mju5w7ndd5vh - -# Result: -2022-11-10T10:28:54.009Z INFO nym_cli_commands::validator::account::balance > Getting balance for n1hzn28p2c6pzr98r85jp3h53fy8mju5w7ndd5vh... - -# Balance for each token will be listed here -0.264 nym -1921.995 nyx -``` - -You can also query an accounts balance by using its mnemonic: - -``` -./nym-cli account balance --mnemonic -``` - -### Send tokens to an account - -Sends tokens to an account using an address. - -``` -./nym-cli account send
-``` - -### Get the current block height - -Queries the specified blockchain (Nyx chain by default) for the current block height. - -``` -./nym-cli block current-height --mnemonic - -# Result: -Current block height: - -``` - -### Query for a mix node - -Query a mix node on the mixnet. - -``` -./nym-cli mixnet query mixnodes --mnemonic -``` - - -### Bond a mix node - -Bonding a mix node is a process that takes a few steps due to the need to sign a transaction with your nym address for replay attack protection. - -* generate a signature payload: -``` -./nym-cli mixnet operators mixnode create-mixnode-bonding-sign-payload - -# returns something like -97GEhgMrPTmQVZgHqJeqWmgQ154GLKqy8xNGtLkV8xy5xc1SuwsEnqjhtZVshBYK74n53fFkKbSrS6kxkBE3vUikbU76JZmLMFmfR7aaU2NdBnfTPPHP2nwb2hJiEueq4SvvtDtQckxv7ZJzdxyXHxUeDPhzbprxTff78U3NGNk4cg6Q2K4EFqishdaqToedsXAPvVCWNbC1iWVjEq8nJ95Eb3NJyi3KmXcNDy4i8ZXgZHu4v8F4htXq2vZUdBSbizdkNr1NRvEg6PGVQdTseyuN8JxD3yuvrqprPY2kvJaT2YiYLPgWxoQtbfwcpkX4PP1PvwuMg4W8EXhitMpM2WHqLDP5vgfDGxdDCmRS44pM8ya4hcQ4g3McHWxduGWdbCzNNEsX6oQw4LVFcWn4mhbXSgqHwNQMm2TQW6LatYZSwCczdhEwV2CXe36UGCUzozmm4nj9qfUtXqDzMrHAAS8kjbKaVNaVaRRKgauQrHnK7QGg1QpVnnaxCs14wvUb62sio8XZmMzP2SjVaRJFCyJB3UwZ6L4oXMGMXSRsiKe8ZNTaa6iX69tx54CAAHBHoiReiq7E5T2VuR5v -``` - -* sign this payload: -``` -./nym-mixnode sign --id upgrade_test --contract-msg 97GEhgMrPTmQVZgHqJeqWmgQ154GLKqy8xNGtLkV8xy5xc1SuwsEnqjhtZVshBYK74n53fFkKbSrS6kxkBE3vUikbU76JZmLMFmfR7aaU2NdBnfTPPHP2nwb2hJiEueq4SvvtDtQckxv7ZJzdxyXHxUeDPhzbprxTff78U3NGNk4cg6Q2K4EFqishdaqToedsXAPvVCWNbC1iWVjEq8nJ95Eb3NJyi3KmXcNDy4i8ZXgZHu4v8F4htXq2vZUdBSbizdkNr1NRvEg6PGVQdTseyuN8JxD3yuvrqprPY2kvJaT2YiYLPgWxoQtbfwcpkX4PP1PvwuMg4W8EXhitMpM2WHqLDP5vgfDGxdDCmRS44pM8ya4hcQ4g3McHWxduGWdbCzNNEsX6oQw4LVFcWn4mhbXSgqHwNQMm2TQW6LatYZSwCczdhEwV2CXe36UGCUzozmm4nj9qfUtXqDzMrHAAS8kjbKaVNaVaRRKgauQrHnK7QGg1QpVnnaxCs14wvUb62sio8XZmMzP2SjVaRJFCyJB3UwZ6L4oXMGMXSRsiKe8ZNTaa6iX69tx54CAAHBHoiReiq7E5T2VuR5v -``` - -* bond the node using the signature: -``` -./nym-cli --mnemonic mixnet operators mixnode bond --amount 100000000 --mix-port 1789 --version "1.1.13" --host "85.163.111.99" --identity-key "B6pWscxYb8sPAdKTci8zPy5AgMzn5Zx8KpWwQNCyUSU7" --location "nym-town" --sphinx-key "o6MmKHzRewpNzVwaV37ZX9G3BfK4AmfYvsQfyoyAFRk" --signature "2TujBZfer8r5QM639Yb8coD9xH6f5eXzjAT5dD7wMom9fH8D1u36d7UpPdVaaZrWsCynmYpobwMWqiMKr5kM6CprD" -``` - -### Bond a gateway -Bonding a mix node is a process that takes a few steps due to the need to sign a transaction with your nym address for replay attack protection. - -* generate a signature payload: -``` -./nym-cli mixnet operators gateway create-gateway-bonding-sign-payload - -# returns something like -97GEhgMrPTmQVZgHqJeqWmgQ154GLKqy8xNGtLkV8xy5xc1SuwsEnqjhtZVshBYK74n53fFkKbSrS6kxkBE3vUikbU76JZmLMFmfR7aaU2NdBnfTPPHP2nwb2hJiEueq4SvvtDtQckxv7ZJzdxyXHxUeDPhzbprxTff78U3NGNk4cg6Q2K4EFqishdaqToedsXAPvVCWNbC1iWVjEq8nJ95Eb3NJyi3KmXcNDy4i8ZXgZHu4v8F4htXq2vZUdBSbizdkNr1NRvEg6PGVQdTseyuN8JxD3yuvrqprPY2kvJaT2YiYLPgWxoQtbfwcpkX4PP1PvwuMg4W8EXhitMpM2WHqLDP5vgfDGxdDCmRS44pM8ya4hcQ4g3McHWxduGWdbCzNNEsX6oQw4LVFcWn4mhbXSgqHwNQMm2TQW6LatYZSwCczdhEwV2CXe36UGCUzozmm4nj9qfUtXqDzMrHAAS8kjbKaVNaVaRRKgauQrHnK7QGg1QpVnnaxCs14wvUb62sio8XZmMzP2SjVaRJFCyJB3UwZ6L4oXMGMXSRsiKe8ZNTaa6iX69tx54CAAHBHoiReiq7E5T2VuR5v -``` - -* sign this payload: -``` -./nym-gateway sign --id upgrade_test --contract-msg 97GEhgMrPTmQVZgHqJeqWmgQ154GLKqy8xNGtLkV8xy5xc1SuwsEnqjhtZVshBYK74n53fFkKbSrS6kxkBE3vUikbU76JZmLMFmfR7aaU2NdBnfTPPHP2nwb2hJiEueq4SvvtDtQckxv7ZJzdxyXHxUeDPhzbprxTff78U3NGNk4cg6Q2K4EFqishdaqToedsXAPvVCWNbC1iWVjEq8nJ95Eb3NJyi3KmXcNDy4i8ZXgZHu4v8F4htXq2vZUdBSbizdkNr1NRvEg6PGVQdTseyuN8JxD3yuvrqprPY2kvJaT2YiYLPgWxoQtbfwcpkX4PP1PvwuMg4W8EXhitMpM2WHqLDP5vgfDGxdDCmRS44pM8ya4hcQ4g3McHWxduGWdbCzNNEsX6oQw4LVFcWn4mhbXSgqHwNQMm2TQW6LatYZSwCczdhEwV2CXe36UGCUzozmm4nj9qfUtXqDzMrHAAS8kjbKaVNaVaRRKgauQrHnK7QGg1QpVnnaxCs14wvUb62sio8XZmMzP2SjVaRJFCyJB3UwZ6L4oXMGMXSRsiKe8ZNTaa6iX69tx54CAAHBHoiReiq7E5T2VuR5v -``` - -* bond the node using this signature: -``` -./nym-cli --mnemonic mixnet operators gateway bond --amount 100000000 --mix-port 1789 --version "1.1.13" --host "85.163.111.99" --identity-key "B6pWscxYb8sPAdKTci8zPy5AgMzn5Zx8KpWwQNCyUSU7" --location "nym-town" --sphinx-key "o6MmKHzRewpNzVwaV37ZX9G3BfK4AmfYvsQfyoyAFRk" --signature "2TujBZfer8r5QM639Yb8coD9xH6f5eXzjAT5dD7wMom9fH8D1u36d7UpPdVaaZrWsCynmYpobwMWqiMKr5kM6CprD" -``` - -### Un-bond a node - -Un-bond a mix node or gateway. -``` -./nym-cli mixnet operators gateway unbound --mnemonic -``` - -> The same command can be applied with a mix node. Just replace `gateway` with `mixnode`. - -### Upgrade a mix node - -Upgrade your node config. -``` -./nym-cli mixnet operators mixnode settings update-config --version -``` - -### Claim a vesting reward for a mixnode - -Claim rewards for a mix node bonded with locked tokens. - -``` -./nym-cli mixnet operators mixnode rewards vesting-claim --mnemonic -``` - -### Claim rewards - -``` -./nym-cli mixnet operators mixnode rewards --mnemonic -``` - -### Manage Mix node Settings - -Manage your mix node settings stored in the directory. - -``` -./nym-cli mixnet operators mixnode settings update-config --version -``` - -### Delegate Stake - -Delegate to a mix node. -``` -./nym-cli mixnet delegators delegate --amount –mix-id --mnemonic -``` - -### Un-delegate Stake - -Remove stake from a mix node. -``` -./nym-cli mixnet delegators undelegate --mix-id --mnemonic -``` - -### Query a reward for a delegator - -Claim rewards accumulated during the delegation of unlocked tokens. -``` -./nym-cli mixnet delegators rewards claim --mix-id --mnemonic -``` - - -### Signature Generation: Sign a message - -Sign a message. -``` -./nym-cli signature sign --mnemonic - -# Result: -{"account_id":,"public_key":{"@type":"/cosmos.crypto.secp256k1.PubKey","key":},"signature":""} -``` - -### Signature Generation: Verify a signature - -Verify a signature. -``` -./nym-cli signature verify --mnemonic -``` - -### Create a Vesting Schedule - -Creates a vesting schedule for an account in the [vesting smart contract](../nyx/vesting-contract.md). - -``` -./nym-cli vesting-schedule create --mnemonic --address
--amount -``` - -### Query a Vesting Schedule - -Query for vesting schedule in the [vesting smart contract](../nyx/vesting-contract.md). - -``` -./nym-cli vesting-schedule query --mnemonic -``` - - -## Staking on someone's behalf (for custodians) - -There is a limitation the staking address can only perform the following actions (and are visible via the Nym Wallet: - -- Bond on the gateway's or mix node's behalf. -- Delegate or Un-delegate (to a mix node in order to begin receiving rewards) -- Claiming the rewards on the account - -```admonish note title="" -The staking address has no ability to withdraw any coins from the parent's account. -``` - -The staking address must maintain the same level of security as the parent mnemonic; while the parent mnemonic's delegations and bonding events will be visible to the parent owner, the staking address will be the only account capable of undoing the bonding and delegating from the mix nodes or gateway. - -Query for staking on behalf of someone else -``` -./nym-cli --mnemonic mixnet delegators delegate --mix-id --identity-key --amount -``` diff --git a/documentation/old_docs/docs/src/wallet/cli-wallet.md b/documentation/old_docs/docs/src/wallet/cli-wallet.md deleted file mode 100644 index a619564672..0000000000 --- a/documentation/old_docs/docs/src/wallet/cli-wallet.md +++ /dev/null @@ -1,8 +0,0 @@ -# CLI Wallet - -If you have already read our validator setup and maintenance [documentation](https://nymtech.net/operators/nodes/validator-setup.html) you will have seen that we compile and use the `nyxd` binary primarily for our validators. This binary can however be used for many other tasks, such as creating and using keypairs for wallets, or automated setups that require the signing and broadcasting of transactions. - -### 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](../nyx/interacting-with-chain.md) page. diff --git a/documentation/old_docs/docs/src/wallet/desktop-wallet.md b/documentation/old_docs/docs/src/wallet/desktop-wallet.md deleted file mode 100644 index e23b8dbcc1..0000000000 --- a/documentation/old_docs/docs/src/wallet/desktop-wallet.md +++ /dev/null @@ -1,185 +0,0 @@ -# Desktop Wallet - - -The Nym Desktop Wallet lets you interact with your Nym node and to delegate stake to others, see the vesting schedule of tokens, and transfer tokens. In future releases, it will also let you access the Nym mixnet. - -You can download it for Mac, Windows, or Linux. - -[![download nym wallet](../images/download-wallet.png)](https://nymtech.net/download/wallet) - -### Bypassing security warnings - -On Windows you will see a security warning pop up when you attempt to run the wallet. We are in the process of getting app store keys from Microsoft so that this doesn't happen. See the section below for details on steps to bypass these. - -#### Linux - -You will need to `chmod +x` the AppImage in the terminal (or give it execute permission in your file browser) before it will run. - -#### Windows - -_You will still encounter warnings when opening the wallet on Windows. This is because - although the wallet is approved by Microsoft - it has less than 10 thousand downloads at the current time. Once the wallet has passed this threshold, this warning will disappear._ - -Follow the steps below to bypass the warnings. - -* Select more-info after clicking the msi installer app: - -![Windows Warning](../images/wallet-warnings/windows_warningv1-0-2.png) - -* Proceed to 'run-anyway': - -![Windows Warning](../images/wallet-warnings/windows_warning2.png) - -* Follow the installer instructions: - -![Windows Warning](../images/wallet-warnings/windows_warning3.png) - -![Windows Warning](../images/wallet-warnings/windows_warning4.png) - -![Windows Warning](../images/wallet-warnings/windows_warning5.png) - -### For developers - -If you would like to the compile the wallet yourself, follow the instructions below. - -> Please note that the wallet has currently only been built on the operating systems for which there are binaries as listed above. If you find an issue or any additional prerequisties, please create an issue or PR against `develop` on [Github](https://github.com/nymtech/docs). - -#### Software prerequisites for building the wallet - -- `git` - -``` -sudo apt update -sudo apt install git -``` - -Verify `git` is installed with: - -``` -git version -# Should return: git version X.Y.Z -``` - -- [Yarn](https://yarnpkg.com/) - -- `NodeJS >= v16.8.0` - -- `Rust & cargo >= v1.56` - -We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old. - -If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms. - -#### Additional prerequisites for Ubuntu/Debian systems - -``` -sudo apt update -sudo apt install pkg-config build-essential libssl-dev curl jq -``` - -#### Additional prerequisites for Windows - -- When running on Windows you will need to install the `c++` build tools. -- An easy guide to get Rust up and running can be found [here](http://kennykerr.ca/2019/11/18/rust-getting-started/). -- When installing `NodeJS` please use the `current features` version. -- Using a package manager like [Chocolatey](https://chocolatey.org/) is recommended. - -### Removing signing errors when building in development mode - -If you're wanting to build the wallet yourself, you will need to make a few modifications to the file located at `nym-wallet/src-tauri/tauri.conf.json` before doing so. These relate to the wallet being accepted by Mac and Windows app stores, and so aren't relevant to you when building and running the wallet yourself. - -On **all** operating systems: -* set the value of line 49 to `false` -* remove lines 50 to 54 - -As well as these modifications for MacOS and Windows users: -* MacOS users must also remove line 39 -* Windows users must remove lines 42 to 46 - -### Installation -Once you have made these modifications to `tauri.conf.json`, inside of the `nym-wallet` folder, run: - -``` -yarn install -``` - -### Running in Development Mode - -> Make sure you copy over the contents of the provided `.env.sample` to a new `.env` file before proceeding - -You can run the wallet without having to install it in development mode by running the following terminal command from the `nym-wallet` folder - -``` -yarn dev -``` - -This will then start the Wallet GUI and produce a binary in `nym-wallet/target/debug/` named `nym-wallet`. - -### Running in Production Mode - -> Make sure you copy over the contents of the provided `.env.sample` to a new `.env` file before proceeding - -To build and install the wallet, run the following terminal command from the `nym-wallet` folder. - -``` -yarn build -``` - -This will build an executable file that you can use to install the wallet on your machine. The output will compile different types of binaries dependent on your hardware / OS system. Once the binaries are built, they can be located as follows: - -``` -Binary output directory structure -**macos** -| -└─── target/release -| |─ nym-wallet -└───target/release/bundle/dmg -│ │─ bundle_dmg.sh -│ │─ nym-wallet.*.dmg -└───target/release/bundle/macos/MacOs -│ │─ nym-wallet -| -**Linux** -└─── target/release -| │─ nym-wallet -└───target/release/bundle/appimage -│ │─ nym-wallet_*_.AppImage -│ │─ build_appimage.sh -└───target/release/bundle/deb -│ │─ nym-wallet_*_.deb -| -**Windows** -└─── target/release -| │─ nym-wallet.exe -└───target/release/bundle/msi -│ │─ nym-wallet_*_.msi -``` - -### Importing or creating account(s) when you have signed in with mnemonic -To import or create a new account, first you need to create a password for your wallet: - -1. Log out from the wallet -2. Sign in using "Sign in with mnemonic" button -3. On the next screen select “Create a password" -4. Type in the mnemonic you want to create a password for and follow the next steps -5. Sign back in the wallet using your new password -6. Come back to this page to import or create new accounts - -### Importing or creating account(s) when you have signed in with mnemonic but a password already exists on your machine -To import or create a new account, you need to log in with your existing password or create a new password. - -> Creating a new password will overwrite any old one stored on your machine. Make sure you have saved any mnemonics associated with the password before creating a new one. - -1. Log out -2. Click on “Forgot password” -3. On the next screen select “Create new password” -4. Follow the instructions and create a new password -5. Sign in using your new password - -### CLI tool for wallet encrypted file (password) recovery: -The mnemonics that are stored in the local password protected file can also be decrypted and recovered through a simple CLI tool, `nym-wallet-recovery-cli`. - -``` -nym-wallet-recovery –file saved-wallet.json –password foo -``` - -The saved wallet file can be found in `$XDG_DATA_HOME` or `$HOME/.local/share` on Linux, `$HOME/Library/Application Support` on Mac, and `C:\Users\username\AppData\Local` on Windows. diff --git a/documentation/old_docs/docs/themes/css/chrome.css b/documentation/old_docs/docs/themes/css/chrome.css deleted file mode 100644 index e16262342c..0000000000 --- a/documentation/old_docs/docs/themes/css/chrome.css +++ /dev/null @@ -1,608 +0,0 @@ -/* CSS for UI elements (a.k.a. chrome) */ - -@import 'variables.css'; - -html { - scrollbar-color: var(--scrollbar) var(--bg); -} -#searchresults a, -.content a:link, -a:visited, -a > .hljs { - color: var(--links); -} - -/* - body-container is necessary because mobile browsers don't seem to like - overflow-x on the body tag when there is a tag. -*/ -#body-container { - /* - This is used when the sidebar pushes the body content off the side of - the screen on small screens. Without it, dragging on mobile Safari - will want to reposition the viewport in a weird way. - */ - overflow-x: clip; -} - -/* Menu Bar */ - -#menu-bar, -#menu-bar-hover-placeholder { - z-index: 101; - margin: auto calc(0px - var(--page-padding)); -} -#menu-bar { - position: relative; - display: flex; - flex-wrap: wrap; - background-color: var(--bg); - border-block-end-color: var(--bg); - border-block-end-width: 1px; - border-block-end-style: solid; -} -#menu-bar.sticky, -.js #menu-bar-hover-placeholder:hover + #menu-bar, -.js #menu-bar:hover, -.js.sidebar-visible #menu-bar { - position: -webkit-sticky; - position: sticky; - top: 0 !important; -} -#menu-bar-hover-placeholder { - position: sticky; - position: -webkit-sticky; - top: 0; - height: var(--menu-bar-height); -} -#menu-bar.bordered { - border-block-end-color: var(--table-border-color); -} -#menu-bar i, #menu-bar .icon-button { - position: relative; - padding: 0 8px; - z-index: 10; - line-height: var(--menu-bar-height); - cursor: pointer; - transition: color 0.5s; -} -@media only screen and (max-width: 420px) { - #menu-bar i, #menu-bar .icon-button { - padding: 0 5px; - } -} - -.icon-button { - border: none; - background: none; - padding: 0; - color: inherit; -} -.icon-button i { - margin: 0; -} - -.right-buttons { - margin: 0 15px; -} -.right-buttons a { - text-decoration: none; -} - -.left-buttons { - display: flex; - margin: 0 5px; -} -.no-js .left-buttons button { - display: none; -} - -.menu-title { - position: absolute; - left: 50%; - display: inline-block; - font-weight: 200; - font-size: 2.4rem; - line-height: var(--menu-bar-height); - text-align: center; - margin: 0; - flex: 1; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; -} -.js .menu-title { - cursor: pointer; -} - -.menu-bar, -.menu-bar:visited, -.nav-chapters, -.nav-chapters:visited, -.mobile-nav-chapters, -.mobile-nav-chapters:visited, -.menu-bar .icon-button, -.menu-bar a i { - color: var(--icons); -} - -.menu-bar i:hover, -.menu-bar .icon-button:hover, -.nav-chapters:hover, -.mobile-nav-chapters i:hover { - color: var(--icons-hover); -} - -/* Nav Icons */ - -.nav-chapters { - font-size: 2.5em; - text-align: center; - text-decoration: none; - - position: fixed; - top: 0; - bottom: 0; - margin: 0; - max-width: auto; - min-width: auto; - - display: flex; - justify-content: center; - align-content: center; - flex-direction: column; - - transition: color 0.5s, background-color 0.5s; -} - -.nav-chapters:hover { - text-decoration: none; - background-color: var(--theme-hover); - transition: background-color 0.15s, color 0.15s; -} - -.nav-wrapper { - margin-block-start: 50px; - display: none; -} - -.mobile-nav-chapters { - font-size: 2.5em; - text-align: center; - text-decoration: none; - width: 90px; - border-radius: 5px; - background-color: var(--sidebar-bg); -} - -/* Only Firefox supports flow-relative values */ -.previous { float: left; } -[dir=rtl] .previous { float: right; } - -/* Only Firefox supports flow-relative values */ -.next { - float: right; - right: var(--page-padding); -} -[dir=rtl] .next { - float: left; - right: unset; - left: var(--page-padding); -} - -/* Use the correct buttons for RTL layouts*/ -[dir=rtl] .previous i.fa-angle-left:before {content:"\f105";} -[dir=rtl] .next i.fa-angle-right:before { content:"\f104"; } - -@media only screen and (max-width: 1080px) { - .nav-wide-wrapper { display: none; } - .nav-wrapper { display: block; } -} - -/* sidebar-visible */ -@media only screen and (max-width: 1380px) { - #sidebar-toggle-anchor:checked ~ .page-wrapper .nav-wide-wrapper { display: none; } - #sidebar-toggle-anchor:checked ~ .page-wrapper .nav-wrapper { display: block; } -} - -/* Inline code */ - -:not(pre) > .hljs { - display: inline; - padding: 0.1em 0.3em; - border-radius: 3px; -} - -:not(pre):not(a) > .hljs { - color: var(--inline-code-color); - overflow-x: initial; -} - -a:hover > .hljs { - text-decoration: underline; -} - -pre { - position: relative; -} -pre > .buttons { - position: absolute; - z-index: 100; - right: 0px; - top: 2px; - margin: 0px; - padding: 2px 0px; - - color: var(--sidebar-fg); - cursor: pointer; - visibility: hidden; - opacity: 0; - transition: visibility 0.1s linear, opacity 0.1s linear; -} -pre:hover > .buttons { - visibility: visible; - opacity: 1 -} -pre > .buttons :hover { - color: var(--sidebar-active); - border-color: var(--icons-hover); - background-color: var(--theme-hover); -} -pre > .buttons i { - margin-inline-start: 8px; -} -pre > .buttons button { - cursor: inherit; - margin: 0px 5px; - padding: 3px 5px; - font-size: 14px; - - border-style: solid; - border-width: 1px; - border-radius: 4px; - border-color: var(--icons); - background-color: var(--theme-popup-bg); - transition: 100ms; - transition-property: color,border-color,background-color; - color: var(--icons); -} -@media (pointer: coarse) { - pre > .buttons button { - /* On mobile, make it easier to tap buttons. */ - padding: 0.3rem 1rem; - } - - .sidebar-resize-indicator { - /* Hide resize indicator on devices with limited accuracy */ - display: none; - } -} -pre > code { - display: block; - padding: 1rem; -} - -/* FIXME: ACE editors overlap their buttons because ACE does absolute - positioning within the code block which breaks padding. The only solution I - can think of is to move the padding to the outer pre tag (or insert a div - wrapper), but that would require fixing a whole bunch of CSS rules. -*/ -.hljs.ace_editor { - padding: 0rem 0rem; -} - -pre > .result { - margin-block-start: 10px; -} - -/* Search */ - -#searchresults a { - text-decoration: none; -} - -mark { - border-radius: 2px; - padding-block-start: 0; - padding-block-end: 1px; - padding-inline-start: 3px; - padding-inline-end: 3px; - margin-block-start: 0; - margin-block-end: -1px; - margin-inline-start: -3px; - margin-inline-end: -3px; - background-color: var(--search-mark-bg); - transition: background-color 300ms linear; - cursor: pointer; -} - -mark.fade-out { - background-color: rgba(0,0,0,0) !important; - cursor: auto; -} - -.searchbar-outer { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); -} - -#searchbar { - width: 100%; - margin-block-start: 5px; - margin-block-end: 0; - margin-inline-start: auto; - margin-inline-end: auto; - padding: 10px 16px; - transition: box-shadow 300ms ease-in-out; - border: 1px solid var(--searchbar-border-color); - border-radius: 3px; - background-color: var(--searchbar-bg); - color: var(--searchbar-fg); -} -#searchbar:focus, -#searchbar.active { - box-shadow: 0 0 3px var(--searchbar-shadow-color); -} - -.searchresults-header { - font-weight: bold; - font-size: 1em; - padding-block-start: 18px; - padding-block-end: 0; - padding-inline-start: 5px; - padding-inline-end: 0; - color: var(--searchresults-header-fg); -} - -.searchresults-outer { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); - border-block-end: 1px dashed var(--searchresults-border-color); -} - -ul#searchresults { - list-style: none; - padding-inline-start: 20px; -} -ul#searchresults li { - margin: 10px 0px; - padding: 2px; - border-radius: 2px; -} -ul#searchresults li.focus { - background-color: var(--searchresults-li-bg); -} -ul#searchresults span.teaser { - display: block; - clear: both; - margin-block-start: 5px; - margin-block-end: 0; - margin-inline-start: 20px; - margin-inline-end: 0; - font-size: 0.8em; -} -ul#searchresults span.teaser em { - font-weight: bold; - font-style: normal; -} - -/* Sidebar */ - -.sidebar { - position: fixed; - left: 0; - top: 0; - bottom: 0; - width: var(--sidebar-width); - font-size: 1em; - box-sizing: border-box; - -webkit-overflow-scrolling: touch; - overscroll-behavior-y: contain; - background-color: var(--sidebar-bg); - color: var(--sidebar-fg); -} -[dir=rtl] .sidebar { left: unset; right: 0; } -.sidebar-resizing { - -moz-user-select: none; - -webkit-user-select: none; - -ms-user-select: none; - user-select: none; -} -.no-js .sidebar, -.js:not(.sidebar-resizing) .sidebar { - transition: transform 0.3s; /* Animation: slide away */ -} -.sidebar code { - line-height: 2em; -} -.sidebar .sidebar-scrollbox { - overflow-y: auto; - position: absolute; - top: 0; - bottom: 0; - left: 0; - right: 0; - padding: 10px 10px; -} -.sidebar .sidebar-resize-handle { - position: absolute; - cursor: col-resize; - width: 0; - right: calc(var(--sidebar-resize-indicator-width) * -1); - top: 0; - bottom: 0; - display: flex; - align-items: center; -} - -.sidebar-resize-handle .sidebar-resize-indicator { - width: 100%; - height: 12px; - background-color: var(--icons); - margin-inline-start: var(--sidebar-resize-indicator-space); -} - -[dir=rtl] .sidebar .sidebar-resize-handle { - left: calc(var(--sidebar-resize-indicator-width) * -1); - right: unset; -} -.js .sidebar .sidebar-resize-handle { - cursor: col-resize; - width: calc(var(--sidebar-resize-indicator-width) - var(--sidebar-resize-indicator-space)); -} -/* sidebar-hidden */ -#sidebar-toggle-anchor:not(:checked) ~ .sidebar { - transform: translateX(calc(0px - var(--sidebar-width) - var(--sidebar-resize-indicator-width))); - z-index: -1; -} -[dir=rtl] #sidebar-toggle-anchor:not(:checked) ~ .sidebar { - transform: translateX(calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width))); -} -.sidebar::-webkit-scrollbar { - background: var(--sidebar-bg); -} -.sidebar::-webkit-scrollbar-thumb { - background: var(--scrollbar); -} - -/* sidebar-visible */ -#sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: translateX(calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width))); -} -[dir=rtl] #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: translateX(calc(0px - var(--sidebar-width) - var(--sidebar-resize-indicator-width))); -} -@media only screen and (min-width: 620px) { - #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: none; - margin-inline-start: calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width)); - } - [dir=rtl] #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: none; - } -} - -.chapter { - list-style: none outside none; - padding-inline-start: 0; - line-height: 2em; -} - -.chapter ol { - width: 100%; -} - -.chapter li { - display: flex; - color: var(--sidebar-non-existant); -} -.chapter li a { - display: block; - padding: 0; - text-decoration: none; - color: var(--sidebar-fg); -} - -.chapter li a:hover { - color: var(--sidebar-active); -} - -.chapter li a.active { - color: var(--sidebar-active); -} - -.chapter li > a.toggle { - cursor: pointer; - display: block; - margin-inline-start: auto; - padding: 0 10px; - user-select: none; - opacity: 0.68; -} - -.chapter li > a.toggle div { - transition: transform 0.5s; -} - -/* collapse the section */ -.chapter li:not(.expanded) + li > ol { - display: none; -} - -.chapter li.chapter-item { - line-height: 1.5em; - margin-block-start: 0.6em; -} - -.chapter li.expanded > a.toggle div { - transform: rotate(90deg); -} - -.spacer { - width: 100%; - height: 3px; - margin: 5px 0px; -} -.chapter .spacer { - background-color: var(--sidebar-spacer); -} - -@media (-moz-touch-enabled: 1), (pointer: coarse) { - .chapter li a { padding: 5px 0; } - .spacer { margin: 10px 0; } -} - -.section { - list-style: none outside none; - padding-inline-start: 20px; - line-height: 1.5em; -} - -/* Theme Menu Popup */ - -.theme-popup { - position: absolute; - left: 10px; - top: var(--menu-bar-height); - z-index: 1000; - border-radius: 4px; - font-size: 0.7em; - color: var(--fg); - background: var(--theme-popup-bg); - border: 1px solid var(--theme-popup-border); - margin: 0; - padding: 0; - list-style: none; - display: none; - /* Don't let the children's background extend past the rounded corners. */ - overflow: hidden; -} -[dir=rtl] .theme-popup { left: unset; right: 10px; } -.theme-popup .default { - color: var(--icons); -} -.theme-popup .theme { - width: 100%; - border: 0; - margin: 0; - padding: 2px 20px; - line-height: 25px; - white-space: nowrap; - text-align: start; - cursor: pointer; - color: inherit; - background: inherit; - font-size: inherit; -} -.theme-popup .theme:hover { - background-color: var(--theme-hover); -} - -.theme-selected::before { - display: inline-block; - content: "✓"; - margin-inline-start: -14px; - width: 14px; -} diff --git a/documentation/old_docs/docs/themes/css/general.css b/documentation/old_docs/docs/themes/css/general.css deleted file mode 100644 index df8c1d12d2..0000000000 --- a/documentation/old_docs/docs/themes/css/general.css +++ /dev/null @@ -1,234 +0,0 @@ -/* Base styles and content styles */ - -@import 'variables.css'; - -:root { - /* Browser default font-size is 16px, this way 1 rem = 10px */ - font-size: 70%; - color-scheme: var(--color-scheme); -} - -html { - font-family: "Open Sans", sans-serif; - color: var(--fg); - background-color: var(--bg); - text-size-adjust: none; - -webkit-text-size-adjust: none; -} - -body { - margin: 0; - font-size: 1.5rem; - overflow-x: hidden; -} - -code { - font-family: var(--mono-font) !important; - font-size: 0.9em; - direction: ltr !important; -} - -/* make long words/inline code not x overflow */ -main { - overflow-wrap: break-word; -} - -/* make wide tables scroll if they overflow */ -.table-wrapper { - overflow-x: auto; -} - -/* Don't change font size in headers. */ -h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { - font-size: unset; -} - -.left { float: left; } -.right { float: right; } -.boring { opacity: 0.6; } -.hide-boring .boring { display: none; } -.hidden { display: none !important; } - -h2, h3 { margin-block-start: 2.5em; } -h4, h5 { margin-block-start: 2em; } - -.header + .header h3, -.header + .header h4, -.header + .header h5 { - margin-block-start: 1em; -} - -h1:target::before, -h2:target::before, -h3:target::before, -h4:target::before, -h5:target::before, -h6:target::before { - display: inline-block; - content: "»"; - margin-inline-start: -30px; - width: 30px; -} - -/* This is broken on Safari as of version 14, but is fixed - in Safari Technology Preview 117 which I think will be Safari 14.2. - https://bugs.webkit.org/show_bug.cgi?id=218076 -*/ -:target { - /* Safari does not support logical properties */ - scroll-margin-top: calc(var(--menu-bar-height) + 0.5em); -} - -.page { - outline: 0; - padding: 0 var(--page-padding); - margin-block-start: calc(0px - var(--menu-bar-height)); /* Compensate for the #menu-bar-hover-placeholder */ -} -.page-wrapper { - box-sizing: border-box; - background-color: var(--bg); -} -.no-js .page-wrapper, -.js:not(.sidebar-resizing) .page-wrapper { - transition: margin-left 0.3s ease, transform 0.3s ease; /* Animation: slide away */ -} -[dir=rtl] .js:not(.sidebar-resizing) .page-wrapper { - transition: margin-right 0.3s ease, transform 0.3s ease; /* Animation: slide away */ -} - -.content { - overflow-y: auto; - padding: 0 10px; -} -.content main { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); -} -.content p { line-height: 1.45em; } -.content ol { line-height: 1.45em; } -.content ul { line-height: 1.45em; } -.content a { text-decoration: none; } -.content a:hover { text-decoration: underline; } -.content img, .content video { max-width: 100%; } -.content .header:link, -.content .header:visited { - color: var(--fg); -} -.content .header:link, -.content .header:visited:hover { - text-decoration: none; -} - -table { - margin: 0 auto; - border-collapse: collapse; -} -table td { - padding: 3px 20px; - border: 1px var(--table-border-color) solid; -} -table thead { - background: var(--table-header-bg); -} -table thead td { - font-weight: 700; - border: none; -} -table thead th { - padding: 3px 20px; -} -table thead tr { - border: 1px var(--table-header-bg) solid; -} -/* Alternate background colors for rows */ -table tbody tr:nth-child(2n) { - background: var(--table-alternate-bg); -} - - -blockquote { - margin: 20px 0; - padding: 0 20px; - color: var(--fg); - background-color: var(--quote-bg); - border-block-start: .1em solid var(--quote-border); - border-block-end: .1em solid var(--quote-border); -} - -.warning { - margin: 20px; - padding: 0 20px; - border-inline-start: 2px solid var(--warning-border); -} - -.warning:before { - position: absolute; - width: 3rem; - height: 3rem; - margin-inline-start: calc(-1.5rem - 21px); - content: "ⓘ"; - text-align: center; - background-color: var(--bg); - color: var(--warning-border); - font-weight: bold; - font-size: 2rem; -} - -blockquote .warning:before { - background-color: var(--quote-bg); -} - -kbd { - background-color: var(--table-border-color); - border-radius: 4px; - border: solid 1px var(--theme-popup-border); - box-shadow: inset 0 -1px 0 var(--theme-hover); - display: inline-block; - font-size: var(--code-font-size); - font-family: var(--mono-font); - line-height: 10px; - padding: 4px 5px; - vertical-align: middle; -} - -:not(.footnote-definition) + .footnote-definition, -.footnote-definition + :not(.footnote-definition) { - margin-block-start: 2em; -} -.footnote-definition { - font-size: 0.9em; - margin: 0.5em 0; -} -.footnote-definition p { - display: inline; -} - -.tooltiptext { - position: absolute; - visibility: hidden; - color: #fff; - background-color: #333; - transform: translateX(-50%); /* Center by moving tooltip 50% of its width left */ - left: -8px; /* Half of the width of the icon */ - top: -35px; - font-size: 0.8em; - text-align: center; - border-radius: 6px; - padding: 5px 8px; - margin: 5px; - z-index: 1000; -} -.tooltipped .tooltiptext { - visibility: visible; -} - -.chapter li.part-title { - color: var(--sidebar-fg); - margin: 5px 0px; - font-weight: bold; -} - -.result-no-output { - font-style: italic; -} diff --git a/documentation/old_docs/docs/themes/css/variables.css b/documentation/old_docs/docs/themes/css/variables.css deleted file mode 100644 index 51b94cfc5a..0000000000 --- a/documentation/old_docs/docs/themes/css/variables.css +++ /dev/null @@ -1,287 +0,0 @@ - -/* Globals */ - -:root { - --sidebar-width: 280px; - --sidebar-resize-indicator-width: 8px; - --sidebar-resize-indicator-space: 2px; - --page-padding: 15px; - --content-max-width: 80%; - --menu-bar-height: 40px; - --mono-font: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace; - --code-font-size: 0.875em /* please adjust the ace font size accordingly in editor.js */ - --pagetoc-width: 13%; - --pagetoc-fontsize: 14.5px; -} - -@media only screen and (max-width:1439px) { - :root{ - --content-max-width: 98%; - } -} - -/* Themes */ - -.ayu { - --bg: hsl(210, 25%, 8%); - --fg: #c5c5c5; - - --sidebar-bg: #14191f; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #5c6773; - --sidebar-active: #ffb454; - --sidebar-spacer: #2d334f; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #b7b9cc; - - --links: #0096cf; - - --inline-code-color: #ffb454; - - --theme-popup-bg: #14191f; - --theme-popup-border: #5c6773; - --theme-hover: #191f26; - - --quote-bg: hsl(226, 15%, 17%); - --quote-border: hsl(226, 15%, 22%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(210, 25%, 13%); - --table-header-bg: hsl(210, 25%, 28%); - --table-alternate-bg: hsl(210, 25%, 11%); - - --searchbar-border-color: #848484; - --searchbar-bg: #424242; - --searchbar-fg: #fff; - --searchbar-shadow-color: #d4c89f; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #252932; - --search-mark-bg: #e3b171; - - --color-scheme: dark; -} - -.coal { - --bg: hsl(200, 7%, 8%); - --fg: #98a3ad; - - --sidebar-bg: #292c2f; - --sidebar-fg: #a1adb8; - --sidebar-non-existant: #505254; - --sidebar-active: #3473ad; - --sidebar-spacer: #393939; - - --scrollbar: var(--sidebar-fg); - - --icons: #43484d; - --icons-hover: #b3c0cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #141617; - --theme-popup-border: #43484d; - --theme-hover: #1f2124; - - --quote-bg: hsl(234, 21%, 18%); - --quote-border: hsl(234, 21%, 23%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(200, 7%, 13%); - --table-header-bg: hsl(200, 7%, 28%); - --table-alternate-bg: hsl(200, 7%, 11%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #b7b7b7; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #98a3ad; - --searchresults-li-bg: #2b2b2f; - --search-mark-bg: #355c7d; - - --color-scheme: dark; -} - -.light { - --bg: hsl(0, 0%, 100%); - --fg: hsl(0, 0%, 0%); - - --sidebar-bg: #fafafa; - --sidebar-fg: hsl(0, 0%, 0%); - --sidebar-non-existant: #aaaaaa; - --sidebar-active: #1f1fff; - --sidebar-spacer: #f4f4f4; - - --scrollbar: #8F8F8F; - - --icons: #747474; - --icons-hover: #000000; - - --links: #1f1fff; - - --inline-code-color: #F42C4C; - - --theme-popup-bg: #fafafa; - --theme-popup-border: #cccccc; - --theme-hover: #e6e6e6; - - --quote-bg: hsl(197, 37%, 96%); - --quote-border: hsl(197, 37%, 91%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(0, 0%, 95%); - --table-header-bg: hsl(0, 0%, 80%); - --table-alternate-bg: hsl(0, 0%, 97%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #fafafa; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #e4f2fe; - --search-mark-bg: #a2cff5; - - --color-scheme: light; -} - -.navy { - --bg: hsl(226, 23%, 11%); - --fg: #bcbdd0; - - --sidebar-bg: #282d3f; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #505274; - --sidebar-active: #2b79a2; - --sidebar-spacer: #2d334f; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #b7b9cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #161923; - --theme-popup-border: #737480; - --theme-hover: #282e40; - - --quote-bg: hsl(226, 15%, 17%); - --quote-border: hsl(226, 15%, 22%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(226, 23%, 16%); - --table-header-bg: hsl(226, 23%, 31%); - --table-alternate-bg: hsl(226, 23%, 14%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #aeaec6; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #5f5f71; - --searchresults-border-color: #5c5c68; - --searchresults-li-bg: #242430; - --search-mark-bg: #a2cff5; - - --color-scheme: dark; -} - -.rust { - --bg: hsl(60, 9%, 87%); - --fg: #262625; - - --sidebar-bg: #3b2e2a; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #505254; - --sidebar-active: #e69f67; - --sidebar-spacer: #45373a; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #262625; - - --links: #2b79a2; - - --inline-code-color: #6e6b5e; - - --theme-popup-bg: #e1e1db; - --theme-popup-border: #b38f6b; - --theme-hover: #99908a; - - --quote-bg: hsl(60, 5%, 75%); - --quote-border: hsl(60, 5%, 70%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(60, 9%, 82%); - --table-header-bg: #b3a497; - --table-alternate-bg: hsl(60, 9%, 84%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #fafafa; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #dec2a2; - --search-mark-bg: #e69f67; - - --color-scheme: light; -} - -@media (prefers-color-scheme: dark) { - .light.no-js { - --bg: hsl(200, 7%, 8%); - --fg: #98a3ad; - - --sidebar-bg: #292c2f; - --sidebar-fg: #a1adb8; - --sidebar-non-existant: #505254; - --sidebar-active: #3473ad; - --sidebar-spacer: #393939; - - --scrollbar: var(--sidebar-fg); - - --icons: #43484d; - --icons-hover: #b3c0cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #141617; - --theme-popup-border: #43484d; - --theme-hover: #1f2124; - - --quote-bg: hsl(234, 21%, 18%); - --quote-border: hsl(234, 21%, 23%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(200, 7%, 13%); - --table-header-bg: hsl(200, 7%, 28%); - --table-alternate-bg: hsl(200, 7%, 11%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #b7b7b7; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #98a3ad; - --searchresults-li-bg: #2b2b2f; - --search-mark-bg: #355c7d; - } -} diff --git a/documentation/old_docs/docs/themes/custom.css b/documentation/old_docs/docs/themes/custom.css deleted file mode 100644 index 0f4dd087bc..0000000000 --- a/documentation/old_docs/docs/themes/custom.css +++ /dev/null @@ -1,55 +0,0 @@ -:root { - --mono-font: Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace; -} - -.coal { - --fg: #f2f2f2; - --sidebar-fg: #f2f2f2; - --sidebar-active: #fb6e4e; - --icons-hover: #fb6e4e; - --links: #fb6e4e; - - ::selection { - color: #121726; - background-color: #c5573d; - } - - select option { - background-color: #121726; - } -} - -.light { - --sidebar-active: #fb6e4e; - --icons-hover: #fb6e4e; - --links: #fb6e4e; - - ::selection { - color: #f2f2f2; - background-color: #c5573d; - } -} - -/*properly centering the title given the additional header items*/ -.menu-title { - left: 45%; -} - -.menu-bar .a:hover, - -/*necessary because of ^*/ -.right-buttons { - position: absolute; - right: 0; -} - -select { - font-size: 16px; -} - -footer { - font-size: 0.8em; - text-align: center; - border-top: 1px solid black; - padding: 5px 0; -} diff --git a/documentation/old_docs/docs/themes/index.hbs b/documentation/old_docs/docs/themes/index.hbs deleted file mode 100644 index d0bb54d0c3..0000000000 --- a/documentation/old_docs/docs/themes/index.hbs +++ /dev/null @@ -1,358 +0,0 @@ - - - - - - {{ title }} - {{#if is_print }} - - {{/if}} - {{#if base_url}} - - {{/if}} - - - - {{> head}} - - - - - - {{#if favicon_svg}} - - {{/if}} - {{#if favicon_png}} - - {{/if}} - - - - {{#if print_enable}} - - {{/if}} - - - - {{#if copy_fonts}} - - {{/if}} - - - - - - - - {{#each additional_css}} - - {{/each}} - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
- -
- {{> header}} - - - - {{#if search_enabled}} - - {{/if}} - - - - -
-
-
-
- -
-
- - {{{ content }}} -
-
-
- - -
-
- - - -
- - {{#if live_reload_endpoint}} - - - {{/if}} - - {{#if playground_line_numbers}} - - {{/if}} - - {{#if playground_copyable}} - - {{/if}} - - {{#if playground_js}} - - - - - - {{/if}} - - {{#if search_js}} - - - - {{/if}} - - - - - - - {{#each additional_js}} - - {{/each}} - - {{#if is_print}} - {{#if mathjax_support}} - - {{else}} - - {{/if}} - {{/if}} - - -
- - diff --git a/documentation/old_docs/docs/themes/mdbook-admonish.css b/documentation/old_docs/docs/themes/mdbook-admonish.css deleted file mode 100644 index 45aeff0511..0000000000 --- a/documentation/old_docs/docs/themes/mdbook-admonish.css +++ /dev/null @@ -1,348 +0,0 @@ -@charset "UTF-8"; -:is(.admonition) { - display: flow-root; - margin: 1.5625em 0; - padding: 0 1.2rem; - color: var(--fg); - page-break-inside: avoid; - background-color: var(--bg); - border: 0 solid black; - border-inline-start-width: 0.4rem; - border-radius: 0.2rem; - box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1); -} -@media print { - :is(.admonition) { - box-shadow: none; - } -} -:is(.admonition) > * { - box-sizing: border-box; -} -:is(.admonition) :is(.admonition) { - margin-top: 1em; - margin-bottom: 1em; -} -:is(.admonition) > .tabbed-set:only-child { - margin-top: 0; -} -html :is(.admonition) > :last-child { - margin-bottom: 1.2rem; -} - -a.admonition-anchor-link { - display: none; - position: absolute; - left: -1.2rem; - padding-right: 1rem; -} -a.admonition-anchor-link:link, a.admonition-anchor-link:visited { - color: var(--fg); -} -a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover { - text-decoration: none; -} -a.admonition-anchor-link::before { - content: "§"; -} - -:is(.admonition-title, summary.admonition-title) { - position: relative; - min-height: 4rem; - margin-block: 0; - margin-inline: -1.6rem -1.2rem; - padding-block: 0.8rem; - padding-inline: 4.4rem 1.2rem; - font-weight: 700; - background-color: rgba(68, 138, 255, 0.1); - print-color-adjust: exact; - -webkit-print-color-adjust: exact; - display: flex; -} -:is(.admonition-title, summary.admonition-title) p { - margin: 0; -} -html :is(.admonition-title, summary.admonition-title):last-child { - margin-bottom: 0; -} -:is(.admonition-title, summary.admonition-title)::before { - position: absolute; - top: 0.625em; - inset-inline-start: 1.6rem; - width: 2rem; - height: 2rem; - background-color: #448aff; - print-color-adjust: exact; - -webkit-print-color-adjust: exact; - mask-image: url('data:image/svg+xml;charset=utf-8,'); - -webkit-mask-image: url('data:image/svg+xml;charset=utf-8,'); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-size: contain; - content: ""; -} -:is(.admonition-title, summary.admonition-title):hover a.admonition-anchor-link { - display: initial; -} - -details.admonition > summary.admonition-title::after { - position: absolute; - top: 0.625em; - inset-inline-end: 1.6rem; - height: 2rem; - width: 2rem; - background-color: currentcolor; - mask-image: var(--md-details-icon); - -webkit-mask-image: var(--md-details-icon); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-size: contain; - content: ""; - transform: rotate(0deg); - transition: transform 0.25s; -} -details[open].admonition > summary.admonition-title::after { - transform: rotate(90deg); -} - -:root { - --md-details-icon: url("data:image/svg+xml;charset=utf-8,"); -} - -:root { - --md-admonition-icon--admonish-note: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-abstract: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-info: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-tip: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-success: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-question: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-warning: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-failure: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-danger: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-bug: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-example: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-quote: url("data:image/svg+xml;charset=utf-8,"); -} - -:is(.admonition):is(.admonish-note) { - border-color: #448aff; -} - -:is(.admonish-note) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(68, 138, 255, 0.1); -} -:is(.admonish-note) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #448aff; - mask-image: var(--md-admonition-icon--admonish-note); - -webkit-mask-image: var(--md-admonition-icon--admonish-note); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-abstract, .admonish-summary, .admonish-tldr) { - border-color: #00b0ff; -} - -:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 176, 255, 0.1); -} -:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00b0ff; - mask-image: var(--md-admonition-icon--admonish-abstract); - -webkit-mask-image: var(--md-admonition-icon--admonish-abstract); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-info, .admonish-todo) { - border-color: #00b8d4; -} - -:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 184, 212, 0.1); -} -:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00b8d4; - mask-image: var(--md-admonition-icon--admonish-info); - -webkit-mask-image: var(--md-admonition-icon--admonish-info); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-tip, .admonish-hint, .admonish-important) { - border-color: #00bfa5; -} - -:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 191, 165, 0.1); -} -:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00bfa5; - mask-image: var(--md-admonition-icon--admonish-tip); - -webkit-mask-image: var(--md-admonition-icon--admonish-tip); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-success, .admonish-check, .admonish-done) { - border-color: #00c853; -} - -:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 200, 83, 0.1); -} -:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00c853; - mask-image: var(--md-admonition-icon--admonish-success); - -webkit-mask-image: var(--md-admonition-icon--admonish-success); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-question, .admonish-help, .admonish-faq) { - border-color: #64dd17; -} - -:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(100, 221, 23, 0.1); -} -:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #64dd17; - mask-image: var(--md-admonition-icon--admonish-question); - -webkit-mask-image: var(--md-admonition-icon--admonish-question); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-warning, .admonish-caution, .admonish-attention) { - border-color: #ff9100; -} - -:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 145, 0, 0.1); -} -:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff9100; - mask-image: var(--md-admonition-icon--admonish-warning); - -webkit-mask-image: var(--md-admonition-icon--admonish-warning); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-failure, .admonish-fail, .admonish-missing) { - border-color: #ff5252; -} - -:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 82, 82, 0.1); -} -:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff5252; - mask-image: var(--md-admonition-icon--admonish-failure); - -webkit-mask-image: var(--md-admonition-icon--admonish-failure); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-danger, .admonish-error) { - border-color: #ff1744; -} - -:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 23, 68, 0.1); -} -:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff1744; - mask-image: var(--md-admonition-icon--admonish-danger); - -webkit-mask-image: var(--md-admonition-icon--admonish-danger); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-bug) { - border-color: #f50057; -} - -:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(245, 0, 87, 0.1); -} -:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #f50057; - mask-image: var(--md-admonition-icon--admonish-bug); - -webkit-mask-image: var(--md-admonition-icon--admonish-bug); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-example) { - border-color: #7c4dff; -} - -:is(.admonish-example) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(124, 77, 255, 0.1); -} -:is(.admonish-example) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #7c4dff; - mask-image: var(--md-admonition-icon--admonish-example); - -webkit-mask-image: var(--md-admonition-icon--admonish-example); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-quote, .admonish-cite) { - border-color: #9e9e9e; -} - -:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(158, 158, 158, 0.1); -} -:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #9e9e9e; - mask-image: var(--md-admonition-icon--admonish-quote); - -webkit-mask-image: var(--md-admonition-icon--admonish-quote); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -.navy :is(.admonition) { - background-color: var(--sidebar-bg); -} - -.ayu :is(.admonition), -.coal :is(.admonition) { - background-color: var(--theme-hover); -} - -.rust :is(.admonition) { - background-color: var(--sidebar-bg); - color: var(--sidebar-fg); -} -.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited { - color: var(--sidebar-fg); -} diff --git a/documentation/old_docs/docs/themes/pagetoc.css b/documentation/old_docs/docs/themes/pagetoc.css deleted file mode 100644 index a68e5b8e21..0000000000 --- a/documentation/old_docs/docs/themes/pagetoc.css +++ /dev/null @@ -1,47 +0,0 @@ -/* src: https://github.com/JorelAli/mdBook-pagetoc */ - -@media only screen and (max-width:1439px) { - .sidetoc { - display: none; - } -} - -@media only screen and (min-width:1440px) { - main { - position: relative; - } - .sidetoc { - margin-left: auto; - margin-right: auto; - /* left: calc(90% + (var(--content-min-width))/4 - 110px); */ - left: 101%; - position: absolute; - font-size: var(--pagetoc-fontsize); - } - .pagetoc { - position: fixed; - width: var(--pagetoc-width); - } - .pagetoc a { - border-left: 1px solid var(--sidebar-bg); - /* color: var(--fg); */ - /* color: var(--sidebar-fg); */ - color: var(--links); - display: block; - padding-bottom: 5px; - padding-top: 5px; - padding-left: 10px; - text-align: left; - text-decoration: none; - font-weight: normal; - background: var(--sidebar-bg); - } - .pagetoc a:hover, - .pagetoc a.active { - background: var(--sidebar-bg); - /* color: var(--sidebar-fg); */ - color: var(--sidebar-active); - font-weight: bold; - font-size: var(--pagetoc-fontsize); - } -} diff --git a/documentation/old_docs/docs/themes/pagetoc.js b/documentation/old_docs/docs/themes/pagetoc.js deleted file mode 100644 index b11052427e..0000000000 --- a/documentation/old_docs/docs/themes/pagetoc.js +++ /dev/null @@ -1,68 +0,0 @@ -// src: https://github.com/JorelAli/mdBook-pagetoc - -// Un-active everything when you click it -Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.addEventHandler("click", function() { - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.classList.remove("active"); - }); - el.classList.add("active"); - }); -}); - -var updateFunction = function() { - - var id; - var elements = document.getElementsByClassName("header"); - Array.prototype.forEach.call(elements, function(el, i) { - if (window.pageYOffset >= el.offsetTop) { - id = el; - } - }); - - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.classList.remove("active"); - }); - - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - if (id.href.localeCompare(el.href) == 0) { - el.classList.add("active"); - } - }); -}; - -// Populate sidebar on load -window.addEventListener('load', function() { - var pagetoc = document.getElementsByClassName("pagetoc")[0]; - var elements = document.getElementsByClassName("header"); - Array.prototype.forEach.call(elements, function(el, i) { - var link = document.createElement("a"); - - // Indent shows hierarchy - var indent = ""; - switch (el.parentElement.tagName) { - case "H2": - indent = "20px"; - break; - case "H3": - indent = "40px"; - break; - case "H4": - indent = "60px"; - break; - default: - break; - } - - link.appendChild(document.createTextNode(el.text)); - link.style.paddingLeft = indent; - link.href = el.href; - pagetoc.appendChild(link); - }); - updateFunction.call(); -}); - - - -// Handle active elements on scroll -window.addEventListener("scroll", updateFunction); diff --git a/documentation/old_docs/operators/.gitignore b/documentation/old_docs/operators/.gitignore deleted file mode 100644 index 7585238efe..0000000000 --- a/documentation/old_docs/operators/.gitignore +++ /dev/null @@ -1 +0,0 @@ -book diff --git a/documentation/old_docs/operators/LICENSE b/documentation/old_docs/operators/LICENSE deleted file mode 100644 index 261eeb9e9f..0000000000 --- a/documentation/old_docs/operators/LICENSE +++ /dev/null @@ -1,201 +0,0 @@ - Apache License - Version 2.0, January 2004 - http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - "Contribution" shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, "submitted" - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but not limited to - communication on electronic mailing lists, source code control systems, - and issue tracking systems that are managed by, or on behalf of, the - Licensor for the purpose of discussing and improving the Work, but - excluding communication that is conspicuously marked or otherwise - designated in writing by the copyright owner as "Not a Contribution." - - "Contributor" shall mean Licensor and any individual or Legal Entity - on behalf of whom a Contribution has been received by Licensor and - subsequently incorporated within the Work. - - 2. Grant of Copyright License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - copyright license to reproduce, prepare Derivative Works of, - publicly display, publicly perform, sublicense, and distribute the - Work and such Derivative Works in Source or Object form. - - 3. Grant of Patent License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - (except as stated in this section) patent license to make, have made, - use, offer to sell, sell, import, and otherwise transfer the Work, - where such license applies only to those patent claims licensable - by such Contributor that are necessarily infringed by their - Contribution(s) alone or by combination of their Contribution(s) - with the Work to which such Contribution(s) was submitted. If You - institute patent litigation against any entity (including a - cross-claim or counterclaim in a lawsuit) alleging that the Work - or a Contribution incorporated within the Work constitutes direct - or contributory patent infringement, then any patent licenses - granted to You under this License for that Work shall terminate - as of the date such litigation is filed. - - 4. Redistribution. You may reproduce and distribute copies of the - Work or Derivative Works thereof in any medium, with or without - modifications, and in Source or Object form, provided that You - meet the following conditions: - - (a) You must give any other recipients of the Work or - Derivative Works a copy of this License; and - - (b) You must cause any modified files to carry prominent notices - stating that You changed the files; and - - (c) You must retain, in the Source form of any Derivative Works - that You distribute, all copyright, patent, trademark, and - attribution notices from the Source form of the Work, - excluding those notices that do not pertain to any part of - the Derivative Works; and - - (d) If the Work includes a "NOTICE" text file as part of its - distribution, then any Derivative Works that You distribute must - include a readable copy of the attribution notices contained - within such NOTICE file, excluding those notices that do not - pertain to any part of the Derivative Works, in at least one - of the following places: within a NOTICE text file distributed - as part of the Derivative Works; within the Source form or - documentation, if provided along with the Derivative Works; or, - within a display generated by the Derivative Works, if and - wherever such third-party notices normally appear. The contents - of the NOTICE file are for informational purposes only and - do not modify the License. You may add Your own attribution - notices within Derivative Works that You distribute, alongside - or as an addendum to the NOTICE text from the Work, provided - that such additional attribution notices cannot be construed - as modifying the License. - - You may add Your own copyright statement to Your modifications and - may provide additional or different license terms and conditions - for use, reproduction, or distribution of Your modifications, or - for any such Derivative Works as a whole, provided Your use, - reproduction, and distribution of the Work otherwise complies with - the conditions stated in this License. - - 5. Submission of Contributions. Unless You explicitly state otherwise, - any Contribution intentionally submitted for inclusion in the Work - by You to the Licensor shall be under the terms and conditions of - this License, without any additional terms or conditions. - Notwithstanding the above, nothing herein shall supersede or modify - the terms of any separate license agreement you may have executed - with Licensor regarding such Contributions. - - 6. Trademarks. This License does not grant permission to use the trade - names, trademarks, service marks, or product names of the Licensor, - except as required for reasonable and customary use in describing the - origin of the Work and reproducing the content of the NOTICE file. - - 7. Disclaimer of Warranty. Unless required by applicable law or - agreed to in writing, Licensor provides the Work (and each - Contributor provides its Contributions) on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - implied, including, without limitation, any warranties or conditions - of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A - PARTICULAR PURPOSE. You are solely responsible for determining the - appropriateness of using or redistributing the Work and assume any - risks associated with Your exercise of permissions under this License. - - 8. Limitation of Liability. In no event and under no legal theory, - whether in tort (including negligence), contract, or otherwise, - unless required by applicable law (such as deliberate and grossly - negligent acts) or agreed to in writing, shall any Contributor be - liable to You for damages, including any direct, indirect, special, - incidental, or consequential damages of any character arising as a - result of this License or out of the use or inability to use the - Work (including but not limited to damages for loss of goodwill, - work stoppage, computer failure or malfunction, or any and all - other commercial damages or losses), even if such Contributor - has been advised of the possibility of such damages. - - 9. Accepting Warranty or Additional Liability. While redistributing - the Work or Derivative Works thereof, You may choose to offer, - and charge a fee for, acceptance of support, warranty, indemnity, - or other liability obligations and/or rights consistent with this - License. However, in accepting such obligations, You may act only - on Your own behalf and on Your sole responsibility, not on behalf - of any other Contributor, and only if You agree to indemnify, - defend, and hold each Contributor harmless for any liability - incurred by, or claims asserted against, such Contributor by reason - of your accepting any such warranty or additional liability. - - END OF TERMS AND CONDITIONS - - APPENDIX: How to apply the Apache License to your work. - - To apply the Apache License to your work, attach the following - boilerplate notice, with the fields enclosed by brackets "[]" - replaced with your own identifying information. (Don't include - the brackets!) The text should be enclosed in the appropriate - comment syntax for the file format. We also recommend that a - file or class name and description of purpose be included on the - same "printed page" as the copyright notice for easier - identification within third-party archives. - - Copyright [yyyy] [name of copyright owner] - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. diff --git a/documentation/old_docs/operators/book.toml b/documentation/old_docs/operators/book.toml deleted file mode 100644 index 587ba8fe3b..0000000000 --- a/documentation/old_docs/operators/book.toml +++ /dev/null @@ -1,112 +0,0 @@ -[book] -title = "Nym Operators Guide" -authors = ["Max Hampshire, Serinko, Alexia Lorenza Martinel"] -description = "Everything needed to run Nym Mixnet components" -language = "en" -multilingual = false # for the moment - ideally work on chinese, brazillian portugese, spanish next -src = "src" - -[rust] -edition = "2018" - -################# -# PREPROCESSORS # -################# - -[preprocessor.theme] -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`. -# this is because of a bug in the `mdbook-theme` plugin -turn-off = true - -[preprocessor.admonish] -command = "mdbook-admonish" -assets_version = "3.0.2" # do not edit: managed by `mdbook-admonish install` - -# https://gitlab.com/tglman/mdbook-variables/ -[preprocessor.variables.variables] -minimum_rust_version = "1.66" -wallet_release_version = "1.2.8" -performance_testing_webpage = "https://nymtech.net/events/fast-and-furious" -performance_validator = "http://validator.performance.nymte.ch/" -performance_testing_release = "v2024.2-fast-and-furious-v2" -# dependencies -prometheus_latest_version = "v2.50.1" -toc_page = "https://nymtech.net/terms-and-conditions/operators/v1.0.0" - -[preprocessor.last-changed] -command = "mdbook-last-changed" -renderer = ["html"] - -# used for grabbing output of binary commands for automation https://github.com/FauconFan/mdbook-cmdrun -[preprocessor.cmdrun] - -# more pre-processor plugins to look into from https://github.com/rust-lang/mdBook/wiki/Third-party-plugins & https://lib.rs/keywords/mdbook-preprocessor -# mdbook-i18n - -# [preprocessor.api-call] -# command = "$(tokens=$(curl -L https://api.nymtech.net/cosmos/staking/v1beta1/pool | jq 'values[\"pool\"][\"bonded_tokens\"]') && echo ${tokens:0:2},${tokens:2:2})" - -######### -# BUILD # -######### - -[build] -build-dir = "book" # the directory where the output is placed -create-missing = true # whether or not to create missing pages -use-default-preprocessors = true # use the default preprocessors -extra-watch-dirs = [] # directories to watch for triggering builds - -########## -# OUTPUT # -########## - -[output.html] -theme = "themes" -default-theme = "coal" -preferred-dark-theme = "coal" -#curly-quotes = true -smart-punctuation = true -copy-fonts = true -no-section-label = false -additional-css = [ - "./themes/custom.css", - "./themes/mdbook-admonish.css", - "./themes/pagetoc.css", -] -additional-js = ["./themes/pagetoc.js"] -git-repository-url = "https://github.com/nymtech/nym" -git-repository-icon = "fa-github" -input-404 = "not-found.md" - -[output.html.fold] -enable = true # whether or not to enable section folding -level = 0 # the depth to start folding - -# controlling rust sample code blocks -[output.html.playground] -editable = false # allows editing the source code -copyable = true # include the copy button for copying code snippets -copy-js = true # includes the JavaScript for the code editor -line-numbers = true # displays line numbers for editable code -runnable = true # displays a run button for rust code - -# options for the built in text search -[output.html.search] -enable = true # enables the search feature -limit-results = 30 # maximum number of search results -teaser-word-count = 30 # number of words used for a search result teaser -use-boolean-and = true # multiple search terms must all match -boost-title = 2 # ranking boost factor for matches in headers -boost-hierarchy = 1 # ranking boost factor for matches in page names -boost-paragraph = 1 # ranking boost factor for matches in text -expand = true # partial words will match longer terms -heading-split-level = 3 # link results to heading levels -copy-js = true # include Javascript code for search - -[output.linkcheck] -warning-policy = "warn" diff --git a/documentation/old_docs/operators/last-changed.css b/documentation/old_docs/operators/last-changed.css deleted file mode 100644 index 0c4228de32..0000000000 --- a/documentation/old_docs/operators/last-changed.css +++ /dev/null @@ -1,6 +0,0 @@ -footer { - font-size: 0.8em; - text-align: center; - border-top: 1px solid black; - padding: 5px 0; - } \ No newline at end of file diff --git a/documentation/old_docs/operators/src/SUMMARY.md b/documentation/old_docs/operators/src/SUMMARY.md deleted file mode 100644 index 85b394583e..0000000000 --- a/documentation/old_docs/operators/src/SUMMARY.md +++ /dev/null @@ -1,89 +0,0 @@ -# -# Summary - -- [Introduction](introduction.md) -- [Changelog](changelog.md) -- [Release Cycle](release-cycle.md) -- [Sandbox Testnet](sandbox.md) - -# Binaries - -- [Pre-built Binaries](binaries/pre-built-binaries.md) - -- [Building from Source](binaries/building-nym.md) - - -# Operators Guides - -- [Preliminary Steps](nodes/preliminary-steps.md) - - [Nym Wallet Preparation](nodes/wallet-preparation.md) - - [VPS Setup](nodes/vps-setup.md) -- [Nym Node](nodes/nym-node.md) - - [Setup & Run](nodes/setup.md) - - [Configuration](nodes/configuration.md) - - [WSS & Reversed Proxy](nodes/proxy-configuration.md) - - [Bonding](nodes/bonding.md) -- [Nyx Validator Setup](nodes/validator-setup.md) - - [Nym API Setup](nodes/nym-api.md) - - [Validator & API Configuration](nodes/nyx-configuration.md) -- [Maintenance](nodes/maintenance.md) - - [Manual Node Upgrade](nodes/manual-upgrade.md) - - [Automatic Node Upgrade: Nymvisor Setup and Usage](nodes/nymvisor-upgrade.md) -- [Performance Monitoring & Testing](testing/performance.md) - - - [Gateway Probe](testing/gateway-probe.md) - - [Node API Check](testing/node-api-check.md) - - [Prometheus & Grafana](testing/prometheus-grafana.md) - - [ExploreNYM scripts](testing/explorenym-scripts.md) - - - - -# Troubleshooting - -- [VPS Setup](troubleshooting/vps-isp.md) -- [Nym Node](troubleshooting/nodes.md) -- [Validators](troubleshooting/validators.md) - -# Token Economics - - - -- [Nyx: Validator Rewards](tokenomics/validator-rewards.md) - -# FAQ - -- [General Operators FAQ](faq/general-faq.md) -- [Nym Nodes](faq/nym-nodes-faq.md) -- [Nyx & Validators](faq/nyx-faq.md) - -# Community & Legal Forum - -- [Exit Gateway](legal/exit-gateway.md) -- [Community Counsel](legal/community-counsel.md) - - [ISP List](legal/isp-list.md) - - [Jurisdictions](legal/jurisdictions.md) - - [Switzerland](legal/swiss.md) - - [United States](legal/united-states.md) - - [Landing Pages](legal/landing-pages.md) -- [How to Add Info](legal/add-content.md) - ---- -# Archive - -- [Why archive?](archive/archive.md) -- [Mixnet Nodes Setup](archive/nodes/setup-guides.md) - - [Preliminary Steps](archive/nodes/initial-steps.md) - - [Mix Node](archive/nodes/mix-node-setup.md) - - [Gateway](archive/nodes/gateway-setup.md) - - [Network Requester](archive/nodes/network-requester-setup.md) -- [FAQ: Mix Nodes](archive/faq/mixnodes-faq.md) -- [FAQ: Project Smoosh](archive/faq/smoosh-faq.md) - - ---- -# Misc. -- [Code of Conduct](coc.md) -- [Terms & Conditions](toc.md) -- [Licensing](licensing.md) ---- diff --git a/documentation/old_docs/operators/src/archive/archive.md b/documentation/old_docs/operators/src/archive/archive.md deleted file mode 100644 index 58bfde316e..0000000000 --- a/documentation/old_docs/operators/src/archive/archive.md +++ /dev/null @@ -1,7 +0,0 @@ -# Archived Pages - -This section contains old but still relevant pages/guides, archived for backwards compatibility. The content of the pages is not updated. See the top of every page informing you about the last time of update. - -Pages listed in archive section will eventually be terminated as they will become completely irrelevant with time. - - diff --git a/documentation/old_docs/operators/src/archive/faq/mixnodes-faq.md b/documentation/old_docs/operators/src/archive/faq/mixnodes-faq.md deleted file mode 100644 index b893ae5d8a..0000000000 --- a/documentation/old_docs/operators/src/archive/faq/mixnodes-faq.md +++ /dev/null @@ -1,97 +0,0 @@ -# Frequently Asked Questions - -```admonish warning -**This is an archived page for backwards compatibility. The content of this page is not updated since April 19th 2024. Eventually this page will be terminated!** -``` - -## Nym Mixnet - -To see different stats about Nym Mixnet live, we recommend you to visit [status.notrustverify.ch](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1) built by [No Trust Verify](https://notrustverify.ch/) crew, one of the squads within Nym core community. - - - - -### Is there an explorer for Nym Mixnet? - -Yes, there are several places, some are built by Nym core community: - -* [Nym Explorer](https://explorer.nymtech.net/) -* [Guru Explorer](https://mixnet.explorers.guru/) -* [ExploreNYM](https://explorenym.net/) - -### What determines the rewards when running a Mix Node? - -The stake required for a Mix Node to achieve maximum rewards is called Mix Node saturation point. This is calculated from the staking supply (all circulating supply + part of unlocked tokens). The target level of staking is to have 40% of the staking supply locked in Mix Nodes. - -The node stake saturation point, which we denote by Nsat, is given by the stake supply, target level of staking divided between the rewarded nodes. - -This design ensures the nodes aim to have a same size of stake (reputation) which can be done by delegation staking, as well as it secures a whale prevention and decentralization of staking, as any higher level of delegated $NYM than Nsat per node results in worsening reward ratio. On the contrary, the more Mix Nodes are active, the lower is Nsat. The equilibrium is reached when the staked tokens are delegated equally across the active Mix nodes and that's our basis for this incentive system. - - - - -The rewarded nodes are the nodes which will receive some rewards by the end of the given epoch. These can be separated further separated into: - -1. Active: Top *N* nodes of the rewarded set (currently all of them but this can change), these are nodes which are used by the clients and mix packets. - -2. Standby: Bottom *N* nodes of the rewarded set, they don't mix data from the clients but are used for testing. Their reward is smaller. - -For more detailed calculation, read our blog post [Nym Token Economics update](https://blog.nymtech.net/nym-token-economics-update-fedff0ed5267). More info on staking can be found [here](https://blog.nymtech.net/staking-in-nym-introducing-mainnet-mixmining-f9bb1cbc7c36). And [here](https://blog.nymtech.net/want-to-stake-in-nym-here-is-how-to-choose-a-mix-node-to-delegate-nym-to-c3b862add165) is more info on how to choose a Mix Node for delegation. And finally an [update](https://blog.nymtech.net/quarterly-token-economic-parameter-update-b2862948710f) on token economics from July 2023. - - - -*More graphs and stats at [stats.notrustverify.ch](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1&from=1703074861988&to=1705666862004).* - -### Which VPS providers would you recommend? - -Consider in which jurisdiction you reside and where do you want to run a Mix Node. Do you want to pay by crypto or not and what are the other important particularities for your case? We always recommend operators to try to choose smaller and decentralised VPS providers over the most known ones controlling a majority of the internet. We receive some good feedback on these: Linode, Ghandi, Flokinet and Exoscale. Do your own research and share with the community. - -### Why is a mix node setup on a self-hosted machine so tricky? - -We don't recommend this setup because it's really difficult to get a static IP and route IPv6 traffic. - -### What's the Sphinx packet size? - -The sizes are shown in the configs [here](https://github.com/nymtech/nym/blob/1ba6444e722e7757f1175a296bed6e31e25b8db8/common/nymsphinx/params/src/packet_sizes.rs#L12) (default is the one clients use, the others are for research purposes, not to be used in production as this would fragment the anonymity set). More info can be found [here](https://github.com/nymtech/nym/blob/4844ac953a12b29fa27688609ec193f1d560c996/common/nymsphinx/anonymous-replies/src/reply_surb.rs#L80). - -### Why a Mix Node and a Gateway cannot be bonded with the same wallet? - -Because of the way the smart contract works we keep it one-node one-address at the moment. - -### Which nodes are the most needed to be setup to strengthen Nym infrastructure and which ones bring rewards? - -Ath this point the most crutial component needed are [Exit Gateways](../../legal/exit-gateway.md). - -### Are Mix Nodes whitelisted? - -Nope, anyone can run a Mix Node. Purely reliant on the node's reputation (self stake + delegations) & routing score. - -## Validators and tokens - -### What's the difference between NYM and uNYM? - -1 NYM = 1 000 000 uNYM - - - -### Why some Nyx blockchain operations take one hour and others are instant? - -This is based on the definition in [Nym's CosmWasm](https://github.com/nymtech/nym/tree/develop/common/cosmwasm-smart-contracts) smart contracts code. - -Whatever is defined as [a pending epoch event](https://github.com/nymtech/nym/blob/b07627d57e075b6de35b4b1a84927578c3172811/common/cosmwasm-smart-contracts/mixnet-contract/src/pending_events.rs#L35-L103) will get resolved at the end of the current epoch. - -And whatever is defined as [a pending interval event](https://github.com/nymtech/nym/blob/b07627d57e075b6de35b4b1a84927578c3172811/common/cosmwasm-smart-contracts/mixnet-contract/src/pending_events.rs#L145-L172) will get resolved at the end of the current interval. - -### Can I run a validator? - -We are currently working towards building up a closed set of reputable validators. You can ask us for coins to get in, but please don't be offended if we say no - validators are part of our system's core security and we are starting out with people we already know or who have a solid reputation. - -### Why is validator set entry whitelisted? - -We understand that the early days of the Nyx blockchain will face possible vulnerabilities in terms of size - easy to disrupt or halt the chain if a malicious party entered with a large portion of stake. Besides that, there are some legal issues we need to address before we can distribute the validator set in a fully permissions fashion. - -### Why does Nym do airdrops? - -It is part of ensuring decentralisation - we need to avoid a handful of people having too much control over the token and market. Of course ideally people will stake the tokens and contribute to the project at this stage. We run surveys to better understand what people are doing with their tokens and what usability issues there are for staking. Any feedback is appreciated as it helps us improve all aspects of using the token and participating in the ecosystem. diff --git a/documentation/old_docs/operators/src/archive/faq/smoosh-faq.md b/documentation/old_docs/operators/src/archive/faq/smoosh-faq.md deleted file mode 100644 index 05c1967d68..0000000000 --- a/documentation/old_docs/operators/src/archive/faq/smoosh-faq.md +++ /dev/null @@ -1,108 +0,0 @@ -# Project Smoosh - FAQ - -```admonish warning -**This is an archived page for backwards compatibility. We have switched to [`nym-node` binary](../../nodes/nym-node.md), please [migrate](../../nodes/setup.md#migrate) your nodes. The content of this page is not updated since April 26th 2024. Eventually this page will be terminated!** -``` - -> We aim on purpose to make minimal changes to reward scheme and software. We're just 'smooshing' together stuff we already debugged and know works. -> -- Harry Halpin, Nym CEO - -
- -This page refer to the changes which are planned to take place over Q3 and Q4 2023. As this is a transition period in the beginning (Q3 2023) the [Mix Nodes FAQ page](mixnodes-faq.md) holds more answers to the current setup as project Smoosh refers to the eventual setup. As project Smoosh gets progressively implemented the answers on this page will become to be more relevant to the current state and eventually this FAQ page will be merged with the still relevant parts of the main Mix Nodes FAQ page. - -If any questions are not answered or it's not clear for you in which stage project Smoosh is right now, please reach out in Node Operators [Matrix room](https://matrix.to/#/#operators:nymtech.chat). - - -### What are the changes? - -Project Smoosh will have four steps, please follow the table below to track the dynamic progress: - -| **Step** | **Status** | -| :--- | :--- | -| **1.** Combine the `nym-gateway` and `nym-network-requester` into one binary | ✅ done | -| **2.** Create [Exit Gateway](../../legal/exit-gateway.md): Take the `nym-gateway` binary including `nym-network-requester` combined in \#1 and switch from [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) to a new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) | ✅ done | -| **3.** Combine all the nodes in the Nym Mixnet into one binary, that is `nym-mixnode`, `nym-gateway` (entry and exit) and `nym-network-requester`. | ✅ done | -| **4.** Adjust reward scheme to incentivise and reward Exit Gateways as a part of `nym-node` binary, implementing [zkNym credentials](https://youtu.be/nLmdsZ1BsQg?t=1717). | 🛠️ in progress | -| **5.** Implement multiple node functionalities into one `nym-node` connected to one Nyx account. | 🛠️ in progress | - -These steps will be staggered over time - period of several months, and will be implemented one by one with enough time to take in feedback and fix bugs in between. -Generally, the software will be the same, just instead of multiple binaries, there will be one Nym Node (`nym-node`) binary. Delegations will remain on as they are now, per our token economics (staking, saturation etc) - -### What does it mean for Nym nodes operators? - -We are exploring two potential methods for implementing binary functionality in practice and will provide information in advance. The options are: - -1. Make a selection button (command/argument/flag) for operators to choose whether they want their node to provide all or just some of the functions nodes have in the Nym Mixnet. Nodes functioning as Exit Gateways (in that epoch) will then have bigger rewards due to their larger risk exposure and overhead work with the setup. - -2. All nodes will be required to have the Exit Gateway functionality. All nodes are rewarded the same as now, and the difference is that a node sometimes (some epochs) may be performing as Exit Gateway sometimes as Mix node or Entry Gateway adjusted according the network demand by an algorithm. - -### Where can I read more about the Exit Gateway setup? - -We created an [entire page](../../legal/exit-gateway.md) about the technical and legal questions around Exit Gateway. - -### What is the change from allow list to deny list? - -The operators running Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays. The main change will be to expand the original short [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) to a more permissive setup. An [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) will constrain the hosts that the users of the Nym VPN and Mixnet can connect to. 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 VPN and Mixnet clients. - -### How will the Exit policy be implemented? - -Follow the dynamic progress of exit policy implementation on Gateways below: - -| **Step** | **Status** | -| :--- | :--- | -| **1.** By default the [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) filtering is disabled and the [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) filtering is going to continue be used. This is to prevent operators getting surprised by upgrading their Gateways (or Network Requesters) and suddenly be widely open to the internet. To enable the new exit policy, operators must use `--with-exit-policy` flag or modify the `config.toml` file. | ✅ done | -| **2.** The exit policy is part of the Gateway setup by default. To disable this exit policy, operators must use `--disable-exit-policy` flag. | ✅ done | -| **3.** The exit policy is the only option. The `allowed.list` is completely removed. | ✅ done | - -Keep in mind the table above only relates to changes happening on Gateways. For the Project Smoosh progress refer to the [table above](./smoosh-faq.md#what-are-the-changes). Whether Exit Gateway functionality will be optional or mandatory part of every active Nym Node depends on the chosen [design](./smoosh-faq.md#what-does-it-mean-for-nym-nodes-operators). - -### Can I run a Mix Node only? - -It depends which [design](./smoosh-faq.md#what-does-it-mean-for-nym-nodes-operators) will ultimately be used. In case of the first - yes. In case of the second option, all the nodes will be setup with Exit Gateway functionality turned on. - -## Token Economics & Rewards - -```admonish info -For any specifics on Nym token economics and Nym Mixnet reward system, please read the [Nym token economics paper](https://nymtech.net/nym-cryptoecon-paper.pdf). -``` - -### What are the incentives for the node operator? - -In the original setup there were no incentives to run a `nym-network-requester` binary. After the transition all the users will buy multiple tickets of zkNyms credentials and use those as [anonymous e-cash](https://arxiv.org/abs/2303.08221) to pay for their data traffic ([`Nym API`](https://github.com/nymtech/nym/tree/master/nym-api) will do the do cryptographical checks to prevent double-spending). All collected fees get distributed to all active nodes proportionally to their work by the end of each epoch. - -### How does this change the token economics? - -The token economics will stay the same as they are, same goes for the reward algorithm. - -### How are the rewards distributed? - -This depends on [design](./smoosh-faq.md#what-does-it-mean-for-nym-nodes-operators) chosen. In case of \#1, it will look like this: - -As each operator can choose what roles their nodes provide, the nodes which work as open Gateways will have higher rewards because they are the most important to keep up and stable. Besides that the operators of Gateways may be exposed to more complication and possible legal risks. - -The nodes which are initialized to run as Mix Nodes and Gateways will be chosen to be on top of the active set before the ones working only as a Mix Node. - -I case we go with \#2, all nodes active in the epoch will be rewarded proportionally according their work. - -In either way, Nym will share all the specifics beforehand. - -### How will be the staking and inflation after project Smoosh? - -Nym will run tests to count how much payment comes from the users of the Mixnet and if that covers the reward payments. If not, we may need to keep inflation on to secure incentives for high quality Gateways in the early stage of the transition. - -### When project smooth will be launched, it would be the mixmining pool that will pay for the Gateway rewards based on amount of traffic routed ? - -Yes, the same pool. Nym's aim is to do minimal modifications. The only real modification on the smart contract side will be to get into top X of 'active set' operators will need to have open Gateway function enabled. - -### What does this mean for the current delegators? - -From an operator standpoint, it shall just be a standard Nym upgrade, a new option to run the Gateway software on your node. Delegators should not have to re-delegate. - -## Legal Questions - -### Are there any legal concerns for the operators? - -So far the general line is that running a Gateway is not illegal (unless you are in Iran, China, and a few other places) and due to encryption/mixing less risky than running a normal VPN node. For Mix Nodes, it's very safe as they have "no idea" what packets they are mixing. - -There are several legal questions and analysis to be made for different jurisdictions. To be able to share resources and findings between the operators themselves we created a [Community Legal Forum](../../legal/exit-gateway.md). diff --git a/documentation/old_docs/operators/src/archive/nodes/gateway-setup.md b/documentation/old_docs/operators/src/archive/nodes/gateway-setup.md deleted file mode 100644 index 06b87fca1c..0000000000 --- a/documentation/old_docs/operators/src/archive/nodes/gateway-setup.md +++ /dev/null @@ -1,222 +0,0 @@ -# Gateways - -```admonish warning -**This is an archived page for backwards compatibility for existing node operators. To start a new node or migrate, follow the [`nym-node` guides](../../nodes/nym-node.md).** The content of this page is not updated since April 19th 2024. Eventually this page will be terminated! -``` - -> The Nym gateway was built in the [building nym](../../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. - - -```admonish info -As a result of [Project Smoosh](../faq/smoosh-faq.md), the current version of `nym-gateway` binary also contains `nym-network-requester` functionality which can be enabled [by the operator](./gateway-setup.md#initialising-gateway-with-network-requester). This combination is a basis of ***Nym Exit Gateway*** node - an essential piece in our new setup. Please read more in our [Project Smoosh FAQ](../faq/smoosh-faq.md) and [Exit Gateway](../../legal/exit-gateway.md) pages. We recommend operators begin to shift their setups to this new combined node, instead of operating two separate binaries. -``` - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -## Current version - -The last version before migration to [`nym-node`](../../nodes/nym-node.md) was `1.1.33`. - -## Preliminary steps - -Make sure you do the preparation listed in the [preliminary steps page](initial-steps.md) before setting up your Gateway. - - -## 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. - -To begin, move to `/target/release` directory from which you run the node commands: - -``` -cd target/release -``` - -### Viewing command help -You can check that your binaries are properly compiled with: - -``` -./nym-gateway --help -``` - -You can also check the various arguments required for individual commands with: - -``` -./nym-gateway --help -``` -> Adding `--no-banner` startup flag will prevent Nym banner being printed even if run in tty environment. - -## 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. - -```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). -``` - -```admonish info -There has been an ongoing development with dynamic upgrades. Follow the status of the Project Smoosh [changes](../faq/smoosh-faq.md#what-are-the-changes) and the progression state of exit policy [implementation](../faq/smoosh-faq.html#how-will-the-exit-policy-be-implemented) to be up to date with the current design. -``` - -**Note:** Due to the development towards Exit Gateway functionality the `--host` flag has been replaced with `--listening-address`, this is the IP address which is used for receiving sphinx packets and listening to client data. Another flag `--public-ips` is required; it’s a comma separated list of IP’s that are announced to the `nym-api`, it is usually the address which is used for bonding. - -### Initialising Exit Gateway - -An operator can initialise the Exit Gateway functionality by adding Network Requester with the new exit policy option: - -``` -./nym-gateway init --id --listening-address 0.0.0.0 --public-ips "$(curl -4 https://ifconfig.me)" --with-network-requester --with-exit-policy true -``` - - -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 - -#### Add Network Requester to an existing Gateway - -If you already [upgraded](../../nodes/manual-upgrade.md) your Gateway to the [latest version](./gateway-setup.md#current-version) and initialised without a Network Requester, you can easily change its functionality to Exit Gateway with a command `setup-network-requester`. - -See the options: - -``` -./nym-gateway setup-network-requester --help -``` - - -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 -``` - -Say we have a Gateway with `` as `new-gateway`, originally initialised and ran without the Exit Gateway functionality. To change the setup, run: - - -``` -./nym-gateway setup-network-requester --enabled true --with-exit-policy true --id new-gateway -``` - - -In case there are any unexpected problems, you can also change it manually by editing the Gateway config file stored in `/home/user/.nym/gateways//config/config.toml` where the line under `[network_requester]` needs to be edited from `false` to `true`. - -``` -[network_requester] -# Specifies whether Network Requester service is enabled in this process. -enabled = true -``` - -Save, exit and restart your Gateway. Now you are an operator of post-smooshed Exit Gateway. - -#### Enable Nym exit policy to an existing Gateway with Network Requester functionality - -In case you already added Network Requester functionality to your Gateway as described above but haven't enabled the [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) there is an easy tweak to do so and turn your node into [Nym Exit Gateway](../faq/smoosh-faq.md#what-are-the-changes). - -Open the config file stored at `.nym/gateways//config/network_requester_config.toml` and set: -```sh -use_deprecated_allow_list = false -``` -Save, exit and restart your Gateway. Now you are an operator of post-smooshed Exit gateway. - -```admonish info -All information about Network Requester part of your Exit Gateway is in `/home/user/.nym/gateways//config/network_requester_config.toml`. -``` - -For now you can run Gateway without Network Requester or with and without the new exit policy. This will soon change as we inform in our [Project Smoosh FAQ](../faq/smoosh-faq.html#how-will-the-exit-policy-be-implemented). - -To read more about the configuration like whitelisted outbound requesters in `allowed.list` and other useful information, see the page [*Network Requester whitelist*](network-requester-setup.md#using-your-network-requester). - - -#### Initialising Gateway without Network Requester - -In case you don't want to run your Gateway with the Exit Gateway functionality, you still can run a simple Gateway. - -To check available configuration options use: - -``` - ./nym-gateway init --help -``` - -The following command returns a Gateway on your current IP with the `` of `simple-gateway`: - -``` -./nym-gateway init --id simple-gateway --listening-address 0.0.0.0 --public-ips "$(curl -4 https://ifconfig.me)" -``` - -The `$(curl -4 https://ifconfig.me)` command above returns your IP automatically using an external service. Alternatively, you can enter your IP manually if you wish. If you do this, remember to enter your IP **without** any port information. - -## Running your Gateway - -The `run` command starts the Gateway: - -``` -./nym-gateway run --id -``` - - -## Bonding your Gateway - -```admonish info -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) - -You can bond your Gateway via the Desktop wallet. **Make sure your Gateway is running first**, then follow the steps below: - -1. Open your wallet, and head to the `Bonding` page, then select the node type `Gateway` and input your node details. Press `Next`. - -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: - -``` -./nym-gateway sign --id --contract-msg -``` - -It will look something like this (as `` we used `supergateway`): - -~~~admonish example collapsible=true title="Console output" -``` -./nym-gateway sign --id supergateway --contract-msg 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a - - - _ __ _ _ _ __ ___ - | '_ \| | | | '_ \ _ \ - | | | | |_| | | | | | | - |_| |_|\__, |_| |_| |_| - |___/ - - (nym-gateway - version v1.1.) - - ->>> attempting to sign 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a ->>> decoding the message... ->>> message to sign: {"nonce":0,"algorithm":"ed25519","message_type":"gateway-bonding","content":{"sender":"n1ewmme88q22l8syvgshqma02jv0vqrug9zq9dy8","proxy":null,"funds":[{"denom":"unym","amount":"100000000"}],"data":{"gateway":{"host":"62.240.134.189","mix_port":1789,"clients_port":9000,"location":"62.240.134.189","sphinx_key":"FKbuN7mPdoCG9jA3CkAfXxC5X4rHhqeMVtmfRtJ3cFZd","identity_key":"3RoAhR8gEdfBETMjm2vbMFzKddxXDdE9ygBAnJHWqSzD","version":"1.1.13"}}}} ->>> The base58-encoded signature is: -2SPDjLjX4b6XEtkgG7yD8Znsb1xycL1edFvRK4JcVnPsM9k6HXEUUeVS6rswRiYxoj1bMgiRKyPDwiksiuyxu8Xi -``` -~~~ - -* Copy the resulting signature: - -```sh -# >>> The base58-encoded signature is: -2SPDjLjX4b6XEtkgG7yD8Znsb1xycL1edFvRK4JcVnPsM9k6HXEUUeVS6rswRiYxoj1bMgiRKyPDwiksiuyxu8Xi -``` - -* And paste it into the wallet nodal, press `Next` and confirm the transaction. - -![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. - -> You are asked to `sign` a transaction on bonding so that the Mixnet smart contract is able to map your Nym address to your node. This allows us to create a nonce for each account and defend against replay attacks. - -### Via the CLI (power users) - -If you want to bond your Gateway via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#bond-a-mix-node) docs. - -## 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/old_docs/operators/src/archive/nodes/initial-steps.md b/documentation/old_docs/operators/src/archive/nodes/initial-steps.md deleted file mode 100644 index 88cf7c7512..0000000000 --- a/documentation/old_docs/operators/src/archive/nodes/initial-steps.md +++ /dev/null @@ -1,45 +0,0 @@ -# Preliminary Steps - -```admonish warning -**This is an archived page for backwards compatibility. The content of this page is not updated since April 19th 2024. Eventually this page will be terminated!** -``` - -> The Nym `mixnode`, `gateway` and `network-requester` binaries were built in the [building nym](../../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. - -There are a couple of steps that need completing before starting to set up your mix node, gateway or a network requester: - -- preparing your [desktop wallet](https://nymtech.net/docs/wallet/desktop-wallet.html) or [CLI wallet](https://nymtech.net/docs/wallet/cli-wallet.html). -- requisitioning a VPS (Virtual Private Server) - -### Wallet preparation -#### Mainnet -Before you initialise and run your mix node, head to our [website](https://nymtech.net/download/) and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren't available, you can build the wallet yourself with instructions [here](https://nymtech.net/docs/wallet/desktop-wallet.html). - -If you don't already have one, please create a Nym address using the wallet, and fund it with tokens. The minimum amount required to bond a mix node is 100 `NYM`, but make sure you have a bit more to account for gas costs. - -`NYM` can be purchased via Bity from the wallet itself with BTC or fiat, and is currently present on several [exchanges](https://www.coingecko.com/en/coins/nym#markets). - -> Remember that you can **only** use Cosmos `NYM` tokens to bond your mix node. You **cannot** use ERC20 representations of `NYM` to run a node. - - -#### Sandbox testnet -Make sure to download a wallet and create an account as outlined above. Then head to our [token faucet](https://faucet.nymtech.net/) and get some tokens to use to bond it. - -### VPS Hardware Specs -You will need to rent a VPS to run your node on. One key reason for this is that your node **must be able to send TCP data using both IPv4 and IPv6** (as other nodes you talk to may use either protocol). - -For the moment, we haven't put a great amount of effort into optimizing concurrency to increase throughput, so don't bother provisioning a beastly server with multiple cores. This will change when we get a chance to start doing performance optimizations in a more serious way. Sphinx packet decryption is CPU-bound, so once we optimize, more fast cores will be better. - -For now, see the below rough specs: - -- Processors: 2 cores are fine. Get the fastest CPUs you can afford. - -#### For mix node - -- RAM: Memory requirements are very low - typically a mix node may use only a few hundred MB of RAM. -- Disks: The mixnodes require no disk space beyond a few bytes for the configuration files. - -#### For Gateway - -- RAM: Memory requirements depend on the amount of users your Gateway will be serving at any one time. If you're just going to be using it yourself, then minimal RAM is fine. **If you're running your Gateway as part of a Service Grant, get something with at least 4GB RAM.** -- Disks: much like the amount of RAM your Gateway could use, the amount of disk space required will vary with the amount of users your Gateway is serving. **If you're running your Gateway as part of a Service Grant, get something with at least 40GB storage.** diff --git a/documentation/old_docs/operators/src/archive/nodes/mix-node-setup.md b/documentation/old_docs/operators/src/archive/nodes/mix-node-setup.md deleted file mode 100644 index ab21518d86..0000000000 --- a/documentation/old_docs/operators/src/archive/nodes/mix-node-setup.md +++ /dev/null @@ -1,243 +0,0 @@ -# Mix Nodes - -```admonish warning -**This is an archived page for backwards compatibility for existing node operators. To start a new node or migrate, follow the [`nym-node` guides](../../nodes/nym-node.md).** The content of this page is not updated since April 19th 2024. Eventually this page will be terminated! -``` - -> The Nym Mix Node binary was built in the [building nym](../../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -## Current version - -The last version before migration to [`nym-node`](../../nodes/nym-node.md) was `1.1.35`. - -The `nym-mix node` binary is currently one point version ahead of the rest of the platform binaries due to a patch applied between releases. - -## Preliminary steps - -Make sure you do the preparation listed in the [preliminary steps page](initial-steps.md) before setting up your Mix Node. - -## Mix node setup - -Now that you have built the [codebase](../../binaries/building-nym.md), set up your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html), and have a VPS with the `nym-mix node` binary, you can set up your Mix Node with the instructions below. - -To begin, move to `/target/release` directory from which you run the node commands: - -``` -cd target/release -``` - -### Viewing command help - -You can check that your binaries are properly compiled with: - -``` -./nym-mixnode --help -``` - -Which should return a list of all available commands. - -You can also check the various arguments required for individual commands with: - -``` -./nym-mixnode --help -``` - -> Adding `--no-banner` startup flag will prevent Nym banner being printed even if run in tty environment. - -### Initialising your Mix Node - -To check available configuration options for initializing your node use: - -``` -./nym-mixnode init --help -``` - -Initialise your Mix Node with the following command, replacing the value of `--id` with the moniker you wish to give your Mix Node. Your `--host` must be publicly routable on the internet in order to mix packets, and can be either an Ipv4 or IPv6 address. The `$(curl -4 https://ifconfig.me)` command returns your IP automatically using an external service. If you enter your IP address manually, enter it **without** any port information. - -``` -./nym-mixnode init --id --host $(curl -4 https://ifconfig.me) -``` - -> The `init` command will refuse to destroy existing Mix Node keys. - -During the `init` process you will have the option to change the `http_api`, `verloc` and `mixnode` ports from their default settings. If you wish to change these in the future you can edit their values in the `config.toml` file created by the initialization process, which is located at `~/.nym/mixnodes//`. - -## Node Description (optional) - -In order to easily identify your node via human-readable information later on, you can `describe` your Mix Node with the following command: - -``` -./nym-mixnode describe --id -``` -Node description is a short text that describes your node. It is displayed in the `./nym-mixnode list` command and in the `./nym-mixnode node-details --id ` command. It also shows up in the node explorer to let people know what your node is about and link to your website. - -You can set your node description, by creating a file called `description.toml` and put it in the same directory as your `config.toml` file (`~/.nym/mixnodes//config/description.toml`). The file should look like this example: - -```toml -name = "Winston Smith" -description = "I am the Sphinx" -link = "https://nymtech.net" -location = "Giza, Egypt" -``` - -> Remember to restart your `nym-mixnode` process in order for the new description to be propagated. - -## Running your Mix Node - -Run your Mix Node with: - -``` -./nym-mixnode run --id -``` - -Have a look at the saved configuration files in `$HOME/.nym/mixnodes/` to see more configuration options. - -## Bonding your Mix Node - -```admonish caution -From `v1.1.3`, if you unbond your Mix Node that means you are leaving the mixnet and you will lose all your delegations (permanently). You can join again with the same identity key, however, you will start with **no delegations**. -``` - -To initialise, run and bond your Mix Node are the minimum steps to do in order for your Mix Node to work. However we recommend to do a few more steps before bonding. These steps will make it easier for you as a node operator on a long run as well as for others to possibly delegate Nym tokens to your Mix Node. These steps are: - -- [Describe your Mix Node](./mix-node-setup.md#node-description-optional) -- [Configure your firewall](../../nodes/maintenance.md#configure-your-firewall) -- [Automate your Mix Node](../../nodes/maintenance.md#vps-setup-and-automation) -- Set the [ulimit](../../nodes/maintenance.md#set-the-ulimit-via-systemd-service-file), in case you haven't automated with [systemd](../../nodes/maintenance.md#set-the-ulimit-on-non-systemd-based-distributions) - -### Bond via the Desktop wallet (recommended) - -You can bond your Mix Node via the Desktop wallet. - -* Open your wallet, and head to the `Bond` page, then select the node type `Mixnode` and input your node details. Press `Next`. - -* Enter the `Amount`, `Operating cost` and `Profit margin` and press `Next`. - -* You will be asked to run a the `sign` command with your `mixnode` - copy and paste the long signature as the value of `--contract-msg` and run it. - -``` -./nym-mixnode sign --id --contract-msg -``` - -* Copy the resulting signature: - -```sh -# >>> The base58-encoded signature is: -2bbDJSmSo9r9qdamTNygY297nQTVRyQaxXURuomVcRd7EvG9oEC8uW8fvZZYnDeeC9iWyG9mAbX2K8rWEAxZBro1 -``` - -* And paste it into the wallet nodal, press `Next` and confirm the transaction. - -![Paste Signature](../../images/wallet-screenshots/wallet-sign.png) -*This image is just an example, copy-paste your own base58-encoded signature* - -* Your node will now be bonded and ready to mix at the beginning of the next epoch (at most 1 hour). - -> You are asked to `sign` a transaction on bonding so that the Mixnet smart contract is able to map your nym address to your node. This allows us to create a nonce for each account and defend against replay attacks. - -If everything worked, you'll see your node running on the either the [Sandbox testnet network explorer](https://sandbox-explorer.nymtech.net) or the [mainnet network explorer](https://explorer.nymtech.net), depending on which network you're running. - -Note that your node's public identity key is displayed during startup, you can use it to identify your node in the list. - -### Bond via the CLI (power users) -If you want to bond your Mix Node via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#bond-a-mix-node) docs. - - -## Node Families - -Node family involves setting up a group of Mix Nodes that work together to provide greater privacy and security for network communications. This is achieved by having the nodes in the family share information and routes, creating a decentralized network that makes it difficult for third parties to monitor or track communication traffic. - -### Create a Node Family - -To create a Node family, you will need to install and configure multiple Mix Nodes, and then use the CLI to link them together into a family. Once your Node family is up and running, you can use it to route your network traffic through a series of nodes, obscuring the original source and destination of the communication. - -You can use either `nym-cli` which can be downloaded from the [release page](https://github.com/nymtech/nym/releases) or compiling `nyxd`. - - -Change directory by `cd ///` and run the following on the family head to obtain the signature for the member: - -``` -./nym-mixnode sign --id --text -``` - -Using `nym-cli`: - -> `--mnemonic` is the mnemonic of the member wanting to be the head of family. - -``` -/nym-cli cosmwasm execute '{"create_family": {"signature": "","family_head": "","owner_signature":"","label": ""}}' --mnemonic -``` - -Using `nyxd`: - -> `--from` is mnemonic of the member wanting to join the family. - -``` -./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "","family_head": ""}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block -``` - -To get the node owner signature, use: - -`./nym-mixnode node-details --id ` - -### Joining a Node Family - -Change directory by `cd ///` and run the following on the family head to obtain the signature for the member: - -``` -./nym-mixnode sign --id --text -``` - -Using `nym-cli`: - -``` -./nym-cli cosmwasm execute '{"join_family": {"signature": "","family_head": "","owner_signautre": "", "label":""}}' --mnemonic -``` - -Using `nyxd`: - -``` -./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "","family_head": ""}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block -``` - - -To get the node owner signature, use: - -`./nym-mixnode node-details --id ` - - -### Leaving a family -If wanting to leave, run the same initial command as above, followed by: - -Using `nym-cli`: - -``` -./nym-cli cosmwasm execute '{"leave_family": {"signature": "","family_head": "","owner_signautre": ""}}' --mnemonic -``` - -Using `nyxd`: - -``` -./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "","family_head": ""}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block -``` - -## Checking that your node is mixing correctly -### Network explorers -Once you've started your Mix Node and it connects to the validator, your node will automatically show up in the 'Mix Nodes' section of either the Nym Network Explorers: - -- [Mainnet](https://explorer.nymtech.net/overview) -- [Sandbox testnet](https://sandbox-explorer.nymtech.net/) - -Enter your **identity key** to find your node. There are numerous statistics about your node on that page that are useful for checking your up-time history, packets mixed, and any delegations your node may have. - -There are also 2 community explorers which have been created by [Nodes Guru](https://nodes.guru): - -- [Mainnet](https://mixnet.explorers.guru/) -- [Sandbox testnet](https://sandbox.mixnet.explorers.guru/) - -## Maintenance - -For Mix Node upgrade, firewall setup, port configuration, API endpoints, VPS suggestions, automation and more, see the [maintenance page](../../nodes/maintenance.md) - diff --git a/documentation/old_docs/operators/src/archive/nodes/network-requester-setup.md b/documentation/old_docs/operators/src/archive/nodes/network-requester-setup.md deleted file mode 100644 index 66e830f41a..0000000000 --- a/documentation/old_docs/operators/src/archive/nodes/network-requester-setup.md +++ /dev/null @@ -1,205 +0,0 @@ -# Network Requester - -```admonish warning -**This is an archived page for backwards compatibility for existing node operators. To start a new node or migrate, follow the [`nym-node` guides](../../nodes/nym-node.md).** The content of this page is not updated since April 19th 2024. Eventually this page will be terminated! -``` - -> Nym Network Requester was built in the [building nym](../../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -## Current version - -The last version before migration to [`nym-node`](../../nodes/nym-node.md) was `1.1.33`. - -## Preliminary steps - -Make sure you do the preparation listed in the [preliminary steps page](initial-steps.md) before setting up your Network Requester. - -## Network Requester Whitelist - -If you have access to a server, you can run the Network Requester, which allows Nym users to send outbound requests from their local machine through the Mixnet to a server, which then makes the request on their behalf, shielding them (and their metadata) from clearnet, untrusted and unknown infrastructure, such as email or message client servers. - -By default the Network Requester is **not** an open proxy (although it can be used as one). It uses a file called `allowed.list` (located in `~/.nym/service-providers/network-requester//`) as a whitelist for outbound requests. - -**Note:** If you run Network Requester as a part of the Exit Gateway (suggested setup) the `allowed.list` will be stored in `~/.nym/gateways//data/network-requester-data/allowed.list`. - -Any request to a URL which is not on this list will be blocked. - -On startup, if this file is not present, the requester will grab the default whitelist from [Nym's default list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) automatically. - -This default whitelist is useful for knowing that the majority of Network Requesters are able to support certain apps 'out of the box'. - -**Operators of a Network Requester are of course free to edit this file and add the URLs of services they wish to support to it!** You can find instructions below on adding your own URLs or IPs to this list. - -The domains and IPs on the default whitelist can be broken down by application as follows: - -``` -# Keybase -keybaseapi.com -s3.amazonaws.com -amazonaws.com -twitter.com -keybase.io -gist.githubusercontent.com - -# Used to for uptime healthcheck (see the section on testing your requester below for more) -nymtech.net - -# Blockstream Green Bitcoin Wallet -blockstream.info -blockstream.com -greenaddress.it - -# Electrum Bitcoin Wallet -electrum.org - -# Helios Ethereum Client -alchemy.com -lightclientdata.org -p2pify.com - -# Telegram - these IPs have been copied from https://core.telegram.org/resources/cidr.txt as Telegram does -# not seem to route by domain as the other apps on this list do -91.108.56.0/22 -91.108.4.0/22 -91.108.8.0/22 -91.108.16.0/22 -91.108.12.0/22 -149.154.160.0/20 -91.105.192.0/23 -91.108.20.0/22 -185.76.151.0/24 -2001:b28:f23d::/48 -2001:b28:f23f::/48 -2001:67c:4e8::/48 -2001:b28:f23c::/48 -2a0a:f280::/32 - -# nym matrix server -nymtech.chat - -# generic matrix server backends -vector.im -matrix.org - -# monero desktop - mainnet -212.83.175.67 -212.83.172.165 -176.9.0.187 -88.198.163.90 -95.217.25.101 -136.244.105.131 -104.238.221.81 -66.85.74.134 -88.99.173.38 -51.79.173.165 - -# monero desktop - stagenet -162.210.173.150 -176.9.0.187 -88.99.173.38 -51.79.173.165 - -# alephium -alephium.org - -``` - -## Network Requester Directory - -You can find a list of Network Requesters running the default whitelist in the [explorer](https://explorer.nymtech.net/network-components/service-providers). This list comprises of the NRs running as infrastructure for NymConnect. - -> We are currently working on a smart-contract based solution more in line with how Mix Nodes and Gateways announce themselves to the network. - -## Viewing command help - -```admonish info -If you run your Network Requester as a part of your Exit Gateway according to the suggested setup, please skip this part of the page and read about [Exit Gateway setup](./gateway-setup.md#initialising-gateway-with-network-requester) instead. -``` - -To begin, move to `/target/release` directory from which you run the node commands: - -``` -cd target/release -``` - -The `./nym-network-requester --help ` command can be used to show a list of available parameters. - -You can check the required parameters for available commands by running: - -``` -./nym-network-requester --help -``` - -> Adding `--no-banner` startup flag will prevent Nym banner being printed even if run in tty environment. - -## Initializing and running your Network Requester - -The Network Requester needs to be initialized before it can be run. This is required for the embedded nym-client to connect successfully to the Mixnet. We want to specify an `` using the `--id` command and give it a value of your choice. The following command will achieve that: - -``` - ./nym-network-requester init --id -``` - -Now that we have initialized our network-requester, we can start it with the following command: - -``` - ./nym-network-requester run --id -``` - -## Using your Network Requester - -The next thing to do is use your requester, share its address with friends (or whoever you want to help privacy-enhance their app traffic). Is this safe to do? If it was an open proxy, this would be unsafe, because any Nym user could make network requests to any system on the internet. - -To make things a bit less stressful for administrators, the Network Requester drops all incoming requests by default. In order for it to make requests, you need to add specific domains to the `allowed.list` file at `$HOME/.nym/service-providers/network-requester/allowed.list` or if Network Requester is ran as a part of [Exit Gateway](./gateway-setup.md#initialising-gateway-with-network-requester), the `allowed.list` will be stored in `~/.nym/gateways//data/network-requester-data/allowed.list` - -### Global vs local allow lists -Your Network Requester will check for a domain against 2 lists before allowing traffic through for a particular domain or IP. - -* The first list is the default list on the [nymtech.net server](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt). Your Requester will not check against this list every time, but instead will keep a record of accepted domains in memory. - -* The second is the local `allowed.list` file. - -### Supporting custom domains with your Network Requester -It is easy to add new domains and services to your Network Requester - simply find out which endpoints (both URLs and raw IP addresses are supported) you need to whitelist, and then add these endpoints to your `allowed.list`. - -> In order to keep things more organised, you can now use comments in the `allow.list` like the example at the top of this page. - -How to go about this? Have a look in your `nym-network-requester` config directory: - -``` -# nym-network-requester binary -ls -lt $HOME/.nym/service-providers/network-requester/*/data | grep "list" - -# nym-gateway binary -ls -lt $HOME/.nym/gateways/*/data/network-requester-data | grep "list" - -# returns: allowed.list unknown.list -``` - -We already know that `allowed.list` is what lets requests go through. All unknown requests are logged to `unknown.list`. If you want to try using a new client type, just start the new application, point it at your local [socks client](https://nymtech.net/docs/clients/socks5-client.html) (configured to use your remote `nym-network-requester`), and keep copying URLs from `unknown.list` into `allowed.list` (it may take multiple tries until you get all of them, depending on the complexity of the application). Make sure to delete the copied ones in `unknown.list` and restart your Exit Gateway or standalone Network Requester. - -> If you are adding custom domains, please note that whilst they may appear in the logs of your network-requester as something like `api-0.core.keybaseapi.com:443`, you **only need** to include the main domain name, in this instance `keybaseapi.com` - -### Running an open proxy -If you *really* want to run an open proxy, perhaps for testing purposes for your own use or among a small group of trusted friends, it is possible to do so. You can disable Network checks by passing the flag `--open-proxy` flag when you run it. If you run in this configuration, you do so at your own risk. - -## Testing your Network Requester -1. Make sure `nymtech.net` is in your `allowed.list` (remember to restart your Network Requester). - -2. Ensure that your `nym-network-requester` is initialized and running. - -3. In another terminal window, run the following: - -``` -curl -x socks5h://localhost:1080 https://nymtech.net/.wellknown/connect/healthcheck.json -``` - -This command should return the following: - -``` -{ "status": "ok" } -``` - - diff --git a/documentation/old_docs/operators/src/archive/nodes/setup-guides.md b/documentation/old_docs/operators/src/archive/nodes/setup-guides.md deleted file mode 100644 index 957c94ab51..0000000000 --- a/documentation/old_docs/operators/src/archive/nodes/setup-guides.md +++ /dev/null @@ -1,15 +0,0 @@ -# Node Setup Guides - -```admonish warning -**This is an archived page for backwards compatibility. The content of this page is not updated since April 19th 2024. Eventually this page will be terminated!** -``` - -To setup any type of Nym's node, start with building [Nym's platform](../../binaries/building-nym.md) on the machine (VPS) where you want to run the node. Nodes will need to be bond to Nym's wallet, setup one [here](https://nymtech.net/docs/wallet/desktop-wallet.html). - -This section contains setup guides for the following node types: -* [Mix Node](mix-node-setup.md) -* [Gateway](gateway-setup.md) -* [Network Requester](network-requester-setup.md) -* [Validator](../../nodes/validator-setup.md) - - diff --git a/documentation/old_docs/operators/src/binaries/building-nym.md b/documentation/old_docs/operators/src/binaries/building-nym.md deleted file mode 100644 index 42165b9bc8..0000000000 --- a/documentation/old_docs/operators/src/binaries/building-nym.md +++ /dev/null @@ -1,70 +0,0 @@ -# Building from Source - -> Nym runs on Mac OS X, Linux, and Windows. All nodes **except the Desktop Wallet and NymConnect** on Windows should be considered experimental - it works fine if you're an app developer but isn't recommended for running nodes. - -## Building Nym -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](../nodes/validator-setup.md) instead.** - -## Prerequisites -- Debian/Ubuntu: `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq`, `git` - -``` -apt install pkg-config build-essential libssl-dev curl jq git -``` - -- Arch/Manjaro: `base-devel` - -``` -pacman -S base-devel -``` - -- Mac OS X: `pkg-config` , `brew`, `openss1`, `protobuf`, `curl`, `git` -Running the following the script installs Homebrew and the above dependencies: - -``` -/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" -``` - -- `Rust & cargo >= {{minimum_rust_version}}` - -We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old. - -If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms. - -## Download and build Nym binaries -The following commands will compile binaries into the `nym/target/release` directory: - -```sh -rustup update -git clone https://github.com/nymtech/nym.git -cd nym - -git reset --hard # in case you made any changes on your branch -git pull # in case you've checked it out before - -git checkout master # master branch has the latest release version: `develop` will most likely be incompatible with deployed public networks - -cargo build --release # build your binaries with **mainnet** configuration -``` - -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/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` - -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](https://nymtech.net/docs/wallet/desktop-wallet.html) -* [Network Explorer UI](https://nymtech.net/docs/explorers/mixnet-explorer.html) - -> 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/old_docs/operators/src/binaries/init-and-config.md b/documentation/old_docs/operators/src/binaries/init-and-config.md deleted file mode 100644 index 7c519a5889..0000000000 --- a/documentation/old_docs/operators/src/binaries/init-and-config.md +++ /dev/null @@ -1,20 +0,0 @@ -# Binary Initialisation and Configuration - -All Nym binaries must first be made executable and initialised with `init` before being `run`. - -To make a binary executable, open terminal in the same directory and run: - -```sh -chmod +x -# for example: chmod +x nym-mixnode -``` - -The `init` command is usually where you pass flags specifying configuration arguments such as the gateway you wish to communicate with, the ports you wish your binary to listen on, etc. - -The `init` command will also create the necessary keypairs and configuration files at `~/.nym///` if these files do not already exist. **It will not overwrite existing keypairs if they are present.** - -You can reconfigure your binaries at any time by editing the config file located at `~/.nym///config/config.toml` and restarting the binary process. - -Once you have run `init`, you can start your binary with the `run` command, usually only accompanied by the `id` of the binary that you specified. - -This `id` is **never** transmitted over the network, and is used to select which local config and key files to use for startup. diff --git a/documentation/old_docs/operators/src/binaries/pre-built-binaries.md b/documentation/old_docs/operators/src/binaries/pre-built-binaries.md deleted file mode 100644 index b42e5bb9c6..0000000000 --- a/documentation/old_docs/operators/src/binaries/pre-built-binaries.md +++ /dev/null @@ -1,32 +0,0 @@ -# Pre-built Binaries - -The [Github releases page](https://github.com/nymtech/nym/releases) has pre-built binaries which should work on Ubuntu 20.04 and other Debian-based systems, but at this stage cannot be guaranteed to work everywhere. - -If the pre-built binaries don't work or are unavailable for your system, you will need to build the platform yourself. - -## Setup Binaries - -> Any syntax in `<>` brackets is a user’s unique variable. Exchange with a corresponding name without the `<>` brackets. - -### Download Binary - -1. Open [Github releases page](https://github.com/nymtech/nym/releases) and right click on the binary you want -2. Select `Copy Link` -3. Open your VPS terminal in a directory where you want to download Nym binaries. -4. Download binary by running `wget ` where `` shall be in your clipboard from point \# 2. - -### Make Executable - -5. Run command: -```sh -chmod +x -# for example: chmod +x nym-mixnode -``` -### Run Binary - -Now you can use your binary, initialise and run your Nym Node. Follow the guide according to the type of your binary. - -**Node setup and usage guides:** - -* [Nym Nodes](../nodes/nym-node.md) -* [Validators](../nodes/validator-setup.md) diff --git a/documentation/old_docs/operators/src/binaries/version-compatiblity.md b/documentation/old_docs/operators/src/binaries/version-compatiblity.md deleted file mode 100644 index 83f152ba47..0000000000 --- a/documentation/old_docs/operators/src/binaries/version-compatiblity.md +++ /dev/null @@ -1,41 +0,0 @@ - - -# Version Compatibility Table - - -There are numerous components to Nym which are released independently of one another aside from when breaking changes occur in the [core platform code](https://github.com/nymtech/nym/) - mix nodes, gateways, network requesters, and clients. - -Whilst in general it recommended to be running the most recent version of any software, if you cannot do that for whatever reason this table will tell you which versions of different components are mutually compatible with which platform code releases. - - -| Core Platform | SDK | Wallet | NymConnect | Network Explorer | Mixnet contract | Vesting contract | -| ---------------- | ------------- | --------------- | --------------- | ---------------- | --------------- | ---------------- | -| 1.1.13 - 1.1.14* | 1.1.7 | 1.1.12 - 1.1.13 | 1.1.12 - 1.1.13 | 1.1.2 | 1.2.0 - 1.3.0 | 1.2.0 - 1.3.0 | -| 1.1.1 - 1.1.12 | 1.1.4 - 1.1.7 | 1.1.0 - 1.1.12 | 1.1.1 - 1.1.12 | 1.1.0 - 1.1.2 | 1.1.0 - 1.1.3 | 1.1.0 - 1.1.3 | -| 1.1.0 - 1.1.1 | 1.1.4 | 1.1.0 | 1.1.0 - 1.1.1 | 1.1.0 | 1.1.0 | 1.1.0 | -| 1.1.0 | x | 1.1.0 | 1.1.0 | 1.1.0 | 1.1.0 | 1.1.0 | - -`*` the `nym-mixnode` binary is currently one point ahead of the main platform release version - -> There are seperate changelogs for [`NymConnect`](https://github.com/nymtech/nym/blob/release/{{platform_release_version}}/nym-connect/CHANGELOG.md) and the [`Desktop Wallet`](https://github.com/nymtech/nym/blob/release/{{platform_release_version}}/nym-wallet/CHANGELOG.md). The changelog referenced below is for the core platform code. - -| Platform release changelog | -| ---------------------------------------------------------------------------------------- | -| 1.1.14 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.14/CHANGELOG.md)) | -| 1.1.13 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.13/CHANGELOG.md)) | -| 1.1.12 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.12/CHANGELOG.md)) | -| 1.1.11 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.11/CHANGELOG.md)) | -| 1.1.10 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.10/CHANGELOG.md)) | -| 1.1.9 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.9/CHANGELOG.md)) | -| 1.1.8 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.8/CHANGELOG.md)) | -| 1.1.7 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.7/CHANGELOG.md)) | -| 1.1.6 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.6/CHANGELOG.md)) | -| 1.1.5 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.5/CHANGELOG.md)) | -| 1.1.4 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.4/CHANGELOG.md)) | -| 1.1.3 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.3/CHANGELOG.md)) | -| 1.1.2 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.2/CHANGELOG.md)) | -| 1.1.1 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.1/CHANGELOG.md)) | -| 1.1.0 ([CHANGELOG](https://github.com/nymtech/nym/blob/release/v1.1.0/CHANGELOG.md)) | -| 1.0.2 ([CHANGELOG](https://github.com/nymtech/nym/blob/nym-binaries-1.0.2/CHANGELOG.md)) | -| 1.0.1 ([CHANGELOG](https://github.com/nymtech/nym/blob/nym-binaries-1.0.1/CHANGELOG.md)) | -| 1.0.0 ([CHANGELOG](https://github.com/nymtech/nym/blob/nym-binaries-1.0.0/CHANGELOG.md)) | diff --git a/documentation/old_docs/operators/src/changelog.md b/documentation/old_docs/operators/src/changelog.md deleted file mode 100644 index 707adc484c..0000000000 --- a/documentation/old_docs/operators/src/changelog.md +++ /dev/null @@ -1,967 +0,0 @@ -# Changelog - -This page displays a full list of all the changes during our release cycle from [`v2024.3-eclipse`](https://github.com/nymtech/nym/blob/nym-binaries-v2024.3-eclipse/CHANGELOG.md) onwards. Operators can find here the newest updates together with links to relevant documentation. The list is sorted so that the newest changes appear first. - -## `v2024.9-topdeck` - -- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.9-topdeck) -- [Release CHANGELOG.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.9-topdeck/CHANGELOG.md) -- [`nym-node`](nodes/nym-node.md) version `1.1.6` - -~~~admonish example collapsible=true title='CHANGELOG.md' -- chore: fix 1.80 lint issues ([#4731]) -- Handle clients with different versions in IPR ([#4723]) -- Add 1GB/day/user bandwidth cap ([#4717]) -- Feature/merge back ([#4710]) -- removed mixnode/gateway config migration code and disabled cli without explicit flag ([#4706]) - -[#4731]: https://github.com/nymtech/nym/pull/4731 -[#4723]: https://github.com/nymtech/nym/pull/4723 -[#4717]: https://github.com/nymtech/nym/pull/4717 -[#4710]: https://github.com/nymtech/nym/pull/4710 -[#4706]: https://github.com/nymtech/nym/pull/4706 -~~~ - -### Features - -* [Removed `nym-mixnode` and `nym-gateway` config migration code and disabled CLI without explicit flag](https://github.com/nymtech/nym/pull/4706): Gateway and Mixnode commands now won't do anything without explicit `--force-run` to bypass the deprecation, instead it will tell an operator to run a `nym-node`. The next step, in say a month or so, is to completely remove all `cli` related things. -~~~admonish example collapsible=true title='Testing steps performed' -- Verify that the `nym-gateway` binary and `nym-mixnode` binary commands return the `_error message_` stating to *update to `nym-node`* -- Check that when adding the `--force-run` flag, it still allows the command to be run (aside from `init` which has been removed) and the message stating to update to `nym-node` is a `_warning_` now -- Check `nym-node` is not affected -- Review the changes in the PR -~~~ - -* [Add 1GB/day/user bandwidth cap](https://github.com/nymtech/nym/pull/4717) - -~~~admonish example collapsible=true title='Testing steps performed - Scenario 1: Bandwidth Decreasing Continuously' -1. Start the client and noted the initial bandwidth (e.g., 1GB). -2. Us the client and track bandwidth usage over time (e.g., decrease by 100MB every hour). -3. Restart the client after some usage. -4. Verify the bandwidth continued from the last recorded value, not reset. - -**Notes:** - The bandwidth continued decreasing without resetting upon restart. Logs and reports correctly reflected the decreasing bandwidth. -~~~ - -~~~admonish example collapsible=true title='Testing steps performed - Scenario 2: Bandwidth Reset Next Day' -1. Use the client normally until the end of the day. -2. Suspend some clients and kept others active. -3. Check bandwidth at midnight. -4. Verify that bandwidth reset to 1GB for both suspended and active clients. - -**Notes:** -Bandwidth reset to 1GB for all clients at midnight. Logs and reports correctly showed the reset. -~~~ - -~~~admonish example collapsible=true title='Testing steps performed - Scenario 3: Bandwidth Reset at a Different Time (e.g., Midday)' -1. Configure the system to reset bandwidth at midday. -2. Use the client and monitored bandwidth until midday. -3. Keep the client connected during the reset time. -4. Verify that bandwidth reset to 1GB live at midday. - -**Notes:** -Bandwidth reset to 1GB at midday while the client was connected. Logs and reports correctly reflected the reset. -~~~ - -* [Handle clients with different versions in IPR](https://github.com/nymtech/nym/pull/4723): Allow the IPR to handle clients connecting both using `v6` and `v7`, independently. The motivation is that we want to be able to roll out an API version change gradually for NymVPN clients without breaking backwards compatibility. The main feature on the new `v7` format that is not yet used, is that it adds signatures for connect/disconnect. -~~~admonish example collapsible=true title='Testing steps performed' -Run the same command (using same gateways deployed from this PR) on different versions of the `nym-vpn-cli`. - -Example: -```sh -sudo -E ./nym-vpn-cli -c ../qa.env run --entry-gateway-id $entry_gateway --exit-gateway-id $exit_gateway --enable-two-hop - -sudo -E ./nym-vpn-cli -c ../qa.env run --entry-gateway-id $entry_gateway --exit-gateway-id $exit_gateway --enable-two-hop -``` -~~~ - -### Bugfix - -* [Feature/merge back](https://github.com/nymtech/nym/pull/4710): Merge back from the release branch the changes that fix the `nym-node` upgrades. - -* [Fix version `1.x.x` not having template correspondent initially](https://github.com/nymtech/nym/pull/4733): This should fix the problem of config deserialisation when operators upgrade nodes and skip over multiple versions. -~~~admonish example collapsible=true title='Testing steps performed' -- Tested updating an old nym-node version and ensuring it did not throw any errors. -~~~ - -* [chore: fix 1.80 lint issues](https://github.com/nymtech/nym/pull/4731): -~~~admonish example collapsible=true title='Testing steps performed' -- Building all binaries is ok -- Running `cargo fmt` returns no issues -~~~ - -### Operators Guide updates - -* [WireGuard tunnel configuration guide](nodes/configuration.md#routing-configuration) for `nym-node` (currently Gateways functionalities). For simplicity we made a detailed step by step guide to upgrade an existing `nym-node` to the latest version and configure your VPS routing for WireGuard. Open by clicking on the example block below. - -~~~admonish example collapsible=true title='Upgrading `nym-node` with WG' -**Prerequisites** - -- **Nym Node Version:** You must be running the `2024.9-topdeck` release branch, which operates as `nym-node` version `1.1.6`. You can find the release here: [Nym 2024.9-topdeck Release](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.9-topdeck). - -- **Important:** Before proceeding, make sure to [back up](nodes/maintenance.md#backup-a-node) your current `nym-node` configuration to avoid any potential data loss or issues. - - -- **Download Nym Node:** - - You can download the `nym-node` binary directly using the following command: -```bash -curl -L https://github.com/nymtech/nym/releases/download/nym-binaries-v2024.9-topdeck/nym-node -o nym-node && chmod u+x nym-node -``` - -**Step 1: Update UFW Firewall Rules** - -- **Warning:** Enabling the firewall with UFW without allowing SSH port 22 first will lead to losing access over SSH. Make sure port 22 is allowed before proceeding with any UFW configurations. - -Run the following as root or with `sudo` prefix: - -1. Check the current status of UFW (Uncomplicated Firewall): -```bash -ufw status -``` - -2. Ensure that the following ports are allowed on your machine before adding the WireGuard port: - -```bash -ufw allow 22/tcp # SSH - you're in control of these ports -ufw allow 80/tcp # HTTP -ufw allow 443/tcp # HTTPS -ufw allow 1789/tcp # Nym specific -ufw allow 1790/tcp # Nym specific -ufw allow 8080/tcp # Nym specific - nym-node-api -ufw allow 9000/tcp # Nym Specific - clients port -ufw allow 9001/tcp # Nym specific - wss port -ufw allow 51822/udp # WireGuard -``` - -3. Confirm that the UFW rules have been updated: -```bash -ufw status -``` - -**Step 2: Download and Prepare the Network Tunnel Manager Script** - -1. Download the [`network_tunnel_manager.sh`](https://gist.github.com/tommyv1987/ccf6ca00ffb3d7e13192edda61bb2a77) script: -```bash -curl -L -o network_tunnel_manager.sh https://gist.githubusercontent.com/tommyv1987/ccf6ca00ffb3d7e13192edda61bb2a77/raw/3c0a38c1416f8fdf22906c013299dd08d1497183/network_tunnel_manager.sh -``` - -2. Make the script executable: -```bash -chmod u+x network_tunnel_manager.sh -``` - -3. Apply the WireGuard IPTables rules: -```bash -./network_tunnel_manager.sh apply_iptables_rules_wg -``` - -**Step 3: Update the Nym Node Service File** - -1. Modify your [`nym-node` service file](nodes/configuration.md#systemd) to enable WireGuard. Open the file (usually located at `/etc/systemd/system/nym-node.service`) and update the `[Service]` section as follows: - -```ini -[Service] -User= -Type=simple -#Environment=RUST_LOG=debug -# CAHNGE PATH IF YOU DON'T RUN IT FROM ROOT HOME DIRECTORY -ExecStart=/root/nym-node run --mode exit-gateway --id --accept-operator-terms-and-conditions --wireguard-enabled true -Restart=on-failure -RestartSec=30 -StartLimitInterval=350 -StartLimitBurst=10 -LimitNOFILE=65536 - -[Install] -WantedBy=multi-user.target - -# ADD OR TWEAK ANY CUSTOM SETTINGS -``` - -2. Reload the systemd daemon to apply the changes: -```bash -systemctl daemon-reload -``` - -3. Restart the `nym-node service`: -```bash -systemctl restart nym-node.service -``` - -4. Optionally, you can check if the node is running correctly by monitoring the service logs: -```bash -journalctl -u nym-node.service -f -n 100 -``` - -**Step 4: Run the Network Tunnel Manager Script** - -Finally, run the following command to initiate our favorite routing test - run the joke through the WireGuard tunnel: -```bash -./network_tunnel_manager.sh joke_through_wg_tunnel -``` - -- **Note:** Wireguard will return only IPv4 joke, not IPv6. WG IPv6 is under development. Running IPR joke through the mixnet with `./network_tunnel_manager.sh joke_through_the_mixnet` should work with both IPv4 and IPv6! -~~~ - -* [Change `--wireguard-enabled` flag to `true`](nodes/setup.md#-initialise--run): With a proper [routing configuration](nodes/configuration.md#routing-configuration) `nym-nodes` running as Gateways can now enable WG. See the example below: - -~~~admonish example collapsible=true title='Syntax to run `nym-node` with WG enabled' -For Exit Gateway: -```sh -./nym-node run --id --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location --accept-operator-terms-and-conditions --wireguard-enabled true - -# is in format without 'https://' prefix -# is format like 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided. -# wireguard can be enabled from version 1.1.6 onwards -``` - -For Entry Gateway: -```sh -./nym-node run --id --mode entry-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --accept-operator-terms-and-conditions --wireguard-enabled true - -# is in format without 'https://' prefix -# is format like 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided. -# wireguard can be enabled from version 1.1.6 onwards -``` -~~~ - -* [Update Nym exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt): Based on the survey, AMA and following discussions we added several ports to Nym exit policy. The ports voted upon in the [forum governance](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464) have not been added yet due to the concerns raised. These ports were unrestricted: - -~~~admonish example collapsible=true title='Newly opened ports in Nym exit policy' -``` -22 # SSH -123 # NTP -445 # SMB file share Windows -465 # URD for SSM -587 # SMTP -853 # DNS over TLS -1433 # databases -1521 # databases -2049 # NFS -3074 # Xbox Live -3306 # databases -5000-5005 # RTP / VoIP -5432 # databases -6543 # databases -8080 # HTTP Proxies -8767 # TeamSpeak -8883 # Secure MQ Telemetry Transport - MQTT over SSL -9053 # Tari -9339 # gaming -9443 # alternative HTTPS -9735 # Lightning -25565 # Minecraft -27000-27050 # Steam and game servers -60000-61000 # MOSH -``` -~~~ - -* [Create a NymConnect archive page](https://nymtech.net/developers/archive/nym-connect.html), PR [\#4750](https://github.com/nymtech/nym/commit/5096c1e60e203dcf8be934823946e24fda16a9a3): Archive deprecated NymConnect for backward compatibility, show PEApps examples for both NC and maintained `nym-socks5-client`. - -* Fix broken URLs and correct redirection. PRs: [\#4745](https://github.com/nymtech/nym/commit/7e36595d8fa7706876880b42df1c998a4b8c1478), [\#4752](https://github.com/nymtech/nym/commit/1db61f800c6884e284c5ab21e7abce3bc6d91d99) [\#4755](https://github.com/nymtech/nym/commit/aaf3dca5b999ad7f19d2ff170078b43c9c4476c2), [\#4737](https://github.com/nymtech/nym/commit/6f669866e92e637772726ad05caa5c5501a830f3) -~~~admonish example collapsible=true title='Testing steps performed' -- Use [deadlinkchecker.com](https://www.deadlinkchecker.com/website-dead-link-checker.asp) to go over `nymtech.net` and correct all docs URLs -- Go over search engines and old medium articles and check that all dead URLs re-directing correctly -~~~ - -* [Clarify syntax on `nym-nodes` ports on VPS setup page](https://nymtech.net/operators/nodes/vps-setup.html#configure-your-firewall), PR [\#4734](https://github.com/nymtech/nym/commit/5e6417f83788f30b2a84e4dd73d6dd9619a2bb16): Make crystal clear that the addresses and ports in operators `config.toml` must be opened using [`ufw`](https://nymtech.net/operators/nodes/vps-setup.html#configure-your-firewall) and set up as in the example below: -~~~admonish example collapsible=true title='snap of binding addresses and ports in `config.toml`' -```toml -[host] -public_ips = [ -'' -] - -[mixnet] -bind_address = '0.0.0.0:1789' - -[http] -bind_address = '0.0.0.0:8080' - -[mixnode] -[mixnode.verloc] -bind_address = '0.0.0.0:1790' - -[entry_gateway] -bind_address = '0.0.0.0:9000' -``` -~~~ - -### Tooling - -* [Nym Harbourmaster](https://https://harbourmaster.nymtech.net/) has now several new functionalities: - - Tab for Mixnodes - - Tab with Charts - - New columns with: *Moniker (node description)*, *DP delegatee*, *Accepted T&Cs* - also part of a new category 🐼😀 - -* Nym has a new [Token page](https://nymtech.net/about/token) - ---- - - -## `v2024.8-wispa` - -- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.8-wispa) -- [Release CHANGELOG.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.8-wispa/CHANGELOG.md) -- [`nym-node`](nodes/nym-node.md) version `1.1.5` - -~~~admonish example collapsible=true title='CHANGELOG.md' -- add event parsing to support cosmos_sdk > 0.50 ([#4697]) -- Fix NR config compatibility ([#4690]) -- Remove UserAgent constructor since it's weakly typed ([#4689]) -- [bugfix]: Node_api_check CLI looked over roles on blacklisted nodes ([#4687]) -- Add mixnodes to self describing api cache ([#4684]) -- Move and whole bump of crates to workspace and upgrade some ([#4680]) -- Remove code that refers to removed nym-network-statistics ([#4679]) -- Remove nym-network-statistics ([#4678]) -- Create UserAgent that can be passed from the binary to the nym api client ([#4677]) -- Add authenticator ([#4667]) - -[#4697]: https://github.com/nymtech/nym/pull/4697 -[#4690]: https://github.com/nymtech/nym/pull/4690 -[#4689]: https://github.com/nymtech/nym/pull/4689 -[#4687]: https://github.com/nymtech/nym/pull/4687 -[#4684]: https://github.com/nymtech/nym/pull/4684 -[#4680]: https://github.com/nymtech/nym/pull/4680 -[#4679]: https://github.com/nymtech/nym/pull/4679 -[#4678]: https://github.com/nymtech/nym/pull/4678 -[#4677]: https://github.com/nymtech/nym/pull/4677 -[#4667]: https://github.com/nymtech/nym/pull/4667 -~~~ - - -### Features - -* [Default construct NodeRole](https://github.com/nymtech/nym/pull/4721): To preserve compatibility with newer clients interacting with older `nym-api` -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes in the `nym-api-requests/src/models.rs` file. - 2. Verified that the `NymNodeDescription` struct includes the new `role` field with a default value set by `default_node_role`. - 3. Checked the implementation of the `default_node_role` function to ensure it returns `NodeRole::Inactive`. - 4. Ran the updated code in the sandbox environment. - 5. Monitored the sandbox environment for any issues or errors related to the changes. - - - **Notes (if any):** - The test was successful. No issues were flagged during the testing in the sandbox environment. The new default value for `NodeRole` ensures backward compatibility without causing disruptions. -~~~ - -* [Default construct NodeRole for backwards compatibility (apply [\#4721](https://github.com/nymtech/nym/pull/4721) on develop)](https://github.com/nymtech/nym/pull/4722) -* [Add upgrades to `nym-node` for `authenticator` changes](https://github.com/nymtech/nym/pull/4703) -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes in the `gateway/src/error.rs` and `gateway/src/node/mod.rs` files. - 2. Verified the new error enum `AuthenticatorStartupFailure` was added to `GatewayError`. - 3. Confirmed the implementation of the `StartedAuthenticator` struct and its usage in the `start_authenticator` function. - 4. Ran the updated code in the canary environment. - 5. Monitored the canary environment for any issues or errors related to the changes. -~~~ - -* [Add event parsing to support `cosmos_sdk` > `0.50`](https://github.com/nymtech/nym/pull/4697) -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes in `common/client-libs/validator-client/src/nyxd/cosmwasm_client/client_traits/signing_client.rs`, `logs.rs`, `types.rs`, and `nym-api/src/coconut/tests/mod.rs` files. - 2. Verified the addition of event parsing in the relevant functions and structs. - 3. Ensured that the `find_attribute` function correctly parses event attributes. - 4. Ran the updated code in the sandbox environment. - 5. Broadcasted transactions on the sandbox network to test the changes. - 6. Monitored the sandbox network for any malformed responses or errors after the test chain upgrade. -~~~ - -* [Send bandwidth status messages when connecting](https://github.com/nymtech/nym/pull/4691): When connecting to the gateway we get received the available bandwidth left. Emit a status messages for this, for consumption by the application layer. -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes in `common/bandwidth-controller/src/event.rs`, `common/bandwidth-controller/src/lib.rs`, and `common/client-libs/gateway-client/src/client.rs` files. - 2. Verified the implementation of `BandwidthStatusMessage` enum for emitting status messages. - 3. Ensured `GatewayClient` is updated to send bandwidth status messages when connecting. - 4. Deployed the updated code on the canary environment. - 5. Connected to the gateway and checked for the emission of bandwidth status messages. - 6. Verified that the messages were correctly parsed and consumed by the application layer. - 7. Ran the VPN client to observe the parsed events. - ~~~ - -* [Fix NR config compatibility](https://github.com/nymtech/nym/pull/4690): Recently we deleted the old statistics service provider. This fixes some issues where old configs didn't work with the latest changes. - - Make NR able to read config with old keys in - - Remove deleted config keys from NR template -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes in the `service-providers/network-requester/src/config/mod.rs` and `service-providers/network-requester/src/config/template.rs` files. - 2. Ensured `NetworkRequester` config is able to read old keys for compatibility. - 3. Removed old and deleted config keys from the `NetworkRequester` template. - 4. Compiled the project to verify no issues or warnings appeared. - 5. Ran all tests to ensure that the changes did not affect the functionality. - 6. Validated that no leftover code from the old statistics service provider caused any issues. - ~~~ - -* [Remove `UserAgent` constructor since it's weakly typed](https://github.com/nymtech/nym/pull/4689): -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes in `common/http-api-client/src/user_agent.rs` file. - 2. Verified the removal of the `UserAgent` constructor and ensured that all instances of `UserAgent::new` are updated accordingly. - 3. Checked the implementation of `UserAgent` struct using `BinaryBuildInformation` and `BinaryBuildInformationOwned`. - 4. Deployed the updated code across different environments (QA, sandbox, and canary). - 5. Ran tests to ensure that the `UserAgent` struct functions correctly without the constructor. - ~~~ - -* [Add mixnodes to self describing api cache](https://github.com/nymtech/nym/pull/4684): - - Abstracts getting the self describing info a bit - - Adds mixnodes to the cache refresher as well - - Adds `role` field to the `NodeDescription` struct, to be able to distinguish between mixnodes and gateways - - Switched to using `NodeStatusCache` instead of `ContractCache` -~~~admonish example collapsible=true title='Testing steps performed' -Called the new `/mixnodes/described` endpoint as well as the existing `/gateways/described` endpoint and verified that the data returned for each was correct based on the settings that different nodes have when they are setup. - -For gateway endpoint, the “role” for now does not differentiate between entry and exit gateways, this will be implemented in the future. -~~~ - -* [Move and whole bump of crates to workspace and upgrade some](https://github.com/nymtech/nym/pull/4680): - - Fix cargo warning for `default_features` - - Move dirs 4.0 to workspace - - Use workspace `base64` dep - - Move `rand_chacha` and `x25519-dalek` to workspace - - Use workspace `ed25519-dalek` dep - - Move `itertools` to workspace deps and upgrade - - Move a few partial deps to workspace while preserving versions -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the changes to move and upgrade crates to the workspace. - 2. Verified the updated dependencies: - - Moved `dirs` to version 4.0 in the workspace. - - Updated the `base64` dependency to use the workspace version. - - Moved `rand_chacha` and `x25519-dalek` to the workspace. - - Updated `ed25519-dalek` to use the workspace version. - - Moved and upgraded `itertools` in the workspace. - - Moved other partial dependencies to the workspace while preserving their versions. - 3. Ensured the `Cargo.toml` files across the project reflect these changes correctly. - 4. Compiled the entire project to check for any issues or warnings. - 5. Verified that all tests pass successfully after the changes. - ~~~ - -* [Remove `nym-network-statistics`](https://github.com/nymtech/nym/pull/4678): Remove `nym-network-statistics` service provider that is no longer used. -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the project to identify all references to `nym-network-statistics`. - 2. Removed all code and dependencies associated with `nym-network-statistics`. - 3. Ensured that no references to `nym-network-statistics` remain in the codebase, including comments, imports, and configuration files. - 4. Compiled the project to check for any issues or warnings. - 5. Ran all tests to ensure the removal did not affect the functionality of the project. - ~~~ - - -* [Remove code that refers to removed `nym-network-statistics`](https://github.com/nymtech/nym/pull/4679): Follow up to [\#4678](https://github.com/nymtech/nym/pull/4678) where all code interacting with it is removed. -~~~admonish example collapsible=true title='Testing steps performed' - 1. Reviewed the project to identify all references to `nym-network-statistics`. - 2. Removed all code and dependencies associated with `nym-network-statistics`. - 3. Ensured that no references to `nym-network-statistics` remain in the codebase, including comments, imports, and configuration files. - 4. Compiled the project to check for any issues or warnings. - 5. Ran all tests to ensure the removal did not affect the functionality of the project. - ~~~ - -* [Create `UserAgent` that can be passed from the binary to the `nym-api` client](https://github.com/nymtech/nym/pull/4677): - - Support setting `UserAgent` for the validator client - - Support setting `UserAgent` in the SDK `MixnetClient` - - Set `UserAgent` when getting the list of gateways and topology in - - `nym-client` - - `nym-socks5-client` - - Standalone `ip-packet-router` - -~~~admonish example collapsible=true title='Testing steps performed' -Used the nym-vpn-cli to test this, and we can visibly see the `UserAgent`, no issues with the comments mentioned above. - -Example of the user agent sent: -`nym-client/1.1.36/x86_64-unknown-linux-gnu/e18bb70` - -image - -Connected with no problems -~~~ - -* [Add `authenticator`](https://github.com/nymtech/nym/pull/4667) - -### Bugfix - -* [`Node_api_check.py` CLI looked over roles on blacklisted nodes](https://github.com/nymtech/nym/pull/4687): Removing/correcting this redundant function which results in unwanted error print, will resolve in the program not looking up the `roles` endpoint for blacklisted GWs, instead just ignores the role description and still return all other endpoints. - -### Operators Guide updates - -* [Create a guide to backup and restore `nym-node`](https://nymtech.net/operators/nodes/maintenance.html#backup-a-node), PR [\#4720](https://github.com/nymtech/nym/pull/4720) -* [Add manual IPv6 ifup/down network configuration](https://nymtech.net/operators/troubleshooting/vps-isp.html#network-configuration), PR [\#4651](https://github.com/nymtech/nym/pull/4651) -* [Extend ISP list](https://nymtech.net/operators/legal/isp-list.html) -* [Add SSL cert bot block to WSS setup](https://nymtech.net/operators/nodes/proxy-configuration.html#web-secure-socket-setup), [PR here](https://github.com/nymtech/nym/commits/develop/): WSS setup fully works! -* [Correct `HTTP API port` in bonding page](https://nymtech.net/operators/nodes/bonding.html#bond-via-the-desktop-wallet-recommended) , [PR \#4707](https://github.com/nymtech/nym/pull/4707): Change `HTTP API port` to `8080` on every `nym-node` by opening `config.toml` and making sure that your binding addresses and ports are as in the block below. Then go to desktop wallet and open the box called `Show advanced options` and make sure all your ports are set correctly (usually this means to change `HTTP api port` to `8080` for `mixnode` mode). -~~~admonish example collapsible=true title='snap of binding addresses and ports in `config.toml`' -```toml -[host] -public_ips = [ -'' -] - -[mixnet] -bind_address = '0.0.0.0:1789' - -[http] -bind_address = '0.0.0.0:8080' - -[mixnode] -[mixnode.verloc] -bind_address = '0.0.0.0:1790' - -[entry_gateway] -bind_address = '0.0.0.0:9000' -``` -~~~ - -* [Comment our deprecated node pages in `/docs`](https://github.com/nymtech/nym/pull/4727) - - Fixes [issue \#4632](https://github.com/nymtech/nym/issues/4632) -* [Remove redundant syntax from the setup guide](https://github.com/nymtech/nym/pull/4682) - ---- - -## `v2024.7-doubledecker` - -- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.7-doubledecker) -- [Release CHANGELOG.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.7-doubledecker/CHANGELOG.md) -- [`nym-node`](nodes/nym-node.md) version `1.1.4` - -~~~admonish example collapsible=true title='CHANGELOG.md' -- Add an early return in `parse_raw_str_logs` for empty raw log strings. ([#4686]) -- Bump braces from 3.0.2 to 3.0.3 in /wasm/mix-fetch/internal-dev ([#4672]) -- add expiry returned on import ([#4670]) -- [bugfix] missing rustls feature ([#4666]) -- Bump ws from 8.13.0 to 8.17.1 in /wasm/client/internal-dev-node ([#4665]) -- Bump braces from 3.0.2 to 3.0.3 in /clients/native/examples/js-examples/websocket ([#4663]) -- Bump ws from 8.14.2 to 8.17.1 in /sdk/typescript/packages/nodejs-client ([#4662]) -- Update setup.md ([#4661]) -- New clippy lints ([#4660]) -- Bump braces from 3.0.2 to 3.0.3 in /nym-api/tests ([#4659]) -- Bump braces from 3.0.2 to 3.0.3 in /docker/typescript_client/upload_contract ([#4658]) -- Update vps-setup.md ([#4656]) -- Update configuration.md ([#4655]) -- Remove old PR template ([#4639]) - -[#4686]: https://github.com/nymtech/nym/pull/4686 -[#4672]: https://github.com/nymtech/nym/pull/4672 -[#4670]: https://github.com/nymtech/nym/pull/4670 -[#4666]: https://github.com/nymtech/nym/pull/4666 -[#4665]: https://github.com/nymtech/nym/pull/4665 -[#4663]: https://github.com/nymtech/nym/pull/4663 -[#4662]: https://github.com/nymtech/nym/pull/4662 -[#4661]: https://github.com/nymtech/nym/pull/4661 -[#4660]: https://github.com/nymtech/nym/pull/4660 -[#4659]: https://github.com/nymtech/nym/pull/4659 -[#4658]: https://github.com/nymtech/nym/pull/4658 -[#4656]: https://github.com/nymtech/nym/pull/4656 -[#4655]: https://github.com/nymtech/nym/pull/4655 -[#4639]: https://github.com/nymtech/nym/pull/4639 -~~~ - -### Features - -- [Remove the `nym-mixnode` and `nym-gateway` binaries from the CI upload builds action](https://github.com/nymtech/nym/pull/4693) -- [Add an early return in `parse_raw_str_logs` for empty raw log strings.](https://github.com/nymtech/nym/pull/4686): This accommodates for the v50 + chain upgrade. -- [Bump braces from `3.0.2` to `3.0.3` in `/wasm/mix-fetch/internal-dev`](https://github.com/nymtech/nym/pull/4672): Version update of [braces](https://github.com/micromatch/braces) -- [Bump braces from `3.0.2` to `3.0.3` in `/clients/native/examples/js-examples/websocket`](https://github.com/nymtech/nym/pull/4663): Version update of [braces](https://github.com/micromatch/braces). -- [Bump braces from `3.0.2` to `3.0.3` in `/nym-api/tests`](https://github.com/nymtech/nym/pull/4659): Version update of [braces](https://github.com/micromatch/braces). -- [Bump braces from `3.0.2` to `3.0.3` in `/docker/typescript_client/upload_contract`](https://github.com/nymtech/nym/pull/4658): Version update of [braces](https://github.com/micromatch/braces). -- [Bump `ws` from `8.13.0` to `8.17.1` in `/wasm/client/internal-dev-node`](https://github.com/nymtech/nym/pull/4665): Version update of [`ws`](https://github.com/websockets/ws). -- [Bump `ws` from `8.14.2` to `8.17.1` in `/sdk/typescript/packages/nodejs-client`](https://github.com/nymtech/nym/pull/4662): Version update of [`ws`](https://github.com/websockets/ws). -- [Add expiry returned on import](https://github.com/nymtech/nym/pull/4670): We need to return the expiry on import for desktop daemon `nym-vpnd`. -- [New clippy lints](https://github.com/nymtech/nym/pull/4660) -- [Remove `nym-connect` directory](https://github.com/nymtech/nym/pull/4643): Since the `nym-vpn` has superseded `nym-connect`, remove `nym-connect` from the repo. -- [Remove old PR template](https://github.com/nymtech/nym/pull/4639) - -### Bugfix - -- [missing rustls feature](https://github.com/nymtech/nym/pull/4666): It just happens to work due to `feature-unification`. It should probably have this feature inbuild. - -### Operators Guide updates - -- [Node description guide](nodes/configuration.md#node-description): Steps to add self-description to `nym-node` and query this information from any node. -- [Web Secure Socket (WSS) guide and reverse proxy update](nodes/proxy-configuration.md), PR [here](https://github.com/nymtech/nym/pull/4694): A guide to setup `nym-node` in a secure fashion, using WSS via Nginx and Certbot. Landing page (reversed proxy) is updated and simplified. - ---- - -## `v2024.6-chomp` - -- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.6-chomp) -- [Release CHANGELOG.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.6-chomp/CHANGELOG.md) -- [`nym-node`](nodes/nym-node.md) version `1.1.3` -- Standalone `nym-gateway` and `nym-mixnode` binaries are no longer released - -~~~admonish example collapsible=true title='CHANGELOG.md' -- Remove additional code as part of Ephemera Purge and SP and contracts ([#4650]) -- bugfix: make sure nym-api can handle non-cw2 (or without detailed build info) compliant contracts ([#4648]) -- introduced a flag to accept toc and exposed it via self-described API ([#4647]) -- bugfix: make sure to return an error on invalid public ip ([#4646]) -- Add ci check for PR having an assigned milestone ([#4644]) -- Removed ephemera code ([#4642]) -- Remove stale peers ([#4640]) -- Add generic wg private network routing ([#4636]) -- Feature/new node endpoints ([#4635]) -- standarised ContractBuildInformation and added it to all contracts ([#4631]) -- validate nym-node public ips on startup ([#4630]) -- Bump defguard wg ([#4625]) -- Fix cargo warnings ([#4624]) -- Update kernel peers on peer modification ([#4622]) -- Handle v6 and v7 requests in the IPR, but reply with v6 ([#4620]) -- fix typo ([#4619]) -- Update crypto and rand crates ([#4607]) -- Purge name service and service provider directory contracts ([#4603]) - -[#4650]: https://github.com/nymtech/nym/pull/4650 -[#4648]: https://github.com/nymtech/nym/pull/4648 -[#4647]: https://github.com/nymtech/nym/pull/4647 -[#4646]: https://github.com/nymtech/nym/pull/4646 -[#4644]: https://github.com/nymtech/nym/pull/4644 -[#4642]: https://github.com/nymtech/nym/pull/4642 -[#4640]: https://github.com/nymtech/nym/pull/4640 -[#4636]: https://github.com/nymtech/nym/pull/4636 -[#4635]: https://github.com/nymtech/nym/pull/4635 -[#4631]: https://github.com/nymtech/nym/pull/4631 -[#4630]: https://github.com/nymtech/nym/pull/4630 -[#4625]: https://github.com/nymtech/nym/pull/4625 -[#4624]: https://github.com/nymtech/nym/pull/4624 -[#4622]: https://github.com/nymtech/nym/pull/4622 -[#4620]: https://github.com/nymtech/nym/pull/4620 -[#4619]: https://github.com/nymtech/nym/pull/4619 -[#4607]: https://github.com/nymtech/nym/pull/4607 -[#4603]: https://github.com/nymtech/nym/pull/4603 -~~~ - -### Features - -- [Make embedded NR/IPR ignore performance of the Gateway](https://github.com/nymtech/nym/pull/4671): fixes bug in relation to scoring issue on nym-nodes operating as exit gateways failing to come online. -- [Introduce a flag to accept Operators Terms and Conditions and exposed it via self-described API](https://github.com/nymtech/nym/pull/4647) -~~~admonish example collapsible=true title='Testing steps performed' -- Verify that the `execute` function correctly checks if the `accept_operator_terms` flag is set. -- Test that a warning is displayed when the `accept_operator_terms` flag is not set. -- Confirm that the `NymNode` instance is initialized with `with_accepted_toc(accepted_toc)` when the flag is set. -- Apply the `--accept-toc` flag in the service and confirmed the change by running: -``` -curl -s -X 'GET' 'http://18.171.251.41:8080/api/v1/auxiliary-details?output=json' -H 'accept: application/json' | jq .accepted_toc -``` -- Verify that the output is `true`. -~~~ - -- [Rename 'accept-toc' flag and fields into explicit 'accept-operator-terms-and-conditions'](https://github.com/nymtech/nym/pull/4654): makes the `accept-toc` flag more explicit. -- [Validate nym-node public ips on startup](https://github.com/nymtech/nym/pull/4630): makes sure `nym-node` is not run with an empty `public_ips` and that they do not correspond to common misconfigurations like `127.0.0.1` or `0.0.0.0` unless run with `--local` flag. -~~~admonish example collapsible=true title='Testing steps performed' -- Use the latest release/chomp binary with nym-node and input a dodgy ip -image - -- Validation: -image -When restarting the node it complains within the service launch file -~~~ - -- [New node endpoints](https://github.com/nymtech/nym/pull/4635): introduces new endpoints on nym-api (and creates scaffolding for additional ones) for providing **unfiltered** network topology alongside performance score of all nodes. - - `NymApiTopologyProvider` got modified to use those endpoints alongside (configurable) filtering of nodes with score < 50% (like our current blacklist) - - Old clients should work as before as no existing endpoint got removed -~~~admonish example collapsible=true title='Testing steps performed' -- Validate that the `skimmed` endpoints are working, keeping in mind that they are unstable. The *full-fat* and *semi-skimmed* have not yet been implemented. -~~~ - -- [Remove stale peers](https://github.com/nymtech/nym/pull/4640) -- [Removed ephemera code](https://github.com/nymtech/nym/pull/4642) -~~~admonish example collapsible=true title='Testing steps performed' -- Check references to everything named SP and Ephemera and removed any additional references -~~~ - -- [Remove additional code as part of Ephemera Purge and SP and contracts](https://github.com/nymtech/nym/pull/4650): in line with [#4642](https://github.com/nymtech/nym/pull/4642) and [#4603](https://github.com/nymtech/nym/pull/4603) -~~~admonish example collapsible=true title='Testing steps performed' -- Check references to everything named SP and Ephemera and removed any additional references -~~~ - -- [Add ci check for PR having an assigned milestone](https://github.com/nymtech/nym/pull/4644): add a CI check for checking that a PR is assigned to a milestone. Can bypassed the check by adding a `no-milestone` label to a PR -~~~admonish example collapsible=true title='Testing steps performed' -- CI complains if no milestone is associated with the an issue. -~~~ - -- [Bump defguard wireguard](https://github.com/nymtech/nym/pull/4625) -- [Add generic wireguard private network routing](https://github.com/nymtech/nym/pull/4636): as defguard wireguard only allows for peer routing modifications, we will configure the entire wireguard private network to be routed to the wg device. Configuring per peer is also not desirable, as the interface doesn't allow removing routes, so unused ip routing won't be cleaned until gateway restart (and it would also pollute to routing table with a lot of rules when many peers are added). -~~~admonish example collapsible=true title='Testing steps performed' -- This is a part of a bigger ticket, but initial testing has proven to shown that launching nym-nodes (entry and exit gateways) in WG enable mode to be working - -*QA will use this template for the other related WG tickets in this release milestone.* -~~~ -- [Standarise `ContractBuildInformation` and add it to all contracts](https://github.com/nymtech/nym/pull/4631): Similarly to `cw2`, we're now saving `ContractBuildInformation` under a constant storage key, i.e. `b"contract_build_info"` that standarises the retrieval by nym-api. - - Also each of our contracts now saves and updates that information upon init and migration. -~~~admonish example collapsible=true title='Testing steps performed' -- Use the latest release/chomp contracts and deploy these to QA -- Use the `nym-api` to query for the results of these new contracts - -```sh - curl -X 'GET' \ - 'https://qa-nym-api.qa.nymte.ch/api/v1/network/nym-contracts-detailed' \ - -H 'accept: application/json' -``` - -- It returns a detailed view of the contracts and which branch they were built from, alongside rust versions and so forth. -image -~~~ - -- [Update kernel peers on peer modification](https://github.com/nymtech/nym/pull/4622): -~~~admonish example collapsible=true title='Testing steps performed' -- This is a part of a bigger ticket, but initial testing has proven to shown that launching nym-nodes (entry and exit gateways) in WG enable mode to be working. -*QA will use this template for the other related WG tickets in this release milestone.* -~~~ - -- [Handle v6 and v7 requests in the IPR, but reply with v6](https://github.com/nymtech/nym/pull/4620): teach the IPR to read both v6 and v7 requests, but always reply with v6. This is to prepare for bumping to v7 and signed connect/disconnect messages. Follow up PRs will add - - Verify signature - - Send v7 in client with signatures included -- [Purge name service and service provider directory contracts](https://github.com/nymtech/nym/pull/4603): this is a compiler assisted purge of the `nym-name-service` and `nym-service-provider-directory` contracts that were never deployed on mainnet, and will anyhow be superseded by the new mixnode directory that is being worked on. -~~~admonish example collapsible=true title='Testing steps performed' -It works insofar that it compiles, we need to deploy and test this on non-mainnet before merging in - -- Purge `nym-name-service` contract -- Purge `nym-name-service-common` -- Purge `nym-service-provider-directory` contract -- Purge `nym-service-provider-directory-common` -- Remove everywhere name-service contract is used -- Remove everywhere sp contract is used - -Performed: -- Check references to everything named SP and Ephemera and removed any additional references -~~~ - -### Crypto - -- [Update crypto and rand crates](https://github.com/nymtech/nym/pull/4607): Update sphinx crate to `0.1.1` along with 25519 crates and `rand` crates -~~~admonish example collapsible=true title="Comments" -This PR contains a test failure due to the update [here](https://github.com/nymtech/nym/blob/b4a0487a41375167b2f481c00917b957b9f89789/common/crypto/src/asymmetric/encryption/mod.rs#L353-L358) - -- This is due a change in `x25519-dalek` from `1.1.1` to `2`. -- Crypto operations should be identical, but the byte representation has changed (sphinx clamps at creation, x25519 clamps at use). This cannot be changed in the sphinx crate without breaking changes. -- There is a good chance that this failure doesn't impact anything else, but it has to be tested to see. -- A mix of old and new clients with a mix of old and new mixnodes should do -~~~ - -### Bugfix -- [Make sure nym-api can handle non-cw2 (or without detailed build info) compliant contracts](https://github.com/nymtech/nym/pull/4648): fixes the issue (even if some contracts aren't uploaded on chain it doesn't prohibit the api from working - caveat, the essential vesting and mixnet contract are required) -~~~admonish example collapsible=true title='Testing steps performed' -- Use the latest release/chomp contracts and deploy these to QA -- If the contract was not found, the API would complain of invalid contracts, thus not starting the rest of the operations of the API (network monitor / rewarding etc) - - `Jun 11 16:27:34 qa-v2-nym-api bash[1352642]: 2024-06-11T16:27:34.551Z ERROR nym_api::nym_contract_cache::cache::refresher > Failed to refresh validator cache - Abci query failed with code 6 - address n14y2x8a60knc5jjfeztt84kw8x8l5pwdgnqg256v0p9v4p7t2q6eswxyusw: no such contract: unknown request` -~~~ - -- [Make sure to return an error on `nym-node` invalid public ip](https://github.com/nymtech/nym/pull/4646): bugfix for [#4630](https://github.com/nymtech/nym/pull/4630) that interestingly hasn't been detected by clippy. -~~~admonish example collapsible=true title='Testing steps performed' -- Use the latest release/chomp binary with nym-node and input a dodgy ip -image - -- Validation: -image -~~~ - -- [Extend the return error when connecting to gateway fails](https://github.com/nymtech/nym/pull/4626) -~~~admonish example collapsible=true title='Testing steps performed' -- Verify that the `establish_connection` function correctly attempts to establish a connection to the gateway. -- Test error handling for `NetworkConnectionFailed` by simulating a failed connection. -- Ensure that the `NetworkConnectionFailed` error includes the `address` and `source` details as expected. -- Checked that `SocketState::Available` is set correctly when a connection is successfully established. -~~~ - -- [Fix Cargo warnings](https://github.com/nymtech/nym/pull/4624): On every cargo command we have the set warnings: -~~~admonish example collapsible=true title="Cargo warnings" -warning: /home/alice/src/nym/nym/common/dkg/Cargo.toml: `default-features` is ignored for bls12_381, since `default-features` was not specified for `workspace.dependencies.bls12_381`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/dkg/Cargo.toml: `default-features` is ignored for ff, since `default-features` was not specified for `workspace.dependencies.ff`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/dkg/Cargo.toml: `default-features` is ignored for group, since `default-features` was not specified for `workspace.dependencies.group`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/client-libs/validator-client/Cargo.toml: `default-features` is ignored for bip32, since `default-features` was not specified for `workspace.dependencies.bip32`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/client-libs/validator-client/Cargo.toml: `default-features` is ignored for prost, since `default-features` was not specified for `workspace.dependencies.prost`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/credentials-interface/Cargo.toml: `default-features` is ignored for bls12_381, since `default-features` was not specified for `workspace.dependencies.bls12_381`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/credentials/Cargo.toml: `default-features` is ignored for bls12_381, since `default-features` was not specified for `workspace.dependencies.bls12_381`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/nymcoconut/Cargo.toml: `default-features` is ignored for bls12_381, since `default-features` was not specified for `workspace.dependencies.bls12_381`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/nymcoconut/Cargo.toml: `default-features` is ignored for ff, since `default-features` was not specified for `workspace.dependencies.ff`, this could become a hard error in the future warning: /home/alice/src/nym/nym/common/nymcoconut/Cargo.toml: `default-features` is ignored for group, since `default-features` was not specified for `workspace.dependencies.group`, this could become a hard error in the future. -~~~ - - This PR adds `default-features = false` to the workspace dependencies to fix these. An alternative way would be to remove `default-features = false` in the crates, but we assume these were put there for a good reason. Also we might have other crates outside of the main workspace that depends on these crates having default features disabled. - - We also have the warning `warning: profile package spec nym-wasm-sdk in profile release did not match any packages` which we fix by commenting out the profile settings, since the crate is currently commented out in the workspace crate list. -~~~admonish example collapsible=true title='Testing steps performed' -- All binaries have been built and deployed from this branch and no issues have surfaced. -~~~ - -### Operators Guide updates - -- [New Release Cycle](release-cycle.md) introduced: a transparent release flow, including: - - New environments - - Stable testnet - - [Testnet token faucet](https://nymtech.net/operators/sandbox.html#sandbox-token-faucet) - - Flow [chart](release-cycle.md#release-flow) -- [Sandbox testnet](sandbox.md) guide: teaching Nym node operators how to run their nodes in Nym Sandbox testnet environment. -- [Terms & Conditions flag](nodes/setup.md#terms--conditions) -- [Node API Check CLI](testing/node-api-check.md) -- [Pruning VPS `syslog` scripts](troubleshooting/vps-isp.md#pruning-logs) -- [Black-xit: Exiting the blacklist](troubleshooting/nodes.md#my-gateway-is-blacklisted) - ---- - -## `v2024.5-ragusa` - -- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.5-ragusa) -- [Release CHANGELOG.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.5-ragusa/CHANGELOG.md) -- [`nym-node`](nodes/nym-node.md) version `1.1.2` -~~~admonish example collapsible=true title='CHANGELOG.md' -- Feature/nym node api location ([#4605]) -- Add optional signature to IPR request/response ([#4604]) -- Feature/unstable tested nodes endpoint ([#4601]) -- nym-api: make report/avg_uptime endpoints ignore blacklist ([#4599]) -- removed blocking for coconut in the final epoch state ([#4598]) -- allow using explicit admin address for issuing freepasses ([#4595]) -- Use rfc3339 for last_polled in described nym-api endpoint ([#4591]) -- Explicitly handle constraint unique violation when importing credential ([#4588]) -- [bugfix] noop flag for nym-api for nymvisor compatibility ([#4586]) -- Chore/additional helpers ([#4585]) -- Feature/wasm coconut ([#4584]) -- upgraded axum and related deps to the most recent version ([#4573]) -- Feature/nyxd scraper pruning ([#4564]) -- Run cargo autoinherit on the main workspace ([#4553]) -- Add rustls-tls to reqwest in validator-client ([#4552]) -- Feature/rewarder voucher issuance ([#4548]) - -[#4605]: https://github.com/nymtech/nym/pull/4605 -[#4604]: https://github.com/nymtech/nym/pull/4604 -[#4601]: https://github.com/nymtech/nym/pull/4601 -[#4599]: https://github.com/nymtech/nym/pull/4599 -[#4598]: https://github.com/nymtech/nym/pull/4598 -[#4595]: https://github.com/nymtech/nym/pull/4595 -[#4591]: https://github.com/nymtech/nym/pull/4591 -[#4588]: https://github.com/nymtech/nym/pull/4588 -[#4586]: https://github.com/nymtech/nym/pull/4586 -[#4585]: https://github.com/nymtech/nym/pull/4585 -[#4584]: https://github.com/nymtech/nym/pull/4584 -[#4573]: https://github.com/nymtech/nym/pull/4573 -[#4564]: https://github.com/nymtech/nym/pull/4564 -[#4553]: https://github.com/nymtech/nym/pull/4553 -[#4552]: https://github.com/nymtech/nym/pull/4552 -[#4548]: https://github.com/nymtech/nym/pull/4548 -~~~ - -### Features - -- New `nym-node` API endpoint `/api/v1/auxiliary-details`: to expose any additional information. Currently it's just the location. `nym-api` will then query all nodes for that information and put it in the `self-described` endpoint. -- New `nym-node` location available - use one of the three options to add this to your node config: - 1. Update the `location` field under `[host]` section of `config.toml` - 2. For new nodes: Initialise the node with `--location` flag, where they have to provide the country info. Either full country name (e.g. 'Jamaica'), two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided. - 3. For existing nodes: It's also possible to use exactly the same `--location` argument as above, but make sure to also provide `--write-changes` (or `-w`) flag to persist those changes! -- [Feature/unstable tested nodes endpoint](https://github.com/nymtech/nym/pull/4601): Adds new data structures (`TestNode`, `TestRoute`, `PartialTestResult`) to handle test results for Mixnodes and Gateways. With the inclusion of pagination to handle large API responses efficiently. Lastly, introducing a new route with the tag `unstable` thus meaning not to be consumed without a user risk, prefixes in endpoints with unstable, are what it says on the tin. -~~~admonish example collapsible=true title='Testing steps performed' -- Deploy new api changes to sandbox environment -- Ensure current operations are transactional and standed operations are working -- Run a script to ensure that the new endpoints are working as expected with pagination - image -~~~ - -- [`nym-api`: make report/avg_uptime endpoints ignore blacklist](https://github.com/nymtech/nym/pull/4599): When querying for node specific data, it's no longer going to go through the entire list of all cached (and filtered nodes) to find it; instead it will attempt to retrieve a single unfiltered entry. -~~~admonish example collapsible=true title='Testing steps performed' -- Build the project and deployed it in a test environment. -- Manually test API endpoints for mixnode and gateway data. -- Verify that the endpoints return the expected data and handle blacklists correctly. -- API performance improved due to the efficient `HashMap` lookups -- Data in mainnet will differ from test nets due to the increased amount of gateways and mixnodes in that environment -- Test standard uptime routes: -```sh -curl -X 'GET' 'https://validator.nymtech.net/api/v1/status/gateway/Fo4f4SQLdoyoGkFae5TpVhRVoXCF8UiypLVGtGjujVPf/avg_uptime' -H 'accept: application/json' -``` -~~~ - -- [Use rfc3339 for last_polled in described nym-api endpoint](https://github.com/nymtech/nym/pull/4591): Fix issue where the validator-client can't parse the nym-api response for the described endpoint, in particular the `latest_polled` field that was recently added, by making the field use `rfc3339` - - **Note:** This will require upgrading `nym-api` and everything that depends on the described endpoint. -~~~admonish example collapsible=true title='Testing steps performed' -- Update a `nym-api` to the binary built from this branch, then restart the api -- Check the `journalctl` for error messages -- Connected via client and could not see the error messages, this is backwards compatible -- Local testing using sdk examples: -```sh -cd /nym/sdk/rust/nym-sdk -cargo run --example simple - -# outcome -thread 'main' panicked at sdk/rust/nym-sdk/examples/simple.rs:9:64: -called Result::unwrap() on an Err value: ClientCoreError(ValidatorClientError(NymAPIError { source: ReqwestClientError { source: reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, -``` -~~~ - -- [Upgrade `axum` and related dependencies to the most recent version](https://github.com/nymtech/nym/pull/4573) -- [Run cargo autoinherit on the main workspace](https://github.com/nymtech/nym/pull/4553): Move several dependencies to the workspace level using cargo autoinherit, to make it easier to keep our dependencies up to date. - - Run cargo autoinherit in the root - - Merge in the new workspace deps in the main list - - We made sure to not mix in other changes as well - all features flags for all crates should be the same as before -~~~admonish example collapsible=true title='Testing steps performed' -- Run `cargo autoinherit` in the root directory to move dependencies to the workspace level -- Merge the new workspace dependencies into the main list -- Ensure no other changes were mixed in during the process -- Verify that all feature flags for all crates remained the same as before -- Build all the binaries from this branch to confirm successful compilation -- Deploy the built binaries across different environments to ensure there were no issues -~~~ - -- [Add rustls-tls to reqwest in validator-client](https://github.com/nymtech/nym/pull/4552): An attempt to make possible to end up in a situation where use use the validator-client but without functioning TLS support. For the monorepo this is masked by cargo feature unification, but becomes a problem for outside consumers, as as been noticed in many of the vpn client implementations. - - In `validator-client`: `reqwest`, enable `rustls-tls` for `non-wasm32` - - In `client-core`: Use default features enabled for `non-wasm32` and switch to `webpki` roots, since that's what we're using with `reqwest` anyway - - In `gateway-client`: Switch to `webpki` roots, since that's what we're using with `reqwest` anyway - -#### Crypto - -- [Remove blocking for coconut in the final epoch state](https://github.com/nymtech/nym/pull/4598) -~~~admonish example collapsible=true title='Testing steps performed' -- Build the project to ensure no compilation errors -- Run tests to verify the functionality of the `issue_credential` function -- Execute integration tests to check the behaviour during an epoch transition. -~~~ - -- [Allow using explicit admin address for issuing freepasses](https://github.com/nymtech/nym/pull/4595) -- [Explicitly handle constraint unique violation when importing credential](https://github.com/nymtech/nym/pull/4588): Add a strong type for when a duplicate credential is imported so the vpn lib can handle this. -- [Feature/wasm coconut](https://github.com/nymtech/nym/pull/4584): This pull request requires [\#4585](https://github.com/nymtech/nym/pull/4585) to be merged first -- [Feature/nyxd scraper pruning](https://github.com/nymtech/nym/pull/4564): This PR introduces storage pruning to `nyxd` scraper which is then used by the validators rewarder. -~~~admonish example collapsible=true title='Testing steps performed' -- Add a `main.rs` file in the `nyxd` scraper dir, underneath `lib.rs`, amend `config.pruning_options.validate()?;` to be `let _ = config.pruning_options.validate();` in the mod.rs file -- Test the different variations of `pruning_options`: - - Check the *default* option: `pruning_options: PruningOptions::default()` - - Check the *nothing* option: `pruning_options: PruningOptions::nothing()` - - Check the *custom* option, example: `pruning_options: PruningOptions { keep_recent: (500), interval: (10), strategy: (PruningStrategy::Custom) }` - - Check the pruning *in real life* for the validator rewarder -- Validate that the database table `blocks` was being updated accordingly -~~~ - -- [Feature/rewarder voucher issuance](https://github.com/nymtech/nym/pull/4548) - - Introduces signature checks on issued credential data - - Stores evidence of any failures/malicious behaviour in the internal db - -### Bugfix - -- [`noop` flag for `nym-api` for `nymvisor` compatibility](https://github.com/nymtech/nym/pull/4586) - - The application starts correctly and logs the starting message - - The `--no_banner` flag works as intended, providing compatibility with `nymvisor` -~~~admonish example collapsible=true title='Testing steps performed' -- Build the project to ensure no compilation errors -- Run the binary with different command-line arguments to verify the CLI functionality -- Test with and without the `--no_banner` flag to ensure compatibility and expected behavior -- Verify logging setup and configuration file parsing -~~~ - -### Operators Guide updates - -- [`nym-gateway-probe`](testing/gateway-probe.md): A CLI tool to check in-real-time networking status of any Gateway locally. -- [Where to host your `nym-node`?](legal/isp-list.md): A list of Internet Service Providers (ISPs) by Nym Operators community. We invite all operators to add their experiences with different ISPs to strengthen the community knowledge and Nym mixnet performance. -- Make sure you run `nym-node` with `--wireguard-enabled false` and add a location description to your `config.toml`, both documented in [`nym-node` setup manual](nodes/setup.md#mode-exit-gateway). - - ---- - -## `v2024.4-nutella` - -- [Merged PRs](https://github.com/nymtech/nym/milestone/59?closed=1) -- [`nym-node`](nodes/nym-node.md) version `1.1.1` -- This release also contains: `nym-gateway` and `nym-network-requester` binaries -- core improvements on nym-node configuration -- Nym wallet changes: - - Adding `nym-node` command to bonding screens - - Fixed the delegation issues with fixing RPC -- [Network configuration](nodes/configuration.md#connectivity-test-and-configuration) section updates, in particular for `--mode mixnode` operators -- [VPS IPv6 troubleshooting](troubleshooting/vps-isp.md#ipv6-troubleshooting) updates - - ---- - -## `v2024.3-eclipse` - -- Release [Changelog.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.3-eclipse/CHANGELOG.md) -- [`nym-node`](nodes/nym-node.md) initial release -- New tool for monitoring Gateways performance [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net) -- New versioning `1.1.0+nymnode` mainly for internal migration testing, not essential for operational use. We aim to correct this in a future release to ensure mixnodes feature correctly in the main API -- New [VPS specs & configuration](nodes/vps-setup.md) page -- New [configuration page](nodes/configuration.md) with [connectivity setup guide](nodes/configuration.md#connectivity-test-and-configuration) - a new requirement for `exit-gateway` -- API endpoints redirection: Nym-mixnode and nym-gateway endpoints will eventually be deprecated; due to this, their endpoints will be redirected to new routes once the `nym-node` has been migrated and is running - -**API endpoints redirection** - -| Previous endpoint | New endpoint | -| --- | --- | -| `http://:8000/stats` | `http://:8000/api/v1/metrics/mixing` | -| `http://:8000/hardware` | `http://:8000/api/v1/system-info` | -| `http://:8000/description` | `http://:8000/api/v1/description` | diff --git a/documentation/old_docs/operators/src/coc.md b/documentation/old_docs/operators/src/coc.md deleted file mode 100644 index f8771a73bf..0000000000 --- a/documentation/old_docs/operators/src/coc.md +++ /dev/null @@ -1,17 +0,0 @@ -# Code of Conduct - -We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. - -Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all. - -Please be kind and courteous. There’s no need to be mean or rude. - -Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. - -Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. - -We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behaviour that excludes people in socially marginalized groups. - -Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust moderation team immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back. - -Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome. diff --git a/documentation/old_docs/operators/src/data/isp-sheet.csv b/documentation/old_docs/operators/src/data/isp-sheet.csv deleted file mode 100644 index f72973f924..0000000000 --- a/documentation/old_docs/operators/src/data/isp-sheet.csv +++ /dev/null @@ -1,26 +0,0 @@ -**ISP**,**Locations**,**Public IPv6**,**Crypto Payments**,**Comments**,**Last Updated** -[Flokinet](https://flokinet.is),"Netherlands, Iceland, Romania,France","Yes, needs a ticket and custom setup","yes, including XMR","Very slow customer support","05/2024" -[BitLaunch](https://bitlaunch.io),"Canada, USA, UK","No","Yes","Expensive. Digial Ocean through BitLanch has IPv6","05/2024" -[Hostinger](https://hostinger.com),"France, Lithuania, India, USA, Brazil","Yes, out of the box","Yes","Crypto payments must be done per each server monthly or annually.","05/2024" -[Linode](https://linode.com),"USA, Canada, Japan, India, Indonesia, Sweden, Netherlands, Germany, Brazil, France, UK, Australia, Italy","Yes out of the box","No, only through [BitLAunch](https://bitlaunch.io)","IPv6 sometimes need to be re-added in Networking tab, no reboot needed","05/2024" -[Cherry Servers](https://www.cherryservers.com),"Lithuania, Netherlands, USA, Singapore","No","Yes","Issued IP doesn’t match the location offered by the provider.","05/2024" -[Njalla](https://nja.la),"Sweden","Yes","Yes","Privacy vandguards! The biggest VPS 45 is 3 cores only, but it works better than many “larger” servers on the market.","05/2024" -[HostSailor](https://hostsailor.com),"USA","Yes, based on ticket","Yes","The IPv6 setup needs custom research and is not documented","05/2024" -[Misaka](https://www.misaka.io/),"South Africa","Yes, native support","No","Very Expensive","05/2024" -[IsHosting](https://ishosting.com/en),"Brazil, Netherlands","Yes, based on ticket","Yes","Expensive","05/2024" -[AlexHost](https://alexhost.com),"Moldova, Bulgaria, Sweden, Netherlands","Yes, on by default","Yes","They allow TOR Bridges, Relays. Exit nodes are only allowed on dedicated servers (prices start from 26 EUR)","07/2024" -[iHostArt](https://ihostart.com),"Romania","Yes, on by default","Yes","Super permissive provider. They do allow Tor Exit/Relay/Bridge. Pro-free speech etc. Recently, IPv6 geolocation was set to North Korea, so be aware.","07/2024" -[Incognet](https://incognet.io),"Netherlands and USA","Yes, on by default","Yes","They allow Tor exit nodes but you must adhere to their rules https://incognet.io/tor-exits","07/2024" -[vSys Host](https://vsys.host),"Ukraine, Netherlands, USA","Yes, on by default","Yes","Pretty permissive provider registered in Ukraine. Should allow Relay/Exit nodes but nothing in T&C, so better double check.","07/2024" -[LiteServer](https://liteserver.nl),"Netherlands","Yes, on by default","Yes","Very reliable Dutch provider. They do allow Relay nodes but for Exit nodes you need to contact them. Always check T&C https://liteserver.nl/legal","07/2024" -[TerraHost](https://terrahost.no),"Norway","Yes, on by default","Yes","Very reliable Norwegian provider. Only allow exit nodes on Dedicated servers subject to certain caveats (you must open a ticket). Always check T&C https://terrahost.no/avtalebetingelser","07/2024" -[Mevspace](https://mevspace.com),"Poland","Yes, on by default","Yes","Flexible Polish providers with 3 DCs in Poland. They do allow Tor Exit nodes but you may need a dedicated server for this. Make sure you open a ticket to check. As of today's date, they have 48h for 1 EUR tariff","07/2024" -[Hostiko](https://hostiko.com.ua),"Ukraine, Germany","Yes, on by default","Yes","Ukrainian provider. They allow Exit nodes on Germany boxes but limit the bandwidth, you also have to restrict certain ports like 25 and 587. Make sure you open a ticket.","07/2024" -[Hostslick](https://hostslick.com),"Netherlands, Germany","Yes, on by default","Yes","Good amount of bandwidth for the price. Make sure you open the ticket if you want to run Exit node","07/2024" -[RDP](https://rdp.sh),"Netherlands, USA, Poland","Yes, on by default","Yes","German provider. Exit nodes are allowed, policy is here https://rdp.sh/docs/faq/tor ports 25,465,587 must be closed. Make sure you open a ticket before running an exit node.","07/2024" - - - - - - diff --git a/documentation/old_docs/operators/src/faq/general-faq.md b/documentation/old_docs/operators/src/faq/general-faq.md deleted file mode 100644 index df8587872b..0000000000 --- a/documentation/old_docs/operators/src/faq/general-faq.md +++ /dev/null @@ -1,42 +0,0 @@ -# General Operators FAQ - -## Nym Mixnet - -To see different stats about Nym Mixnet live, we recommend you to visit [status.notrustverify.ch](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1) built by [No Trust Verify](https://notrustverify.ch/) crew, one of the squads within Nym core community. - - - - -### Is there an explorer for Nym Mixnet? - -Yes, there are several places, some are built by Nym core community: - -* [Nym Explorer](https://explorer.nymtech.net/) -* [Guru Explorer](https://mixnet.explorers.guru/) -* [ExploreNYM](https://explorenym.net/) - -### Which VPS providers would you recommend? - -Consider in which jurisdiction you reside and where do you want to run a Mix Node. Do you want to pay by crypto or not and what are the other important particularities for your case? We always recommend operators to try to choose smaller and decentralised VPS providers over the most known ones controlling a majority of the internet. We receive some good feedback on these: Linode, Gandi, Flokinet and Exoscale. Do your own research and share with the community. - -### Why is a node setup on a self-hosted machine so tricky? - -We don't recommend this setup because it's really difficult to get a static IP and route IPv6 traffic. - -### What's the Sphinx packet size? - -The sizes are shown in the configs [here](https://github.com/nymtech/nym/blob/1ba6444e722e7757f1175a296bed6e31e25b8db8/common/nymsphinx/params/src/packet_sizes.rs#L12) (default is the one clients use, the others are for research purposes, not to be used in production as this would fragment the anonymity set). More info can be found [here](https://github.com/nymtech/nym/blob/4844ac953a12b29fa27688609ec193f1d560c996/common/nymsphinx/anonymous-replies/src/reply_surb.rs#L80). - -### Why a Mix Node and a Gateway cannot be bonded with the same wallet? - -Because of the way the smart contract works we keep it one-node one-address at the moment. - -### Which nodes are the most needed to be setup to strengthen Nym infrastructure and which ones bring rewards? - -Ath this point the most crutial component needed are [Exit Gateways](../legal/exit-gateway.md). - -### Are Nym Nodes whitelisted? - -Nope, anyone can run a Nym Node. whether your node is chosen to mix is purely reliant on the node's performance and reputation (self stake + delegations). - - diff --git a/documentation/old_docs/operators/src/faq/nym-nodes-faq.md b/documentation/old_docs/operators/src/faq/nym-nodes-faq.md deleted file mode 100644 index d0a65b2ec0..0000000000 --- a/documentation/old_docs/operators/src/faq/nym-nodes-faq.md +++ /dev/null @@ -1,32 +0,0 @@ -# Nym Nodes related Frequently Asked Questions - -### What determines the rewards when running a `nym-node --mode mixnode`? - -The stake required for a Mix Node to achieve maximum rewards is called Mix Node saturation point. This is calculated from the staking supply (all circulating supply + part of unlocked tokens). The target level of staking is to have 40% of the staking supply locked in Mix Nodes. - -The node stake saturation point, which we denote by Nsat, is given by the stake supply, target level of staking divided between the rewarded nodes. - -This design ensures the nodes aim to have a same size of stake (reputation) which can be done by delegation staking, as well as it secures a whale prevention and decentralization of staking, as any higher level of delegated $NYM than Nsat per node results in worsening reward ratio. On the contrary, the more Mix Nodes are active, the lower is Nsat. The equilibrium is reached when the staked tokens are delegated equally across the active Mix nodes and that's our basis for this incentive system. - - - -The rewarded nodes are the nodes which will receive some rewards by the end of the given epoch. These can be separated further separated into: - -1. Active: Top *N* nodes of the rewarded set (currently all of them but this can change), these are nodes which are used by the clients and mix packets. - -2. Standby: Bottom *N* nodes of the rewarded set, they don't mix data from the clients but are used for testing. Their reward is smaller. - - -For more detailed calculation, read our blog post [Nym Token Economics update](https://blog.nymtech.net/nym-token-economics-update-fedff0ed5267). More info on staking can be found [here](https://blog.nymtech.net/staking-in-nym-introducing-mainnet-mixmining-f9bb1cbc7c36). And [here](https://blog.nymtech.net/want-to-stake-in-nym-here-is-how-to-choose-a-mix-node-to-delegate-nym-to-c3b862add165) is more info on how to choose a Mix Node for delegation. And finally an [update](https://blog.nymtech.net/quarterly-token-economic-parameter-update-b2862948710f) on token economics from July 2023. - - - - - -*More graphs and stats at [stats.notrustverify.ch](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1&from=1703074861988&to=1705666862004).* - - diff --git a/documentation/old_docs/operators/src/faq/nyx-faq.md b/documentation/old_docs/operators/src/faq/nyx-faq.md deleted file mode 100644 index bbef752dfe..0000000000 --- a/documentation/old_docs/operators/src/faq/nyx-faq.md +++ /dev/null @@ -1,29 +0,0 @@ -## Validators and tokens - -### What's the difference between NYM and uNYM? - -1 NYM = 1 000 000 uNYM - - - -### Why some Nyx blockchain operations take one hour and others are instant? - -This is based on the definition in [Nym's CosmWasm](https://github.com/nymtech/nym/tree/develop/common/cosmwasm-smart-contracts) smart contracts code. - -Whatever is defined as [a pending epoch event](https://github.com/nymtech/nym/blob/b07627d57e075b6de35b4b1a84927578c3172811/common/cosmwasm-smart-contracts/mixnet-contract/src/pending_events.rs#L35-L103) will get resolved at the end of the current epoch. - -And whatever is defined as [a pending interval event](https://github.com/nymtech/nym/blob/b07627d57e075b6de35b4b1a84927578c3172811/common/cosmwasm-smart-contracts/mixnet-contract/src/pending_events.rs#L145-L172) will get resolved at the end of the current interval. - -### Can I run a validator? - -We are currently working towards building up a closed set of reputable validators. You can ask us for coins to get in, but please don't be offended if we say no - validators are part of our system's core security and we are starting out with people we already know or who have a solid reputation. - -### Why is validator set entry whitelisted? - -We understand that the early days of the Nyx blockchain will face possible vulnerabilities in terms of size - easy to disrupt or halt the chain if a malicious party entered with a large portion of stake. Besides that, there are some legal issues we need to address before we can distribute the validator set in a fully permissions fashion. - -### Why does Nym do airdrops? - -It is part of ensuring decentralisation - we need to avoid a handful of people having too much control over the token and market. Of course ideally people will stake the tokens and contribute to the project at this stage. We run surveys to better understand what people are doing with their tokens and what usability issues there are for staking. Any feedback is appreciated as it helps us improve all aspects of using the token and participating in the ecosystem. diff --git a/documentation/old_docs/operators/src/images/grafana/add-data-source-prometheus.png b/documentation/old_docs/operators/src/images/grafana/add-data-source-prometheus.png deleted file mode 100644 index c9bae39f39..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/add-data-source-prometheus.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/grafana/add-data-sources-button.png b/documentation/old_docs/operators/src/images/grafana/add-data-sources-button.png deleted file mode 100644 index 9f90c5643a..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/add-data-sources-button.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/grafana/add-data-sources.png b/documentation/old_docs/operators/src/images/grafana/add-data-sources.png deleted file mode 100644 index 6ec2b2fb7b..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/add-data-sources.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/grafana/add-prometheus.png b/documentation/old_docs/operators/src/images/grafana/add-prometheus.png deleted file mode 100644 index c25dae3b69..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/add-prometheus.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/grafana/id-1860.png b/documentation/old_docs/operators/src/images/grafana/id-1860.png deleted file mode 100644 index 3c277642b5..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/id-1860.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/grafana/import-dashboard.png b/documentation/old_docs/operators/src/images/grafana/import-dashboard.png deleted file mode 100644 index 2a17aed7a5..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/import-dashboard.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/grafana/menu-data-sources.png b/documentation/old_docs/operators/src/images/grafana/menu-data-sources.png deleted file mode 100644 index 6073d2dae9..0000000000 Binary files a/documentation/old_docs/operators/src/images/grafana/menu-data-sources.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/ip_table_prompt.png b/documentation/old_docs/operators/src/images/ip_table_prompt.png deleted file mode 100644 index dadd006b58..0000000000 Binary files a/documentation/old_docs/operators/src/images/ip_table_prompt.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/ipv6_64.png b/documentation/old_docs/operators/src/images/ipv6_64.png deleted file mode 100644 index 505202d00b..0000000000 Binary files a/documentation/old_docs/operators/src/images/ipv6_64.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/sandbox.png b/documentation/old_docs/operators/src/images/sandbox.png deleted file mode 100644 index 4059ad8c17..0000000000 Binary files a/documentation/old_docs/operators/src/images/sandbox.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/wallet-screenshots/bonding.png b/documentation/old_docs/operators/src/images/wallet-screenshots/bonding.png deleted file mode 100644 index b5cef3bb89..0000000000 Binary files a/documentation/old_docs/operators/src/images/wallet-screenshots/bonding.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/wallet-screenshots/new_http_port.png b/documentation/old_docs/operators/src/images/wallet-screenshots/new_http_port.png deleted file mode 100644 index 7db2a30d72..0000000000 Binary files a/documentation/old_docs/operators/src/images/wallet-screenshots/new_http_port.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/wallet-screenshots/node_settings.png b/documentation/old_docs/operators/src/images/wallet-screenshots/node_settings.png deleted file mode 100644 index 69568ce6a5..0000000000 Binary files a/documentation/old_docs/operators/src/images/wallet-screenshots/node_settings.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/wallet-screenshots/old_http_port.png b/documentation/old_docs/operators/src/images/wallet-screenshots/old_http_port.png deleted file mode 100644 index 5d92ecb233..0000000000 Binary files a/documentation/old_docs/operators/src/images/wallet-screenshots/old_http_port.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/wallet-screenshots/wallet-gateway-sign.png b/documentation/old_docs/operators/src/images/wallet-screenshots/wallet-gateway-sign.png deleted file mode 100644 index 63a76aaf4d..0000000000 Binary files a/documentation/old_docs/operators/src/images/wallet-screenshots/wallet-gateway-sign.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/images/wallet-screenshots/wallet-sign.png b/documentation/old_docs/operators/src/images/wallet-screenshots/wallet-sign.png deleted file mode 100644 index a31dddd391..0000000000 Binary files a/documentation/old_docs/operators/src/images/wallet-screenshots/wallet-sign.png and /dev/null differ diff --git a/documentation/old_docs/operators/src/introduction.md b/documentation/old_docs/operators/src/introduction.md deleted file mode 100644 index fe4cd0664c..0000000000 --- a/documentation/old_docs/operators/src/introduction.md +++ /dev/null @@ -1,45 +0,0 @@ -# Introduction - -This is Nym's Operators guide, containing information and setup guides for the various pieces of Nym Mixnet infrastructure and Nyx blockchain validators. - -``` - ┌─►mix──┐ mix mix - │ │ - Entry │ │ Exit -client ───► Gateway ──┘ mix │ mix ┌─►mix ───► Gateway ───► internet - │ │ - │ │ - mix └─►mix──┘ mix -``` - -If you are new to Nym and want to learn about the Mixnet, explore kickstart options and demos, learn how to integrate with the network, and follow developer tutorials check out the [Developer Portal](https://nymtech.net/developers/). - -If you want to dive deeper into Nym's architecture, clients, nodes, and SDK examples visit the [technical docs](https://nymtech.net/docs/). - - -## Popular pages - -**Binary Information** - -* [Building Nym](binaries/building-nym.md) -* [Pre-built Binaries](binaries/pre-built-binaries.md) - -**Node setup and usage guides:** - -* [Nym Node](nodes/nym-node.md) -* [Nymvisor](nodes/nymvisor-upgrade.md) -* [Validators](nodes/validator-setup.md) -* [Nym API Setup](nodes/nym-api.md) - -**Maintenance, troubleshooting and FAQ** - -* [FAQ](faq/nym-nodes-faq.md) -* [Maintenance](nodes/maintenance.md) -* [Troubleshooting](troubleshooting/nodes.md) - -**Community Legal Forum** - -* [Exit Gateway](legal/exit-gateway.md) -* [Community Counsel](legal/community-counsel.md) -* [How to Add Info](legal/add-content.md) - diff --git a/documentation/old_docs/operators/src/legal/add-content.md b/documentation/old_docs/operators/src/legal/add-content.md deleted file mode 100644 index a770b9d4d6..0000000000 --- a/documentation/old_docs/operators/src/legal/add-content.md +++ /dev/null @@ -1,58 +0,0 @@ -# Adding Content to Legal Forum - -Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in, to share solutions to the challenges they encountered when running Exit Gateway, and create a pull request (PR). - -First of all, please join our [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) and post any information or questions there. - -To add your information to this book, you can create a PR directly to our [repository](https://github.com/nymtech/nym/tree/develop/documentation/operators/src/legal). - -**Steps to make a pull request:** - -1. Write down your legal findings, suggestions, communication templates, FAQ in a text editor - -2. Clone `nymtech/nym` repository or pull in case you already have it and switch to `develop` branch - -```sh -# clone the repository -git clone https://github.com/nymtech/nym - -# go to the directory nym -cd nym - -# switch to branch develop -git checkout develop - -# update the repository -git pull origin develop -``` - -3. Make your own branch based off `develop` and switch to it - -```sh -# choose a descriptive and consise name without using <> -git checkout -b operators/legal-forum/ - -# example: git checkout -b operators/legal-forum/alice-vps-faq-template - -# you can double check that you are on the right branch -git branch -``` - -4. Save your legal findings as `.md` to `/nym/documentation/operators/src/legal` or add info to an existing page - -5. **Don't change anything in `SUMMARY.md`**, the admins will do it when merging - -6. Add, commit and push your changes - -```sh -cd documentation/operators/src/legal -git add .md -git commit -am "" -git push origin operators/legal-forum/ -``` -7. Open the git generated link in your browser, fill the description and click on `Create a Pull Request` button -```sh -# the url will look like this - https://github.com/nymtech/nym/pull/new/operators/legal-forum/ -``` -8. Notify others in the [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) about the PR. diff --git a/documentation/old_docs/operators/src/legal/community-counsel.md b/documentation/old_docs/operators/src/legal/community-counsel.md deleted file mode 100644 index aa0418f43d..0000000000 --- a/documentation/old_docs/operators/src/legal/community-counsel.md +++ /dev/null @@ -1,11 +0,0 @@ -# Community Counsel - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -Running an Exit Gateway is a commitment and as such is exposed to various challenges. Besides different legal regulations typical difficulties may be dealing with VPS or ISP providers. Our strength lies in decentralised community of squads and individuals supporting each other. Sharing examples of [landing pages](landing-pages.md), templates for communication and FAQs is a great way to empower other operators sharing the mission of liberating internet. Below is a simple way how to create a pull request directly to Nym Operator Guide book. - -## How to add content - -Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](add-content.md). diff --git a/documentation/old_docs/operators/src/legal/exit-gateway.md b/documentation/old_docs/operators/src/legal/exit-gateway.md deleted file mode 100644 index bea236d28c..0000000000 --- a/documentation/old_docs/operators/src/legal/exit-gateway.md +++ /dev/null @@ -1,141 +0,0 @@ -# Nym Operators Legal Forum: Running Exit Gateway - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -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. [**Nym exit policy**](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) is a combination of safeguards like (nowadays deprecated) `Tor Null deny list` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy aims to find a healthy compromise between protecting the operators and NymVPN users against attacks while allowing for as wide experience when accessing the internet through Nym Network. - - -All the technical changes on the side of Nym nodes - ***Project Smoosh*** - are described in the [FAQ section](../archive/faq/smoosh-faq.md). - -```admonish warning -Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the operator channels ([Element](https://matrix.to/#/#operators:nymtech.chat), [Discord](https://nymtech.net/go/discord), [Telegram](https://t.me/nymchan_help_chat)) to share best practices and experiences. -``` - - -## 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. - -* 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. - -* 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 (nowadays deprecated) `Tor Null deny list` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)) - -* 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. - -* Nym core team cannot provide operators with definitive answers regarding the potential risks of operating open Gateways. However, there is online evidence of operating Tor exit relays: - * From a technical perspective, Nym node operators may need to implement additional controls, such as dedicated hardware and IP usage, or setting up an HTML exit notice on port 80. - * From an operational standpoint, node operators may be expected to actively manage their relationship with their ISP or VPS provider and respond to abuse requests using the proposed templates. - * Legally, exit relays are typically considered "telecommunication networks" and are subject to intermediary liability protection. However, there may be exceptions, particularly in cases involving criminal law and copyright claims. Operators could seek advice from local privacy associations and may consider running nodes under an entity rather than as individuals. - -* This document serves as the basis for a consultation with Nym node operators on any concerns or additional support and information you need for this change to be successful and ensure maximum availability, usability and adoption. - -## Goal of the initiative - -**Nym supports privacy for everyone, everywhere.** - -To offer a better and more private everyday experience for its users, Nym would like them to use any online services they please, without limiting its access to a few messaging apps or crypto wallets. - -To achieve this, operators running Exit Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays following this [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). - -## Pros and cons of the initiative - -Previous setup: Running nodes supporting strict SOCKS5 app-based traffic - -| **Dimension** | **Pros** | **Cons** | -| :--- | :--- | :--- | -| Aspirational | | - Very limited use cases, not supportive of the “Privacy for everyone everywhere” aspiration
- Limited appeal to users, low competitiveness in the market, thus low usage | -| 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 | - - -The new setup: Running nodes supporting traffic of any online service (with safeguards in the form of a denylist) - -| **Dimension** | **Pros** | **Cons** | -| :--- | :--- | :--- | -| Aspirational | - Higher market appeal of a fully-fledged product able to answer all users’ use cases
- Relevance in the market, driving higher usage | | -| Technical | - Very limited changes required in the technical setup (changes in the allow -> denylist) | - Increased monitoring required to detect and prevent abuse (e.g. spam) | -| Operational | | - Higher operational overhead, such as dealing with DMCA / abuse complaints, managing the VPS provider questions, or helping the community to maintain the denylist
- Administrative overhead if running nodes as a company or an entity | -| Legal | | - Ideally requires to check legal environment with local privacy association or lawyer | Financial | - Higher revenue potential for operators due to the increase in network usage | - If not running VPS with an unlimited bandwidth plan, higher costs due to higher network usage | - -## 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. - -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). - -As of now we the Gateways will be defaulted to a combination of (nowadays deprecated) `Tor Null deny list` (note: Tornull is not affiliated with Tor Project) - 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` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy will remain the same for all the nodes, without any option to modify it by Nym node operators individually, to secure stable and reliable service for the end users. - -For exit relays on ports 80 and 443, the Gateways will exhibit an HTML page resembling the one proposed by [Tor](https://gitlab.torproject.org/tpo/core/tor/-/raw/HEAD/contrib/operator-tools/tor-exit-notice.html). By doing so, the operator will be able to disclose details regarding their Gateway, including the currently configured exit policy, all without the need for direct correspondence with regulatory or law enforcement agencies. It also makes the behavior of Exit Gateways transparent and even computable (a possible feature would be to offer a machine readable form of the notice in JSON or YAML). - -We also recommend operators to check the technical advice from [Tor](https://community.torproject.org/relay/setup/exit/). - -## Tor legal advice - -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: -> This FAQ is for informational purposes only and does not constitute legal advice. - -*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](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) -* Top 3 advice - - Have an abuse response letter - - Run relay from a location that is not home - - Read through the legal resources that Tor-supportive lawyers put together: [www.eff.org/pages/legal-faq-tor-relay-operators](https://www.eff.org/pages/legal-faq-tor-relay-operators) or [www.noisebridge.net/wiki/Noisebridge_Tor/FBI](https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI) -* 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* - -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 - -*Be ready to respond to abuse complaints* - -* Make your contact details (email, phone, or even fax) available, instead of those of the ISP -* Reply in a timely manner (e.g., 24 hours) using the [provided templates](https://community.torproject.org/relay/community-resources/tor-abuse-templates) -* 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: - -* Tor abuse templates: - - [community.torproject.org/relay/community-resources/tor-abuse-templates/](https://community.torproject.org/relay/community-resources/tor-abuse-templates/) - - [gitlab.torproject.org/legacy/trac/-/wikis/doc/TorAbuseTemplates](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorAbuseTemplates) (from 2020) - - [github.com/coldhakca/abuse-templates/blob/master/generic.template](https://github.com/coldhakca/abuse-templates/blob/master/generic.template) - -* DMCA response templates: - - [community.torproject.org/relay/community-resources/eff-tor-legal-faq/tor-dmca-response/](https://community.torproject.org/relay/community-resources/eff-tor-legal-faq/tor-dmca-response/) - - [2019.www.torproject.org/eff/tor-dmca-response.html](https://2019.www.torproject.org/eff/tor-dmca-response.html) (from 2011) - - [github.com/coldhakca/abuse-templates/blob/master/dmca.template](https://github.com/coldhakca/abuse-templates/blob/master/dmca.template) - - -## Legal environment of Nym Exit Gateway - -The Node Operators Legal Forum pages are divided according [jurisdictions](jurisdictions.md). Read below to learn [how to add](add-content.md) findings about your jurisdiction or edit existing info. - -## Community Counsel - -Nym Node operators are invited to add their legal findings or helpful suggestions directly through [pull requests](add-content.md). This can be done as a new legal information (or entire new country) to the list of [jurisdictions](jurisdictions.md) or in a form of an advice to [Community counsel pages](community-counsel.md), sharing examples of Exit Gateway [landing pages](landing-pages.md), templates etcetra. - -## How to add content - -Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](add-content.md). diff --git a/documentation/old_docs/operators/src/legal/isp-list.md b/documentation/old_docs/operators/src/legal/isp-list.md deleted file mode 100644 index e11c786d8a..0000000000 --- a/documentation/old_docs/operators/src/legal/isp-list.md +++ /dev/null @@ -1,25 +0,0 @@ -# Where to host your `nym-node`? - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -Inspired by a valuable resource, done by Tor community - [*Good Bad ISPs*](https://community.torproject.org/relay/community-resources/good-bad-isps/), LunarDAO squad initiated a table customised for Nym Exit Gateways operators. - -This ISP list is fully managed by Nym operator community and it serves as a space to share their experience of running Exit Gateways on various Internet Service Providers (ISPs). The ISPs greatly differ in regards to services they offer as well as to their openess of hosting exit routing software. - -Please share any experiences running a node like policies, complains, legal issues and solutions, discrepancy between offers and reality (bandwidth, IP range, locations) or anything regarding pricing or customer support. - -If you came across any legal findings, please share them in our [list of jurisdictions](jurisdictions.md). - -While we trust that Nym node operators are honest, we would like to ask everyone to do your own research. - -```admonish caution title="" -To edit or add information to the ISP list, make changes to the csv file located [here](https://github.com/nymtech/nym/blob/develop/documentation/operators/src/data/isp-sheet.csv) and submit your edits as a pull request according to [this guide](add-content.md). -``` - -```admonish note title="" -As of now the list is quite short. When it grows, we can divide it according the localities of the listed ISPs. -``` - - diff --git a/documentation/old_docs/operators/src/legal/jurisdictions.md b/documentation/old_docs/operators/src/legal/jurisdictions.md deleted file mode 100644 index a629626695..0000000000 --- a/documentation/old_docs/operators/src/legal/jurisdictions.md +++ /dev/null @@ -1,19 +0,0 @@ -# Exit Gateway - Jurisdictions - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -```admonish warning -The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences. -``` - -There is no one silver bullet covering the entire globe. Every jurisdiction has different set of laws and practices regarding internet traffic routing. Therefore the Node Operators Legal Forum pages are divided per region. - -These are some findings from our legal team as an example: - -- [Switzerland](swiss.md) -- [United States](united-states.md) - -> Nym Node operators are invited to add their legal findings directly through [pull requests](add-content.md). - diff --git a/documentation/old_docs/operators/src/legal/landing-pages.md b/documentation/old_docs/operators/src/legal/landing-pages.md deleted file mode 100644 index 0e39e56cef..0000000000 --- a/documentation/old_docs/operators/src/legal/landing-pages.md +++ /dev/null @@ -1,13 +0,0 @@ -# Landing Pages - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -> Nym Node operators are invited to add their legal findings and suggestions directly through [pull requests](add-content.md). - -Exit Gateway landing page is a great and transparent way to prevent possible troubles by providing people with basic facts, links to laws and regulations on a given topic as well as operator's contact info. To inspire each other we share some examples how Nym community handled this issue below. - -## Avril 14th Exit Gateways - -Visit [Reversed Proxy: Avril 14th Exit Gateways Guide](../nodes/proxy-configuration.md#reversed-proxy-avril-14th-exit-gateways-guide) and follow the guide to setup your landing page. diff --git a/documentation/old_docs/operators/src/legal/swiss.md b/documentation/old_docs/operators/src/legal/swiss.md deleted file mode 100644 index b879123d85..0000000000 --- a/documentation/old_docs/operators/src/legal/swiss.md +++ /dev/null @@ -1,77 +0,0 @@ -# Legal environment: Switzerland - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -```admonish warning -The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences. -``` - -## Findings from our legal team - -> **Note:** The information shared below is in the stage of conclusions upon final confirmation. The text is a not edited exert from a legal counsel. Nym core team is asking for more clarifications. - -### Operators of Exit Nodes - -#### Telecoms Law - -As well as operators of normal mixnet nodes, operators of exit nodes might be considered telecommunications providers according to the broad term of the telecommunications act (TCA). -The regulatory consequences have already been laid out in section 5.1.2.2.1 above. - -#### Telecoms Surveillance Law - -Unlike normal mixnet nodes, exit nodes might have information about the communication party which uses the respective exit node (in particular its IP address). They might therefore be a target for surveillance authorities, at least at first glance. - -However, as the IP address of the communications party is disguised on the other side of the communications through the Nym encryption infrastructure, the usual situation, where an IP address or another trace of an Internet user is found in the connection with a criminal activity (e.g., in a web server protocol), and then used in cooperation with the user’s provider to identify the user, is not going to take place. - -The same is true for the opposite side: The node operator does not see the communication party of his user. - -Experience has shown that Swiss investigative authorities are aware of these limitations and do not conduct investigations against individuals who operate TOR nodes, for example. In one specific case that I know of, the investigation was stopped by the police as soon as it was clear that a TOR node was being operated. - -I therefore consider the risk for an exit node operator to become involved in a SPTA proceeding as low. - -Nevertheless, in such a situation, exit node operators providers would have to provide the authorities with the information already available to them (Art. 22 Para. 3 SPTA), and they would have to tolerate monitoring by the authorities or by the persons commissioned by the service of the data which the monitored person transmits or stores using derived communications services (Art. 27 Para. 1 SPTA; see above, 5.1.1.2). There is no duty of data retention for providers of derived communication services, though. - -The the risk for exit node operators of being upgraded according to Art. 22 Para. 4 SPTA is low to non existent for the reasons mentioned above. - -#### Intelligence Service Law - -Operators of exit nodes do not provide wire-based telecommunications services either and therefore do not fall under the IntelSA. - -### Nym as VPN provider - -#### Telecoms Law - -Nym as a VPN operator might be considered a telecommunication provider under the newly revised TCA, as the term now also covers operators of Over-the-Top services which are carried out over the internet. - -However I consider possible administrative burdens arising from this qualification as negligible (see above, 5.1.2.1). - -#### Telecoms Surveillance Law - -VPN providers have information about the communication party which uses the respective exit node (in particular its IP address). They might therefore be a target for surveillance authorities, at least at first glance. - -However, for the same reason I see a risk low for exit node operators to become involved in a SPTA proceeding (the IP address is not visible to the communication partner, which is exactly the reason the Nym VPN is being used at all), I also see a low risk for Nym itself to become involved in such a proceeding (see above, 5.1.3.2). - -#### Intelligence Service Law - -VPN operators do not provide wire-based telecommunications services and therefore do not fall under the IntelSA. - -### EU chat control regulation in particular - -According to a EU commission proposal for a regulation laying down rules to prevent and combat child sexual abuse (https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX: 52022PC0209) hosting providers and providers of so-called interpersonal communication services should be obliged to perform an assessment of risks of online child sexual abuse. Additionally an obligation for certain providers should be established to detect such abuse, to report it via the EU Centre, to remove or disable access to, or to block online child sexual abuse material when so ordered. - -'Interpersonal communications service’ means a service normally provided for remuneration that enables direct interpersonal and interactive exchange of information via electronic communications networks between a finite number of persons, whereby the persons initiating or participating in the communication determine its recipient(s) and does not include services which enable interpersonal and interactive communication merely as a minor ancillary feature that is intrinsically linked to another service (Art. 2 Point 5 Directive (EU) 2018/1972, which is also relevant for the mentioned proposal). - -Interpersonal communications services are services that enable interpersonal and interactive exchange of information. Interactive communication entails that the service allows the recipient of the information to respond. The proposal therefore only covers services like traditional voice calls between two individuals but also all types of emails, messaging services, or group chats. Examples for services which do not meet those requirements are linear broadcasting, video on demand, websites, social networks, blogs, or exchange of information between machines (Directive (EU) 2018/1972, Consideration 17). - -Neither the Nym encryption infrastructure nor the NYM VPN are used as means for an interactive exchange of information in the aforementioned sense (of e-mail, messaging, chats or similar). - -I therefore consider the risk arising from the mentioned proposal for Nym as low, be it as software developer or VPN operator. - -However, an application provider which uses the Nym encryption infrastructure to provide encrypted chat services or similar could still fall under the proposal. This might pose a commercial risk for Nym as the provider of the basic infrastructure for such services, because such services might lose their commercial value for end customers. - -Currently the EU decision on chat control has been postponed because there is a blocking minority which can prevent the adoption of the respective parts of the law. In addition, even EU internal lawyers held that the proposal was clearly in violation of the EU charter of fundamental rights and would therefore be nullified by the EU courts in case it would still be enacted by the parliament. - -I therefore consider the risk that the mentioned proposal is enacted by the EU authorities and finally upheld by the courts in its planned form as low. - diff --git a/documentation/old_docs/operators/src/legal/united-states.md b/documentation/old_docs/operators/src/legal/united-states.md deleted file mode 100644 index ce541b3028..0000000000 --- a/documentation/old_docs/operators/src/legal/united-states.md +++ /dev/null @@ -1,25 +0,0 @@ -# Legal environment: United States - -```admonish info -The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/). -``` - -```admonish warning -The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences. -``` - -## Findings from our legal team - -> **Note:** The information shared below is in the stage of conclusions upon final confirmation. The text is a not edited exert from a legal counsel. Nym core team is asking for more clarifications. - -The US legal counsel have so far provided the following advice: - -The legal risk faced by VPN operators subject to United States jurisdiction depends on various statutes and regulations related to privacy, anonymity, and electronic communications. The key areas to consider are: intermediary liability and exceptions, data protection, copyright infringement, export controls, criminal law, government requests for data and assistance, and third party liability. - -As outlined in Part A, the United States treats VPNs as telecommunications networks subject to intermediary liability protection from wrongful conduct that occurs on its network. However, such protections do have exceptions including criminal law and copyright claims that are worth considering. In the United States, I am not aware of an individual ever being prosecuted or convicted for running a node for a dVPN or a Privacy Enhancing Network. - -However, as discussed in Part B-C, VPN operators are subject to law enforcement requests for access or assistance in obtaining access to data relevant to an investigation into allegedly unlawful conduct that was facilitated by the network as an intermediary. As shown in Part C, governments may also request assistance from node operators for certain high-level and national security targets. - -Finally, as outlined in Parts D-G, VPN operators may also be subject to non-criminal liability including (Part D) failing to respond to notices under the DMCA, (Part E) privacy and data protection law, (Part F) third party lawsuits stemming from wrongful acts committed using the network, and (G) export control violations. - - diff --git a/documentation/old_docs/operators/src/licensing.md b/documentation/old_docs/operators/src/licensing.md deleted file mode 100644 index b569231b75..0000000000 --- a/documentation/old_docs/operators/src/licensing.md +++ /dev/null @@ -1,11 +0,0 @@ -# Licensing - -As a general approach, licensing is as follows this pattern: - -*

Nym Documentation by Nym Technologies is licensed under CC BY-NC-SA 4.0

- -* Nym applications and binaries are [GPL-3.0-only](https://www.gnu.org/licenses/) - -* Used libraries and different components are [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) or [MIT](https://mit-license.org/) - -For accurate information, please check individual files. diff --git a/documentation/old_docs/operators/src/nodes/bonding.md b/documentation/old_docs/operators/src/nodes/bonding.md deleted file mode 100644 index 3982dad973..0000000000 --- a/documentation/old_docs/operators/src/nodes/bonding.md +++ /dev/null @@ -1,73 +0,0 @@ -# Bonding Nym Node - -```admonish caution -If you unbond your Nym Node that means you are leaving the mixnet and you will lose all your delegations (permanently). You can join again with the same identity key, however, you will start with **no delegations**. -``` - -Nym Mixnet operators are rewarded for their work every epoch (60 minutes). To prevent centralisation, [Nym API](nym-api.md) is ran by distributed validators on Nyx blockchain. - -You are asked to `sign` a transaction and bpnd your node to Nyx blockchain so that the Mixnet smart contract is able to map your nym address to your node. This allows us to create a nonce for each account and defend against replay attacks. - -**Before you bond your `nym-node` make sure you went through all the previous steps** - -1. [Build](../binaries/building-nym.md) or [download](../binaries/pre-built-binaries.md) `nym-node` binary -2. [Configure VPS](vps-setup.md) correctly -3. [Prepare Nym wallet](wallet-preparation.md) -4. [Setup & Run](setup.md) the node -5. [Configure](configuration.md) the node (Optionally setup automation, WSS, reversed proxy) - -```admonish warning -Do not bond your node to the API if the previous steps weren't finished. Bad connectivity, closed ports, or other poor setup will result in your node getting blacklisted. -``` - -## Bond via the Desktop wallet (recommended) - -You can bond your `nym-node` via the Desktop wallet. - -1. Open your wallet, and head to the `Bond` page, then select the node type `Mixnode` and input your node details. Press `Next`. - - To find out your `nym-node` details, run `./nym-node bonding-information --id ` - - To get a correct host address, run `echo "$(curl -4 https://ifconfig.me)"` - -2. Open the box called `Show advanced options` and make sure all your ports are set correctly, like the values in this table: - -| Node type | Port name | Correct port value | -| :-- | :-- | :-- | -| Mixnode | Mix port | `1789` | -| Mixnode | Verloc port | `1790` | -| Mixnode | HTTP api port (picture below) | `8080` | -| Gateway (entry & exit) | Mix port | `1789` | -| Gateway (entry & exit) | Client WS API port | `9000` | - -- If you bonding `nym-node --mode mixnode` through *Bond mixnode* desktop wallet menu, change manually *HTTP api port* value from deprecated `8000` to `8080` - a generic `nym-node` HTTP port (for all modes). - -![](../images/wallet-screenshots/new_http_port.png) - -3. Enter the `Amount`, `Operating cost` and `Profit margin` and press `Next`. - -4. You will be asked to run a `sign` command with your `nym-node` - copy and paste the long signature as the value of `--contract-msg` and run it. - -``` -./nym-node sign --contract-msg -``` - -5. Copy the resulting signature string and paste it into the wallet nodal, press `Next` and confirm the transaction: - -```sh -# This is just an example, copy the one from your process ->>> The base58-encoded signature is: -2bbDJSmSo9r9qdamTNygY297nQTVRyQaxXURuomVcRd7EvG9oEC8uW8fvZZYnDeeC9iWyG9mAbX2K8rWEAxZBro1 -``` - -![Paste Signature](../images/wallet-screenshots/wallet-sign.png) - -*This image is just an example, copy-paste your own base58-encoded signature* - -6. Your node will now be bonded and ready to recieve traffic, latest at the beginning of the next epoch (at most 1 hour) - - -If everything worked, you'll see your node running on the either the [Sandbox testnet network explorer](https://sandbox-explorer.nymtech.net) or the [mainnet network explorer](https://explorer.nymtech.net), depending on which network you're running. - - -## Bond via the CLI (power users) - -If you want to bond your Mix Node via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#bond-a-mix-node) docs. diff --git a/documentation/old_docs/operators/src/nodes/maintenance.md b/documentation/old_docs/operators/src/nodes/maintenance.md deleted file mode 100644 index df109c7f83..0000000000 --- a/documentation/old_docs/operators/src/nodes/maintenance.md +++ /dev/null @@ -1,365 +0,0 @@ -# Maintenance - -## Useful commands - -> 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. - -For example `./target/debug/nym-network-requester --no-banner build-info --output json` will return: - -```sh -{"binary_name":"nym-network-requester","build_timestamp":"2023-07-24T15:38:37.00657Z","build_version":"1.1.23","commit_sha":"c70149400206dce24cf20babb1e64f22202672dd","commit_timestamp":"2023-07-24T14:45:45Z","commit_branch":"feature/simplify-cli-parsing","rustc_version":"1.71.0","rustc_channel":"stable","cargo_profile":"debug"} -``` - -## Configure your firewall - -Although your `` is now ready to receive traffic, your server may not be. The following commands will allow you to set up a firewall using `ufw`. - -```sh -# check if you have ufw installed -ufw version - -# if it is not installed, install with -sudo apt install ufw -y - -# enable ufw -sudo ufw enable - -# check the status of the firewall -sudo ufw status -``` - -Finally open your `` p2p port, as well as ports for ssh and ports for verloc and measurement pings: - -```sh -# for nym-node -sudo ufw allow 1789,1790,8000,9000,9001,22/tcp - -# in case of setting up WSS on Gateway add: -sudo ufw allow 9001/tcp - -# In case of reverse proxy for the Gateway swagger page add: -sudo ufw allow 8080,80/443 - -# for validator -sudo ufw allow 1317,26656,26660,22,80,443/tcp -``` - -Check the status of the firewall: -```sh -sudo ufw status -``` - -For more information about your node's port configuration, check the [port reference table](./maintenance.md#gateway-port-reference) below. - -## VPS Setup and Automation - -> Replace `` variable with type of node you run, preferably `nym-node` (depreciated `nym-mixnode`, `nym-gateway` or `nym-network-requester`). - -### Automating your node with nohup, tmux and systemd - -Although it’s not totally necessary, it's useful to have the Mix Node automatically start at system boot time. We recommend to run your remote operation via [`tmux`](maintenance.md#tmux) for easier management and a handy return to your previous session. For full automation, including a failed node auto-restart and `ulimit` setup, [`systemd`](maintenance.md#systemd) is a good choice. - -> Do any of these steps and run your automated node before you start bonding process! - -#### nohup - -`nohup` is a command with which your terminal is told to ignore the `HUP` or 'hangup' signal. This will stop the node process ending if you kill your session. - -```sh -nohup ./ run # use all the flags you use to run your node -``` - -#### tmux - -One way is to use `tmux` shell on top of your current VPS terminal. Tmux is a terminal multiplexer, it allows you to create several terminal windows and panes from a single terminal. Processes started in `tmux` keep running after closing the terminal as long as the given `tmux` window was not terminated. - -Use the following command to get `tmux`. - -| Platform | Install Command | -| :--- | :--- | -| Arch Linux|`pacman -S tmux` | -| Debian or Ubuntu|`apt install tmux` | -| Fedora|`dnf install tmux` | -| RHEL or CentOS|`yum install tmux` | -| macOS (using Homebrew | `brew install tmux` | -| macOS (using MacPorts) | `port install tmux` | -| openSUSE | `zypper install tmux` | - -In case it didn't work for your distribution, see how to build `tmux` from [version control](https://github.com/tmux/tmux#from-version-control). - -**Running tmux** - -Now you have installed tmux on your VPS, let's run a Mix Node on tmux, which allows you to detach your terminal and let your `` run on its own on the VPS. - -* Pause your `` -* Start tmux with the command -```sh -tmux -``` -* The tmux terminal should open in the same working directory, just the layout changed into tmux default layout. -* Start the `` again with a command: -```sh -./ run # use all the flags you use to run your node -``` -* Now, without closing the tmux window, you can close the whole terminal and the `` (and any other process running in tmux) will stay active. -* Next time just start your teminal, ssh into the VPS and run the following command to attach back to your previous session: -```sh -tmux attach-session -``` -* To see keybinding options of tmux press `ctrl`+`b` and after 1 second `?` - -#### systemd - -> Configuration of `systemd` service files for `nym-node` is under [Nym Node - Configuration](configuration.md#systemd) page. - -##### For Nymvisor -> Since you're running your node via a Nymvisor instance, as well as creating a Nymvisor `.service` file, you will also want to **stop any previous node automation process you already have running**. - -To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nymvisor.service` and follow the [next steps](#following-steps-for-nym-nodes-running-as-systemd-service). - -1. Open text editor -```sh -nano /etc/systemd/system/nymvisor.service -``` - -2. Paste this file - -``` -[Unit] -Description=Nymvisor -StartLimitInterval=350 -StartLimitBurst=10 - -[Service] -User= # replace this with whatever user you wish -LimitNOFILE=65536 -ExecStart=/home///nymvisor run --id -KillSignal=SIGINT -Restart=on-failure -RestartSec=30 - -[Install] -WantedBy=multi-user.target -``` - -3. Save the file - -```admonish note -Make sure your `ExecStart ` and `run` command are correct! - -Example: If you have built nym in the `$HOME` directory on your server, your username is `jetpanther`, and node `` is `puma`, then the `ExecStart` line (command) in the script located in `/etc/systemd/system/nym-mixnode.service` for Nym Mixnode might look like this: -`ExecStart=/home/jetpanther/nym/target/release/nym-node run --id puma`. - -Basically, you want the full `///nym-mixnode run --id `. If you are unsure about your `///`, then `cd` to your directory where you run your `` from and run `pwd` command which returns the full path for you. -``` - - -#### Following steps for Nym nodes running as `systemd` service - -Once your init file is save follow these steps: - -1. Reload systemctl to pickup the new unit file -```sh -systemctl daemon-reload -``` - -2. Enable the newly created service: - -```sh -systemctl enable nym-node.service -``` - -3. Start your `` as a `systemd` service: - -```sh -service nym-node start -``` - -This will cause your `` to start at system boot time. If you restart your machine, your `` will come back up automatically. - -**Useful systemd commands** - -- You can monitor system logs of your node by running: -```sh -journalctl -u -f -``` - -- Or check a status by running: -```sh -systemctl status .service -# for example systemctl status nym-node.service -``` - -- You can also do `service stop` or `service restart`. - -**Note:** if you make any changes to your `systemd` script after you've enabled it, you will need to run: - -```sh -systemctl daemon-reload -``` - -This lets your operating system know it's OK to reload the service configuration. Then restart your ``. - - -## Backup a node - -Anything can happen to the server on which your node is running. To back up your `nym-node` keys and configuration protects the operators against the negative impact of unexpected events. To restart your node on another server, two essential pieces are needed: - -1. Node keys to initialise the same node on a new VPS -2. Access to the bonding Nym account (wallet seeds) to edit the IP on smart contract - -Assuming that everyone access their wallets from local machine and does *not* store their seeds on VPS, point \#2 should be a given. To backup your `nym-node` keys and configuration in the easiest way possible, copy the entire config directory `.nym` from your VPS to your local desktop, using a special copy command `scp`: - -1. Create a directory where you want to store your backup -```sh -mkdir -pv -``` - -2. Copy configuration folder `.nym` from your VPS to your newly created backup directory: - -```sh -scp -r @:~/.nym/nym-nodes/ -``` - -3. The `scp` command should print logs, an operator can see directly whether it was successful or if it encountered any error. However, double check that all your needed configuration is in the backup directory. - -## Restoring a node - -In case your VPS shut down and you have a [backup](#backup-a-node) of your node keys and access to your bonding wallet, you can easily restore your node on another server without losing your delegation. - -1. On VPS: Do all [preliminary steps](preliminary-steps.md) needed to run a `nym-node`. - -2. On VPS: Create a `.nym/nym-nodes` configuration folder: -```sh -mkdir -pv ~/.nym/nym-nodes -``` - -3. From machine where your node is backed up (usually local desktop): Copy the folder with your node keys and configuration to the newly created folder on your VPS using `scp` command. Make sure to grab the entire `nym-node` configuration folder, which is called after your local `nym-node` ID, the `-r` flag will take care of all sub-directories and their content: -```sh -scp -r @:~/.nym/nym-nodes/ -``` - -4. The `scp` command should print logs, an operator can see directly whether it was successful or if it encountered any error. However, double check that all your needed configuration is in the target directory `.nym/nym-nodes` on your VPS. - - -5. Configure your node on the new VPS: - -* Edit `~/.nym/nym-nodes//config/config.toml` config with the new listening address IP - it's the one under the header `[host]`, called `public_ips = ['',]` and add your new location (field `location = `, formats like: 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided). You can see your IP by running a command `echo "$(curl -4 https://ifconfig.me)"`. -* Try to run the node and see if everything works. -* Setup the [systemd](#systemd) automation (don't forget to add the [terms and conditions flag](setup.md#terms--conditions)) to `ExecStart` command, reload the daemon and run the service. - -6. And finally change the node smart contract info via the wallet interface. Open Nym Wallet, go to *Bonding*, open *Gateway Settings* or *Mixnode Settings* and change *Host* value to the new `nym-node` IP address. Otherwise the keys will point to the old IP address in the smart contract, and the node will not be able to be connected, and it will fail up-time checks, returning zero performance. - -## Moving a node - -In case of a need to move a Nym Node from one machine to another and avoiding to lose the delegation, here are few steps how to do it. - -Assuming both machines are remote VPS. - -* Make sure your `~/.ssh/.pub` is in both of the servers `~/.ssh/authorized_keys` file -* Create a `nym-nodes` folder in the target VPS. SSH in from your terminal and run: - -```sh -# in case none of the nym configs was created previously -mkdir ~/.nym - -#in case no nym Nym Node was initialized previously -mkdir ~/.nym/nym-nodes -``` -* Move the node data (keys) and config file to the new machine by opening your **local terminal** (as that one's ssh key is authorized in both of the VPS) and running: -```sh -scp -r -3 @:~/.nym/nym-nodes @:~/.nym/nym-nodes/ -``` - -**On new/target VPS** - -* Edit `~/.nym/nym-nodes//config/config.toml` config with the new listening address IP - it's the one under the header `[host]`, called `public_ips = ['',]` and add your new location (field `location = `, formats like: 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided). You can see your IP by running a command `echo "$(curl -4 https://ifconfig.me)"`. -* Try to run the node and see if everything works. -* Setup the [systemd](#systemd) automation. If you want to use the exact same service config file, you can also copy it from one VPS to another following the same logic by opening your **local terminal** (as that one's ssh key is authorized in both of the VPS) and running: -```sh -scp -r -3 @:/etc/systemd/system/nym-node.service @:/etc/systemd/system/nym-node.service -``` - -Note: [Accepting T&Cs](setup.md#terms--conditions) is done via a flag `--accept-operator-terms-and-conditions` added explicitly to `nym-node run` command every time. If you use [systemd](configuration.md#systemd) automation, add the flag to your service file's `ExecStart` line. - -**In your desktop wallet** - -* Change the node smart contract info via the wallet interface. Open Nym Wallet, go to *Bonding*, open *Gateway Settings* or *Mixnode Settings* and change *Host* value to the new `nym-node` IP address. Otherwise the keys will point to the old IP address in the smart contract, and the node will not be able to be connected, and it will fail up-time checks, returning zero performance. - -Make sure to stop the old node. - -## Rename node local ID - -Local node ID (not the identity key) is a name chosen by operators which defines where the nodes configuration data will be stored, where the ID determines the path to `~/.nym/nym-nodes//`. This ID is never shared on the network. - -Since migrating to [`nym-node`](nym-node.md), specifying an with `--ID ` when starting a new node is no longer necessary. Nodes without a specified ID will be asigned the default ID `default-nym-node`. This streamlines node management, particularly for operators handling multiple nodes via ansible and other automation scripts, as all data is stored at `~/.nym/nym-nodes/default-nym-node`. - -If you already operate a `nym-node` and wish to change the local ID to `default-nym-node` or anything else, follow the steps below to do so. - -```admonish note -In the example we use `default-nym-node` as a target ``, if you prefer to use another name, edit the syntax in the commands accordingly. -``` - -1. Copy the configuration directory to the new one -```sh -cp -r ~/.nym/nym-nodes/ ~/.nym/nym-nodes/default-nym-node/ -``` - -2. Rename all `` occurences in `config.toml` to `default-nym-node` - -```sh -# check occurences of the -grep -r "" ~/.nym/nym-nodes/default-nym-node/* -``` -```admonish bug title="Caution!" -If your node `` is too generic (like `gateway` etc) and it occurs elsewhere than just a custom value, **do not use `sed` command but rewrite the values manually using a text editor!** -``` - -```sh -# rename it by using sed command -sed -i -e "s//default-nym-node/g" ~/.nym/nym-nodes/default-nym-node/config/config.toml - -# or manually by opening config.toml and rewriting each occurence of -nano ~/.nym/nym-nodes/default-nym-node/config/config.toml -``` - -3. Validate by rechecking the config file content -```sh -# either re-run -grep -r "" ~/.nym/nym-nodes/default-nym-node/* - -# or by reading the config file -less ~/.nym/nym-nodes/default-nym-node/config/config.toml -``` -- Pay extra attention to the `hostname` line. In case its value was somehow correlated with the `` string you may need to correct it back - -4. Reload your [systemd service daemon](#systemd) and restart the service, or if automation isn't your thing, simply reboot the node - -5. If you double-checked that everything works fine, you can consider removing your old config directory - -## Ports -All ``-specific port configuration can be found in `$HOME/.nym///config/config.toml`. If you do edit any port configs, remember to restart your client and node processes. - -### Nym Node Port Reference -| Default port | Use | -| ------------ | ------------------------- | -| `1789` | Listen for Mixnet traffic | -| `1790` | Listen for VerLoc traffic | -| `8080` | Metrics http API endpoint | -| `1789` | Listen for Mixnet traffic | -| `9000` | Listen for Client traffic | -| `9001` | WSS | -| `51822/udp` | WireGuard | - -### Validator Port Reference -All validator-specific port configuration can be found in `$HOME/.nymd/config/config.toml`. If you do edit any port configs, remember to restart your validator. - -| Default port | Use | -|--------------|--------------------------------------| -| 1317 | REST API server endpoint | -| 26656 | Listen for incoming peer connections | -| 26660 | Listen for Prometheus connections | diff --git a/documentation/old_docs/operators/src/nodes/manual-upgrade.md b/documentation/old_docs/operators/src/nodes/manual-upgrade.md deleted file mode 100644 index c1bab073b6..0000000000 --- a/documentation/old_docs/operators/src/nodes/manual-upgrade.md +++ /dev/null @@ -1,74 +0,0 @@ -# Manual Node Upgrade - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -**Upgrading your node is a straight forward two-step process:** - -#### 1. Updating the binary and `~/.nym///config/config.toml` on your VPS -#### 2. Updating the node information in the [mixnet smart contract](https://nymtech.net/docs/nyx/mixnet-contract.html). This is the information that is present on the [mixnet explorer](https://explorer.nymtech.net). - -## Step 1: Upgrading your binary - -Follow these steps to upgrade your node binary and update its config file: -1. Pause your node process. - - if you see the terminal window with your node, press `ctrl + c` - - if you run it as `systemd` service, run: `service stop` -2. Replace the existing `` binary with the newest binary (which you can either [compile yourself](../binaries/building-nym.md) or [download](../binaries/pre-built-binaries.md). -3. [Re-run with the same values](setup.md#initialise--run) as you used initially for your ``. **This will just update the config file, it will not overwrite existing keys**. - - if your node is *not automated*, just `run` your `` with `./ run --id `. - - if you *automated* your node with systemd (recommended) run: -```sh -systemctl daemon-reload # to pickup the new unit file - -service start && journalctl -f -u .service # to monitor log of you node -``` - -If you prefer to automate the process, try to setup your flow with [Nymvisor](nymvisor-upgrade.md). - -## Step 2: Updating your node information in the smart contract - -Follow these steps to update the information about your `` which is publicly available from the [`nym-api`](https://validator.nymtech.net/api/swagger/index.html) and information displayed on the [Mixnet explorer](https://explorer.nymtech.net). - -You can either do this graphically via the Desktop Wallet, or the CLI. - -### Updating node information via the Desktop Wallet (recommended) - -1. Navigate to the `Bonding` page and click the `Node Settings` link in the top right corner: - -![Bonding page](../images/wallet-screenshots/bonding.png) - -2. Update the fields in the `Node Settings` page (usually the field `Version` is the only one to change) and click `Submit changes to the blockchain`. - -![Node Settings Page](../images/wallet-screenshots/node_settings.png) - -### Updating node information via the CLI - -If you want to bond your `` via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#upgrade-a-mix-node) docs. - -```admonish info -If you run a Gateway, visit [Nym Harbour Master](https://harbourmaster.nymtech.net/) to get all the probe info about your node directly from API. -``` - -## Upgrading your validator - -Upgrading from `v0.31.1` -> `v0.32.0` process is fairly simple. Grab the `v0.32.0` release tarball from the [`nyxd` releases page](https://github.com/nymtech/nyxd/releases), and untar it. Inside are two files: - -- the new validator (`nyxd`) v0.32.0 -- the new wasmvm (it depends on your platform, but most common filename is `libwasmvm.x86_64.so`) - -Wait for the upgrade height to be reached and the chain to halt awaiting upgrade, then: - -* copy `libwasmvm.x86_64.so` to the default LD_LIBRARY_PATH on your system (on Ubuntu 20.04 this is `/lib/x86_64-linux-gnu/`) replacing your existing file with the same name. -* swap in your new `nyxd` binary and restart. - -You can also use something like [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/main/tools/cosmovisor) - grab the relevant information from the current upgrade proposal [here](https://nym.explorers.guru/proposal/9). - -Note: Cosmovisor will swap the `nyxd` binary, but you'll need to already have the `libwasmvm.x86_64.so` in place. - -### Common reasons for your validator being jailed - -The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs. - -Running the command `df -H` will return the size of the various partitions of your VPS. - -If the `/dev/sda` partition is almost full, try pruning some of the `.gz` syslog archives and restart your validator process. diff --git a/documentation/old_docs/operators/src/nodes/nym-api.md b/documentation/old_docs/operators/src/nodes/nym-api.md deleted file mode 100644 index bce06b8981..0000000000 --- a/documentation/old_docs/operators/src/nodes/nym-api.md +++ /dev/null @@ -1,287 +0,0 @@ -# Nym API Setup - -[//]: # (> The nym-api binary was built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. You can build just the API with `cargo build --release --bin nym-api`.) - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -## What is the Nym API? -The Nym API is a binary that will be operated by the Nyx validator set. This binary can be run in several different modes, and has two main bits of functionality: -* network monitoring (calculating the routing score of Mixnet nodes) -* generation and validation of [zk-nyms](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a), our implementation of the Coconut Selective Disclosure Credential Scheme. - -This is important for both the proper decentralisation of the network uptime calculation and, more pressingly, enabling the NymVPN to utilise privacy preserving payments. - -The process of enabling these different aspects of the system will take time. At the moment, Nym API operators will only have to run the binary in a minimal 'caching' mode in order to get used to maintaining an additional process running alongside a full node. - -```admonish warning -It is highly recommended to run `nym-api` alongside a full node and NOT a validator node, since you will be exposing HTTP port(s) to the Internet. We also observed degradation in p2p and block signing operations when `nym-api` was run alongside a signing validator. -``` - -### Rewards -Operators of Nym API will be rewarded for performing the extra work of taking part in credential generation. These rewards will be calculated **separately** from rewards for block production. - -Rewards for credential signing will be calculated hourly, with API operators receiving a proportional amount of the reward pool (333NYM per hour / 237,600 NYM per month), proportional to the percentage of credentials they have signed. - - -### Hardware Requirements - -The specification mentioned below is for running a full node alongside the nym-api. It is recommended to run `nym-api` and a full Nyx node on the same machine for optimum performance. - -Bear in mind that credential signing is primarily CPU-bound, so choose the fastest CPU available to you. - -#### Minimum Requirements - -| Hardware | Minimum Specification | -|----------|--------------------------------------------| -| CPU | 8-cores, 2.8GHz base clock speed or higher | -| RAM | 16GB DDR4+ | -| Disk | 500 GiB+ NVMe SSD | - -#### Recommended Requirements - -| Hardware | Minimum Specification | -|----------|---------------------------------------------| -| CPU | 16-cores, 2.8GHz base clock speed or higher | -| RAM | 32GB DDR4+ | -| Disk | 1 TiB+ NVMe SSD | - -### Full node configuration - -To install a full node from scratch, refer to the [validator setup guide](./validator-setup.md) and follow the steps outlined there. -Additionally, to ensure `nym-api` works as expected, ensure the configuration is as below: - -#### Ensure transaction index is turned on in your `config.toml`: - -``` -[tx_index] - -# Ensure that this is not set to "null". You're free to use any indexer - -indexer = "kv" -``` - -#### Ensure pruning settings are manually configured - -`nym-api` needs to check validity of user-submitted transactions (in the past) while issuing credentials and as part of double-spend check. Hence, aggressively pruning data will lead to errors with your `nym-api` - -Make sure your pruning settings are configured as below in `app.toml`: - -``` -pruning = "custom" - -# This number is likely to be updated once zk-nym signing goes live -pruning-keep-recent = "750000" -pruning-interval = "100" -``` - -The example value of `100` for `pruning-interval` can be customised as per your requirement. - - -### Credential Generation -Validators that take part in the DKG ceremony will become part of the 'quorum' generating and verifying zk-nym credentials. These will initially be used for private proof of payment for NymVPN (see our blogposts [here](https://blog.nymtech.net/nymvpn-an-invitation-for-privacy-experts-and-enthusiasts-63644139d09d) and [here](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a) for more on this), and in the future will be expanded into more general usecases such as [offline ecash](https://arxiv.org/abs/2303.08221). - -The DKG ceremony will be used to create a subset of existing validators who run `nym-api` alongside a Nyx full-node. As outlined above, they will be the ones taking part in the generation and verification of zk-nym credentials. The size of the 'minimum viable quorum' is 10 - we are aiming for a larger number than this for the initial quorum in order to have some redundancy in the case of a validator dropping or going offline. - -We will be releasing more detailed step-by-step documentation for involved validators nearer to the ceremony itself, but at a high level it will involve: -* the deployment and initialisation of [`group`](https://github.com/nymtech/nym/tree/develop/contracts/multisig/cw4-group) and [`multisig`](https://github.com/nymtech/nym/tree/develop/contracts/multisig) contracts by Nym. Validators that are members of the `group` contract are the only ones that will be able to take part in the ceremony. -* the deployment and initialisation of an instance of the [DKG contract](https://github.com/nymtech/nym/tree/develop/contracts/coconut-dkg) by Nym. -* Validators will update their `nym-api` configs with the address of the deployed contracts. They will also stop running their API instance in caching only mode, instead switching over run with the `--enabled-credentials-mode`. -* From the perspective of operators, this is all they have to do. Under the hood, each `nym-api` instance will then take part in several rounds of key submission, verification, and derivation. This will continue until quorum is acheived. - -**We will be communicating individually with members of the existing validator set who have expressed interest in joining the quorum concerning the timing and specifics of the ceremony**. - -## Current version -``` - -``` - -## Setup and Usage -### Viewing command help -You can check that your binary is properly compiled with: - -``` -./nym-api --help -``` - -Which should return a list of all available commands. - -~~~admonish example collapsible=true title="Console output" -``` - -``` -~~~ - -You can also check the various arguments required for individual commands with: - -``` -./nym-api --help -``` - -### Initialising your Nym API Instance in caching mode -Initialise your API instance with: - -``` -./nym-api init -``` - -You can optionally pass a local identifier for this instance with the `--id` flag. Otherwise the ID of your instance defaults to `default`. - -### Enabling credential signing on your Nym API instance - -To engage in the Distributed Key Generation (DKG) ceremony, it's essential to transition your `nym-api` instance from its default caching mode to the active credential signing mode. This section guides you through the process of enabling credential signing - -#### Generate a new wallet - -Begin by generating a new wallet address specifically for your instance to use in credential signing mode. Utilize the `nyxd` command-line tool with the following command: - -``` -nyxd keys add signer -``` - -~~~admonish warning title="Backup your keys!" -It's critical to securely back up the mnemonic phrase generated during this process. This mnemonic is your key to recovering the wallet in the future, so store it in a secure, offline location. -~~~ - -#### Fund the address - -Next, deposit NYM tokens into the newly created wallet address to ensure it can cover transaction fees incurred during the credential signing process. `nym-api` will not operate if the wallet's balance falls below 10 NYM tokens, displaying an error message upon startup. - -We recommand beginning with an initial deposit of 100 NYM tokens and monitoring the balance regularly, topping it up as necessary to maintain operational readiness. - -#### Update API configuration - -With your new wallet ready and funded, proceed to update your `nym-api` configuration to enable credential signing: - -Update your `config.toml` located in `/.nym/nym-api/foo/config/config.toml` as below: - -Enable the coconut signer: - -``` -[coconut_signer] -# Specifies whether coconut signing protocol is enabled in this process. -enabled = true # This was previously false -``` - -Set your announce address if it is empty. This is the URL you previously configured for your `nym-api` instance - -``` -# This is the address you previously configured for the nym-api -# Not to be confused with the Cosmos REST API URL -announce_address = 'https://nym-api.your.tld/' -``` - -Finally, input the mnemonic phrase generated during the wallet creation step into the mnemonic field - -``` -mnemonic = '' -``` - -After completing these steps, your `nym-api` instance is configured to participate in credential signing and the DKG ceremony. - - -### Running your Nym API Instance -The API binary currently defaults to running in caching mode. You can run your API with: - -``` -./nym-api run --id -``` - -By default the API will be trying to query your full node running locally on `localhost:26657`. If your node is hosted elsewhere, you can specify the RPC location by using the `--nyxd-validator ` flag on `run`: - -``` -./nym-api run --id --nyxd-validator https://rpc-nym.yourcorp.tld:443 -``` - -> You can also change the value of `local_validator` in the config file found by default in `$HOME/.nym/nym-api//config/config.toml`. - -This process is quite noisy, but informative: - -~~~admonish example collapsible=true title="Console output" -``` -Starting nym api... - 2023-12-12T14:29:55.800Z INFO rocket::launch > 🔧 Configured for release. - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > address: 127.0.0.1 - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > port: 8000 - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > workers: 4 - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > max blocking threads: 512 - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > ident: Rocket - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > IP header: X-Real-IP - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > limits: bytes = 8KiB, data-form = 2MiB, file = 1MiB, form = 32KiB, json = 1MiB, msgpack = 1MiB, string = 8KiB - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > temp dir: /tmp - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > http/2: true - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > keep-alive: 5s - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > tls: disabled - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > shutdown: ctrlc = true, force = true, signals = [SIGTERM], grace = 2s, mercy = 3s - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > log level: critical - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > cli colors: true - 2023-12-12T14:29:55.800Z INFO rocket::launch > 📬 Routes: - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_registered_names) GET /v1/names - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnodes) GET /v1/mixnodes - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_gateways) GET /v1/gateways - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_services) GET /v1/services - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /v1/openapi.json - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_full_circulating_supply) GET /v1/circulating-supply - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_current_epoch) GET /v1/epoch/current - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_active_set) GET /v1/mixnodes/active - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnodes_detailed) GET /v1/mixnodes/detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_rewarded_set) GET /v1/mixnodes/rewarded - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_gateways_described) GET /v1/gateways/described - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_interval_reward_params) GET /v1/epoch/reward_params - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_blacklisted_mixnodes) GET /v1/mixnodes/blacklisted - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_blacklisted_gateways) GET /v1/gateways/blacklisted - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_total_supply) GET /v1/circulating-supply/total-supply-value - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_circulating_supply) GET /v1/circulating-supply/circulating-supply-value - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_active_set_detailed) GET /v1/mixnodes/active/detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_rewarded_set_detailed) GET /v1/mixnodes/rewarded/detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /cors/ - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/ - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/index.css - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/index.html - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui.css - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/oauth2-redirect.html - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui-bundle.js - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui-config.json - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-initializer.js - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui-standalone-preset.js - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnodes_detailed) GET /v1/status/mixnodes/detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_inclusion_probabilities) GET /v1/status/mixnodes/inclusion_probability - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_status) GET /v1/status/mixnode//status - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_active_set_detailed) GET /v1/status/mixnodes/active/detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_rewarded_set_detailed) GET /v1/status/mixnodes/rewarded/detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_stake_saturation) GET /v1/status/mixnode//stake-saturation - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_inclusion_probability) GET /v1/status/mixnode//inclusion-probability - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (network_details) GET /v1/network/details - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (nym_contracts) GET /v1/network/nym-contracts - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (nym_contracts_detailed) GET /v1/network/nym-contracts-detailed - 2023-12-12T14:29:55.800Z INFO rocket::launch > 📡 Fairings: - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > Validator Cache Stage (ignite) - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > Circulating Supply Cache Stage (ignite) - 2023-12-12T14:29:55.800Z INFO rocket::launch::_ > Shield (liftoff, response, singleton) - 2023-12-12T14:29:55.801Z INFO rocket::launch::_ > CORS (ignite, request, response) - 2023-12-12T14:29:55.801Z INFO rocket::launch::_ > Node Status Cache (ignite) - 2023-12-12T14:29:55.801Z INFO rocket::shield::shield > 🛡️ Shield: - 2023-12-12T14:29:55.801Z INFO rocket::shield::shield::_ > X-Content-Type-Options: nosniff - 2023-12-12T14:29:55.801Z INFO rocket::shield::shield::_ > X-Frame-Options: SAMEORIGIN - 2023-12-12T14:29:55.801Z INFO rocket::shield::shield::_ > Permissions-Policy: interest-cohort=() - 2023-12-12T14:29:55.801Z WARN rocket::launch > 🚀 Rocket has launched from http://127.0.0.1:8000 - 2023-12-12T14:29:56.375Z INFO nym_api::nym_contract_cache::cache::refresher > Updating validator cache. There are 888 mixnodes and 105 gateways - 2023-12-12T14:29:56.375Z INFO nym_api::node_status_api::cache::refresher > Updating node status cache - 2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > Updating circulating supply cache - 2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > the mixmining reserve is now 220198535489690unym - 2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > the number of tokens still vesting is now 145054386857730unym - 2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > the circulating supply is now 634747077652580unym - 2023-12-12T14:30:00.803Z INFO nym_api::support::caching::refresher > node-self-described-data-refresher: refreshing cache state - 2023-12-12T14:31:56.290Z INFO nym_api::nym_contract_cache::cache::refresher > Updating validator cache. There are 888 mixnodes and 105 gateways - 2023-12-12T14:31:56.291Z INFO nym_api::node_status_api::cache::refresher > Updating node status cache -``` -~~~ - -## Automation -You will most likely want to automate your validator restarting if your server reboots. Checkout the [maintenance page](./maintenance.md) for an example `service` file. - -You can also use `nymvisor` to automatically update the `nym-api` node. The steps to install Nymvisor can be found [here](nymvisor-upgrade.md). - -## Exposing web endpoint using HTTPS -It is recommended to expose the webserver over HTTPS by using a webserver like Nginx. An example configuration for configuring Nginx is listed [on the maintenance page](maintenance.md#nym-api-configuration). If you're using a custom solution, ensure to allow requests from anywhere by setting a permissive CORS policy. - -For example, it is configured in Nginx using: `add_header 'Access-Control-Allow-Origin' '*';` diff --git a/documentation/old_docs/operators/src/nodes/nym-node.md b/documentation/old_docs/operators/src/nodes/nym-node.md deleted file mode 100644 index a95b67657a..0000000000 --- a/documentation/old_docs/operators/src/nodes/nym-node.md +++ /dev/null @@ -1,106 +0,0 @@ -# Nym Node - -```admonish note -If you are a `nym-mixnode` or `nym-gateway` operator and you are not familiar with the binary changes called *Project Smoosh*, you can read the archived [Smoosh FAQ](../archive/faq/smoosh-faq.md) page. -``` - -NYM NODE is a tool for running a node within the Nym network. Nym Nodes containing functionality such as `mixnode`, `entry-gateway` and `exit-gateway` are fundamental components of Nym Mixnet architecture. Nym Nodes are ran by decentralised node operators. - -To setup any type of Nym Node, start with either building [Nym's platform](../binaries/building-nym.md) from source or download [pre-compiled binaries](../binaries/pre-built-binaries.md) on the [configured server (VPS)](vps-setup.md) where you want to run the node. Your Nym Node will need to be bonded before it can be run. We recommend most users use the [Nym desktop wallet](wallet-preparation.md) for this. - -**Follow [preliminary steps](preliminary-steps.md) page before you configure and run a `nym-node`!** - -## Steps for Nym Node Operators - -Once [VPS and Nym wallet are configured](preliminary-steps.md), binaries ready, the operators of `nym-node` need to: - -1. **[Setup](setup.md) the node** - -2. **[Configure](configuration.md) the node and optionally automation, Wireguard, WSS, reversed proxy ...** - -3. **[Run](setup.md#initialise--run) the node or [the service](configuration.md#following-steps-for-nym-nodes-running-as-systemd-service)** - -4. **[Bond](bonding.md) the node to the Nym API, using Nym wallet** - -Make sure to follow the steps thoroughly, in case you find any point difficult don't hesitate to ask in our [Operators channel](https://matrix.to/#/#operators:nymtech.chat). - - diff --git a/documentation/old_docs/operators/src/nodes/nymvisor-upgrade.md b/documentation/old_docs/operators/src/nodes/nymvisor-upgrade.md deleted file mode 100644 index 49bb267815..0000000000 --- a/documentation/old_docs/operators/src/nodes/nymvisor-upgrade.md +++ /dev/null @@ -1,297 +0,0 @@ -# Automatic Node Upgrade: Nymvisor Setup and Usage - -> The Nymvisor binary was built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. You can build just Nymvisor with `cargo build --release --bin nymvisor`. - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -## What is Nymvisor? -Nymvisor is a process manager for Nym binaries that monitors the Nym release information for any newly released binaries. If it detects any changes, Nymvisor can automatically download the binary, stop the current binary, switch from the old binary to the new one, and finally restart the underlying process with the new binary. - -In essence, it tries to mirror the behaviour of [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/main/tools/cosmovisor), a tool used by Cosmos blockchain operators for managing/automating chain upgrades. Nymvisor, however, introduces some Nym-specific changes since, for example, upgrade information is obtained from our GitHub [releases page](https://github.com/nymtech/nym/releases) instead of (in the case of Cosmos blockchains) governance proposals. - -You can use Nymvisor to automate the upgrades of the following binaries: -* `nym-api` -* `nym-node` -* `nym-client` -* `nym-socks5-client` - -```admonish warning -Nymvisor is an early and experimental software. Users should use it at their own risk. -``` - -## Current version -``` - -``` - -## Preliminary steps -You need to have at least one Nym Node / client / Nym API instance already set up on the **same VPS** that you wish to run Nymvisor on. - -> Using Nymvisor presumes your VPS is running an operating system that is compatible with the pre-compiled binaries availiable on the [Github releases page](https://github.com/nymtech/nym/releases). If you're not, then until we're packaging for a greater variety of operating systems, you're stuck with [manually upgrading your node](manual-upgrade.md). - -## Setup and Usage -### Viewing command help -You can check that your binaries are properly compiled with: - -``` -./nymvisor --help -``` - -Which should return a list of all available commands. - -~~~admonish example collapsible=true title="Console output" -``` - -``` -~~~ - -You can also check the various arguments required for individual commands with: - -``` -./nymvisor --help -``` - -### Initialising your Nymvisor Instance -> This example will use the Nym Node binary as an example - however replacing `nym-node` with any other supported binary will work the same. - -Initialise your Nymvisor instance with the following command. You must initialise Nymvisor with the binary you wish to add upgrades for: - -``` -./nymvisor init --daemon-home ~/.nym// -``` - -Where the value of `--daemon-home` might be `~/.nym/nym-nodes/default-nym-node` and `` might be `/home/my_user/nym/target/release/nym-node`, or wherever your node binary is located. - -~~~admonish example collapsible=true title="Console output" -``` - -``` -~~~ - -By default this will create config files at `~/.nym/nymvisors/instances/-default/config/config.toml` as shown in the console output above. For config options look at the different `--flags` available, or the [environment variables](nymvisor-upgrade.md#environment-variables) section below. - -### Running your Nymvisor Instance -Nymvisor acts as a wrapper around the specified node process - it has to do this in order to be able to pause and restart this process. As such, you need to run your node _via_ Nymvisor! - -The interface to the `nymvisor run ` command is quite simple. Any argument passed after the `run` command will be passed directly to the underlying daemon, for example: `nymvisor run run --id default-nym-node` will run the `$DAEMON_NAME run --id default-nym-node` command (where `DAEMON_NAME` is the name of the binary itself (e.g. `nym-api`, `nym-node`, etc.)). - -`run` Nymvisor and start your node via the following command. Make sure to stop any existing node before running this command. - -``` -./nymvisor run run --id -``` - -~~~admonish example collapsible=true title="Console output" -``` - -``` -~~~ - -Nymvisor will now manage your node process (for an in-depth overview of this command check the [in-depth command information](./nymvisor-upgrade.md#commands-in-depth) below). It will periodically poll [this endpoint](https://nymtech.net/.wellknown/nym-node/upgrade-info.json) (replace `nym-node` with whatever node you may actually be running via Nymvisor) and check for a new `version` of the binary it is watching. If this exists, it will then, using the information there: -* pause your node process -* grab the new binary (`version`) -* verify it against the provided `checksum` -* perform a data backup of the existing node -* replace the old binary with the new one -* restart the process - -And that's it! Check the [maintenance page](./maintenance.md#for-nymvisor) for information on Nymvisor process maintenance and automation, and you can find more in-depth information about the various aspects of Nymvisor such as what happens [under the hood](#commands-in-depth) for various commands. - -### Creating an Adhoc Upgrade -`nymvisor add-upgrade --upgrade-name= --arg1=value1 --arg2=value2 ...` can be used to amend an existing `upgrade-plan.json` by creating new entries or to add an executable to an existing scheduled upgrade so that it would not have to be downloaded. - ->Generally users **will not have to use this command**. Situations in which this command might be used are: -> - an adhoc upgrade if e.g. a patched version of a binary was required -> - if a user doesn't trust the verification process of Nymvisor's pipeline and wishes to build/verify the binary themselves before using Nymvisor to perform the upgrade -> - if a user isn't using a currently supported operating system and needs to manually specify a binary they have built themselves - -Similarly to `init`, `add-upgrade` requires a positional argument specifying a valid path to the upgrade binary. Furthermore, the `--upgrade-name` keyword argument must be set in order to declare the upgrade name. The remaining arguments are optional. They include: -- `--force` - if specified, will allow Nymvisor to overwrite existing upgrade binary / `upgrade-info.json` files if they already exist -- `--add-binary` - indicate that this command should only add binary to an existing scheduled upgrade -- `--now` - if specified will force the upgrade to be performed immediately (technically not 'immediately' within few seconds). It can't be specified alongside either `--upgrade-time` or `--upgrade-delay` arguments -- `--publish-date` - if a new `upgrade-info.json` file is going to be created, this argument will specify the `publish_date` metadata field. Otherwise, the current time will be used. The [RFC3339 datetime](https://www.rfc-editor.org/rfc/rfc3339) format is expected -- `--upgrade-time` - specifies the time at which the provided upgrade will be performed (RFC3339 formatted). If left unset, the upgrade will be performed in 15 minutes. It can't be specified alongside either `--now` or `--upgrade-delay` arguments. -- `--upgrade-delay` - specifies delay until the provided upgrade is going to get performed. If let unset, the upgrade will be performed in 15 minutes. It can't be specified alongside either `--upgrade_time` or `--now` arguments. - -## Config -The output format of `nymvisor config` can be further configured with `--output` argument. By default a human-readable text representation is used: -``` -id: nym-node-default -daemon name: nym-node -daemon home: /home/nym/.nym/nym-nodes/default-nym-node -upstream base upgrade url: https://nymtech.net/.wellknown/ -disable nymvisor logs: false -CUSTOM upgrade data directory "" -upstream absolute upgrade url: "" -allow binaries download: true -enforce download checksum: true -restart after upgrade: true -restart on failure: false -on failure restart delay: 10s -max startup failures: 10 -startup period duration: 2m -shutdown grace period: 10s -CUSTOM backup data directory "" -UNSAFE skip backups false -``` - -Adding `--output=json` would format the same data into JSON which can be more easily parsed programmatically to e.g. pipe the output into `jq` for further processing. -``` -nymvisor config --output=json -``` -outputs: -``` -{"nymvisor":{"id":"nym-node-default","upstream_base_upgrade_url":"https://nymtech.net/.wellknown/","upstream_polling_rate":"1h","disable_logs":false,"upgrade_data_directory":null},"daemon":{"name":"nym-node","home":"/home/nym/.nym/nym-nodes/default-nym-nodee","absolute_upstream_upgrade_url":null,"allow_binaries_download":true,"enforce_download_checksum":true,"restart_after_upgrade":true,"restart_on_failure":false,"failure_restart_delay":"10s","max_startup_failures":10,"startup_period_duration":"2m","shutdown_grace_period":"10s","backup_data_directory":null,"unsafe_skip_backup":false}} -``` - -## CLI Overview -Command options are: -- `help`, `--help`, or `-h` - Output Nymvisor help information and display the available commands. -- `config` - Display the current Nymvisor configuration, that means displaying the current configuration file that might have been overridden with environment variables value that Nymvisor is using. -- `init` - Generate a `config.toml` file for this instance of Nymvisor that will use the provided arguments alongside any environmental variables that are set. -- `add-upgrade` - Add an upgrade manually to Nymvisor. This command allows you to easily add the binary corresponding to an upgrade or amend the existing `upgrade-plan.json` whilst creating new `upgrade-info.json` file. -- `build-info` - Output the build information. -- `daemon-build-info` - Output the build information of the current binary used by the associated daemon. -- `run` - Run the configured binary using the rest of the provided arguments. -- `-V` or `--version` - Output the Nymvisor version - -Similarly to other Nym binaries, Nymvisor supports a global `--config-env-file` or `-c` flag that allows specifying path to a `.env` file defining any relevant environmental variables that are going to be applied to any of the Nymvisor commands as described in the [Environment section](./nymvisor-upgrade.md#environment-variables). - -For commands that depend on Nymvisor config file (i.e. all but `init`), the configuration file is loaded as follows: -- if available, reading `$NYMVISOR_CONFIG_PATH` -- otherwise, if `$NYMVISOR_ID` is set, a default path will be used, i.e. `$HOME/.nym/nymvisors/instances/$NYMVISOR_ID/config/config.toml` -- finally, if there's only a single `nymvisor` instance instantiated (as defined by directories in `$HOME/.nym/nymvisors/instances`), that one will be loaded -- if all of the above fails, an error is returned - -Nymvisor attempts to load the file from the derived path. If it fails, it attempts to use one of the older schemas to and upgrade it as it goes, the loaded configuration is then overridden with any value that might have been set in the environment. - -## Environment Variables - -> Please note environmental variables take precedence over any arguments passed, i.e. if one were to specify `--daemon_home="/foo"` and set `DAEMON_HOME="bar"`, the value of `"bar"` would end up being used. - -For any of its commands as described in [CLI Overview section](./nymvisor-upgrade.md#cli-overview), Nymvisor reads its configuration from the following environment variables: - -- `NYMVISOR_ID` is the human-readable identifier of the particular Nymvisor instance. -- `NYMVISOR_CONFIG_PATH` is used to manually override path to the configuration file of the Nymvisor instance. -- `NYMVISOR_UPSTREAM_BASE_UPGRADE_URL` (defaults to https://nymtech.net/.wellknown/) is the base url of the upstream source for obtaining upgrade information for the daemon. It will be used fo constructing the full url, i.e. `$NYMVISOR_UPSTREAM_BASE_UPGRADE_URL/$DAEMON_NAME/upgrade-info.json`. -- `NYMVISOR_UPSTREAM_POLLING_RATE` (defaults to 1h) is polling rate the upstream url for upgrade information. -- `NYMVISOR_DISABLE_LOGS` (defaults to `false`). If set to `true`, this will disable Nymvisor logs (but not the underlying process) completely. -- `NYMVISOR_UPGRADE_DATA_DIRECTORY` is the custom directory for upgrade data - binaries and upgrade plans. If not set, the global Nymvisors' data directory will be used instead. -- `DAEMON_NAME` is the name of the binary itself (e.g. `nym-api`, `nym-node`, etc.). -- `DAEMON_HOME` is the location where the `nymvisor/` directory is kept that contains the auxiliary files associated with the underlying daemon instance, such as any backups or current version information, e.g. `$HOME/.nym/nym-api/my-nym-api`, `$HOME/.nym/nym-nodes/default-nym-node`, etc. -- `DAEMON_ABSOLUTE_UPSTREAM_UPGRADE_URL` is the absolute (i.e. the full url) upstream source for upgrade plans for this daemon. The url has to point to an endpoint containing a valid `UpgradeInfo` json file. If set it takes precedence over `NYMVISOR_UPSTREAM_BASE_UPGRADE_URL`. -- `DAEMON_ALLOW_BINARIES_DOWNLOAD` (defaults to `true`), if set to `true`, it will enable auto-downloading of new binaries (as declared by urls in corresponding `upgrade-info.json` files). For security reasons one might wish to disable it and instead manually provide binaries by either placing them in the appropriate directory or by invoking `add-upgrade` command. -- `DAEMON_ENFORCE_DOWNLOAD_CHECKSUM` (defaults to `true`), if set to `true` Nymvisor will require that a checksum is provided in the upgrade plan for the upgrade binary to be downloaded. If disabled, Nymvisor will not require a checksum to be provided, but still check the checksum if one is provided. -- `DAEMON_RESTART_AFTER_UPGRADE` (defaults to `true`), if set to `true` Nymvisor will restart the subprocess with the same command-line arguments and flags (but with the new binary) after a successful upgrade. Otherwise (`false`), Nymvisor stops running after an upgrade and requires the system administrator to manually restart it. **Note restart is only after the upgrade and does not auto-restart the subprocess after an error occurs.** That is controlled via `DAEMON_RESTART_ON_FAILURE`. -- `DAEMON_RESTART_ON_FAILURE` (defaults to `true`), if set to `true`, Nymvisor will restart the subprocess with the same command-line arguments and flags if it has terminated with a non-zero exit code. -- `DAEMON_FAILURE_RESTART_DELAY` (defaults to 10s), if `DAEMON_RESTART_ON_FAILURE` is set to `true`, this will specify a delay between the process shutdown (with a non-zero exit code) and it being restarted. -- `DAEMON_MAX_STARTUP_FAILURES` (defaults to 10) if `DAEMON_RESTART_ON_FAILURE` is set to `true`, this defines the maximum number of startup failures the subprocess can experience in a quick succession before no further restarts will be attempted and Nymvisor will terminate. -- `DAEMON_STARTUP_PERIOD_DURATION` (defaults to 120s) if `DAEMON_RESTART_ON_FAILURE` is set to `true`, this defines the length of time during which the subprocess is still considered to be in the startup phase when its failures are going to be counted towards the limit defined in `DAEMON_MAX_STARTUP_FAILURES`. -- `DAEMON_SHUTDOWN_GRACE_PERIOD` (defaults to 10s), specifies the amount of time Nymvisor is willing to wait for the subprocess to undergo graceful shutdown after receiving an interrupt before it sends a kill signal. -- `DAEMON_BACKUP_DATA_DIRECTORY` specifies custom backup directory for daemon data. If not set, `DAEMON_HOME/nymvisor/backups` is used instead. -- `DAEMON_UNSAFE_SKIP_BACKUP` (defaults to `false`), if set to `true`, all upgrades will be performed directly without performing any backups. Otherwise (`false`), Nymvisor will back up the contents of `DAEMON_HOME` before trying the upgrade. - -## Dir structure -The folder structure of Nymvisor is heavily inspired by Cosmovisor, but with some notable changes to accommodate our binaries having possibly multiple instances due to their different `--id` flags. The data is spread through three main directories: -- in a global `nymvisors` data directory shared by all Nymvisor instances (default: `$HOME/.nym/nymvisors/data`) that contains daemon upgrade plans, binaries and upgrades histories. It includes a subdirectory for each version of the application (i.e. `genesis` or `upgrades`). Within each subdirectory is the application binary (i.e. `bin/$DAEMON_NAME`), the associated `upgrade-info.json` and any additional auxiliary files associated with each binary. `current` is a symbolic link to the currently active directory (i.e. `genesis` or `upgrades/`) -- in a home directory of a particular `nymvisor` instance (e.g. `$HOME/.nym/nymvisors/instances//`). It includes subdirectories for its configuration file (i.e. `config/config.toml`), that preconfigures the instance, and for any additional persistent data that might be added in the future (i.e. `data`) -- in a `nymvisor` data directory inside the home directory of the managed daemon instance (default: `$HOME/.nym/$DAEMON_NAME/nymvisor`) that contains subdirectories for data backups (i.e. `backups/`) and current version information (`current-version-info.json`) - -A sample full structure looks as follows: - -``` -~/.nym -├── nymvisors -│ ├── instances -│ │ ├── -│ │ │ ├── config -│ │ │ │ └── config.toml -│ │ │ └── data -│ │ │ └── ... -│ │ └── -│ │ └── ... -│ └── data -│ ├── nym-api -│ │ ├── current -> genesis or upgrades/ -│ │ ├── genesis -│ │ │ ├── bin -│ │ │ │ └── nym-api -│ │ │ └── upgrade-info.json -│ │ ├── upgrades -│ │ │ └── -│ │ │ ├── bin -│ │ │ │ └── nym-api -│ │ │ └── upgrade-info.json -│ │ ├── upgrade-history.json -│ │ └── upgrade-plan.json -│ ├── nym-node -│ │ └── ... -│ └── $DAEMON_NAME -│ └── ... -└── nym-api -├── -│ ├── config -│ │ └── -│ ├── data -│ │ └── -│ └── nymvisor -│ ├── backups -│ │ └── -│ │ └── .... -│ └── current-version-info.json -└── -└── ... -``` - -## Commands In-Depth -This section outlines what happens under the hood with the following commands: - -### Init -`init` does the following: -- executes the `$DAEMON_NAME build-info` command on the daemon executable to check its validity and obtain its name -- creates the required directory structure: - - `$DAEMON_HOME/nymvisor` folder if it doesn't yet exist - - `$DAEMON_BACKUP_DATA_DIRECTORY` folder if it doesn't yet exist - - `$NYMVISOR_UPGRADE_DATA_DIRECTORY` folder if it doesn't yet exist - - `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis/bin` folder if it doesn't yet exist - - `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/upgrades` folder if it doesn't yet exist -- copies the provided executable to `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis/bin/$DAEMON_NAME` -- generates initial `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis/upgrade-info.json` file based on the provided binary -- generates initial `$DAEMON_HOME/nymvisor/current-version-info.json` file based on the provided binary -- creates a `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/current` symlink pointing to `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis` -- saves the Nymvisor instance's config file to `$NYMVISOR_CONFIG_PATH` and creates the full directory structure for the file -- outputs (to `stdout`) the full configuration used - -> `nymvisor init` is specifically for initializing Nymvisor, and should **not** be confused with a daemon's `init` command - such as `nym-node init` (e.g. `cosmovisor run init`). - -### Run -`nymvisor run` is a lightweight wrapper around the underlying daemon. It uses only a single thread and spawns three simple tasks: -- an upstream poller that checks the upstream source (as defined by `DAEMON_ABSOLUTE_UPSTREAM_UPGRADE_URL` or derived from `NYMVISOR_UPSTREAM_BASE_UPGRADE_URL`) for any recently released upgrades. It then creates appropriate `upgrade-info.json` file and updates the `upgrade-plan.json` -- a file watcher for the `upgrade-plan.json` file that can notify the main run loop of upgrades that were added by either the above upstream poller task or via the `add-upgrade` command, -- the daemon run loop that: - - runs the `DAEMON_NAME` with the provided arguments until: - - it completes the execution (with any exit code), - - Nymvisor receives a `SIGINT`, `SIGTERM` or `SIGQUIT`, - - a new upgrade is scheduled to be performed (by other task watching for changes in `upgrade-plan.json` and waiting until the `upgrade_time`, - - if `DAEMON_UNSAFE_SKIP_BACKUP` is not set to `true`, it backups the content of `DAEMON_HOME` directory, - - performs the binary upgrade by: - - creating a temporary, exclusive and non-blocking, `upgrade.lock` file for the `DAEMON_NAME`. `flock` with `LOCK_EX | LOCK_NB` is used for that purpose. The file is created in case users didn't read any warnings and attempted to run multiple instances of `nymvisor` managing the same `DAEMON_NAME`, - - downloading the upgrade binary for the runners architecture using one of the urls defined in `upgrade-info.json`. Note, however, that this is only done if the binary associated with the `` does not already exist and `DAEMON_ALLOW_DOWNLOAD_BINARIES` is set to `true`, - - if the binary has been downloaded and `DAEMON_ENFORCE_DOWNLOAD_CHECKSUM` is set to true, the file checksum is verified using the specified algorithm, - - verifying the upgrade binary - checking if it's a valid executable with expected `build-info`. Note that this will also set `a+x` bits on the file if those permissions have not already been set, - - removing the queued upgrade from `upgrade-plan.json`, - - inserting new upgrade into the `upgrade-history.json`, - - updating the `current-version-info.json`, - - updating the `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/current` symlink to the upgrade directory, - - removing the `upgrade.lock` file. - - the above loop is repeated if either: - - the daemon has crashed and `DAEMON_MAX_STARTUP_FAILURES` has not been reached yet, - - the daemon has successfully been upgraded, `DAEMON_RESTART_AFTER_UPGRADE` has been set to `true` and the manual flag on the performed upgrade has been set to `false`. - -### Add-Upgrade -`nymvisor add-upgrade` does the following: -- executes the `$DAEMON_NAME build-info` command on the daemon executable to check its validity and obtain its name -- attempts to load existing `upgrade-info.json` for the provided ``. If it already exists and neither `--force` nor `--add-binary` was specified, Nymvisor will terminate -- checks if `upgrades//$DAEMON_NAME` binary already exists. If it does and `--force` flag was not specified, Nymvisor will terminate the provided upgrade binary is copied to its appropriate location -- if applicable, new `upgrade-info.json` is created and written to its appropriate location -- `upgrade-plan.json` is updated with the new upgrade details. If there's an active Nymvisor instance running, this change will be detected to initialise upgrade process diff --git a/documentation/old_docs/operators/src/nodes/nyx-configuration.md b/documentation/old_docs/operators/src/nodes/nyx-configuration.md deleted file mode 100644 index cbad32a3b5..0000000000 --- a/documentation/old_docs/operators/src/nodes/nyx-configuration.md +++ /dev/null @@ -1,268 +0,0 @@ -# Nyx Validator & Nym API Configuration - -## Automation - -### Validator `systemd` Automation - -To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nymd.service` and follow the steps bellow.. - -1. Open text editor -```sh -nano /etc/systemd/system/nymd.service -``` - -2. Paste this file -```ini -[Unit] -Description=Nyxd -StartLimitInterval=350 -StartLimitBurst=10 - -[Service] -User= # change to your user -Type=simple -Environment="LD_LIBRARY_PATH=/home//" # change to correct path -ExecStart=/home///nymd start # change to correct path -Restart=on-failure -RestartSec=30 -LimitNOFILE=infinity - -[Install] -WantedBy=multi-user.target -``` - -Proceed to start it with: - -```sh -systemctl daemon-reload # to pickup the new unit file -systemctl enable nymd # to enable the service -systemctl start nymd # to actually start the service -journalctl -f -u nymd # to monitor system logs showing the service start -``` - -**Note:** if you make any changes to your `systemd` script after you've enabled it, you will need to run: - -```sh -systemctl daemon-reload -``` - -This lets your operating system know it's ok to reload the service configuration. Then restart your ``. - -### Nym API `systemd` Automation - - -To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nym-api.service` and follow the steps bellow.. - -1. Open text editor -```sh -nano /etc/systemd/system/nym-api.service -``` - -2. Paste this file -```ini -[Unit] -Description=NymAPI -StartLimitInterval=350 -StartLimitBurst=10 - -[Service] -User= # change to your user -Type=simple -ExecStart=/home///nym-api start # change to correct path -Restart=on-failure -RestartSec=30 -LimitNOFILE=infinity - -[Install] -WantedBy=multi-user.target -``` - -Proceed to start it with: - -```sh -systemctl daemon-reload # to pickup the new unit file -systemctl enable nym-api # to enable the service -systemctl start nym-api # to actually start the service -journalctl -f -u nym-api # to monitor system logs showing the service start -``` - -**Note:** if you make any changes to your `systemd` script after you've enabled it, you will need to run: - -```sh -systemctl daemon-reload -``` - -This lets your operating system know it's ok to reload the service configuration. Then restart your ``. - -## Nym API (previously 'Validator API') endpoints - -Numerous API endpoints are documented on the Nym API (previously 'Validator API')'s [Swagger Documentation](https://validator.nymtech.net/api/swagger/index.html). There you can also try out various requests from your browser, and download the response from the API. Swagger will also show you what commands it is running, so that you can run these from an app or from your CLI if you prefer. - -```sh -sudo ufw allow 'Nginx Full' -``` - -Check nginx is running via systemctl: - -```sh -systemctl status nginx -``` - -Which should return: - -```sh -● nginx.service - A high performance web server and a reverse proxy server - Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) - Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago - Docs: man:nginx(8) - Main PID: 2369 (nginx) - Tasks: 2 (limit: 1153) - CGroup: /system.slice/nginx.service - ├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; - └─2380 nginx: worker process -``` - -## Full Node Configuration - -Proxying various full node services through port 80 can then be done by creating a file with the following at `/etc/nginx/sites-enabled/nyxd-webrequests.conf`: - -Setting up a reverse proxy using a webserver such as Nginx allows you to easily configure SSL certificates for the endpoints. When running on mainnet, it is recommended to encrypt all web traffic to your node. - -```sh -### To expose RPC server -server { - listen 80; - listen [::]:80; - server_name ""; - - location / { - proxy_pass http://127.0.0.1:26657; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header Host $host; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - - location /websocket { - proxy_pass http://127.0.0.1:26657; - proxy_http_version 1.1; - proxy_set_header Upgrade $http_upgrade; - proxy_set_header Connection "Upgrade"; - proxy_set_header Host $host; - } -} - -### To expose Cosmos API server -server { - server_name ""; - location / { - proxy_pass http://127.0.0.1:1317; - proxy_set_header X-Forwarded-For $remote_addr; - proxy_set_header Host $http_host; - proxy_set_header Upgrade websocket; - proxy_set_header Connection Upgrade; - } -} - -### To expose GRPC endpoint -server { - server_name ""; - location / { - grpc_pass 127.0.0.1:9090; - } -} -``` - -## nym-api Configuration - -```sh -### To expose nym-api webserver -server { - listen 80; - listen [::]:80; - server_name ""; - add_header 'Access-Control-Allow-Origin' '*'; - - location / { - proxy_pass http://127.0.0.1:8000; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header Host $host; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } -} -``` - -Followed by: - -```sh -sudo apt install certbot nginx python3 -certbot --nginx -m --agree-tos -``` - -```admonish caution title="" -If using a VPS running Ubuntu 20: replace `certbot nginx python3` with `python3-certbot-nginx` -``` - -These commands will get you an https encrypted nginx proxy in front of the various endpoints. - -## Configuring Prometheus metrics (optional) - -Configure Prometheus with the following commands (adapted from NodesGuru's [Agoric setup guide](https://nodes.guru/agoric/setup-guide/en)): - -```sh -echo 'export OTEL_EXPORTER_PROMETHEUS_PORT=9464' >> $HOME/.bashrc -source ~/.bashrc -sed -i '/\[telemetry\]/{:a;n;/enabled/s/false/true/;Ta}' $HOME/.nymd/config/app.toml -sed -i "s/prometheus-retention-time = 0/prometheus-retention-time = 60/g" $HOME/.nymd/config/app.toml -sudo ufw allow 9464 -echo 'Metrics URL: http://'$(curl -s ifconfig.me)':26660/metrics' -``` - -Your validator's metrics will be available to you at the returned 'Metrics URL'. - -~~~admonish example collapsible=true title="Console output" -``` -# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles. -# TYPE go_gc_duration_seconds summary -go_gc_duration_seconds{quantile="0"} 6.7969e-05 -go_gc_duration_seconds{quantile="0.25"} 7.864e-05 -go_gc_duration_seconds{quantile="0.5"} 8.4591e-05 -go_gc_duration_seconds{quantile="0.75"} 0.000115919 -go_gc_duration_seconds{quantile="1"} 0.001137591 -go_gc_duration_seconds_sum 0.356555301 -go_gc_duration_seconds_count 2448 -# HELP go_goroutines Number of goroutines that currently exist. -# TYPE go_goroutines gauge -go_goroutines 668 -# HELP go_info Information about the Go environment. -# TYPE go_info gauge -go_info{version="go1.15.7"} 1 -# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use. -# TYPE go_memstats_alloc_bytes gauge -go_memstats_alloc_bytes 1.62622216e+08 -# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed. -# TYPE go_memstats_alloc_bytes_total counter -go_memstats_alloc_bytes_total 2.09341707264e+11 -# HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table. -# TYPE go_memstats_buck_hash_sys_bytes gauge -go_memstats_buck_hash_sys_bytes 5.612319e+06 -# HELP go_memstats_frees_total Total number of frees. -# TYPE go_memstats_frees_total counter -go_memstats_frees_total 2.828263344e+09 -# HELP go_memstats_gc_cpu_fraction The fraction of this program's available CPU time used by the GC since the program started. -# TYPE go_memstats_gc_cpu_fraction gauge -go_memstats_gc_cpu_fraction 0.03357798610671518 -# HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata. -# TYPE go_memstats_gc_sys_bytes gauge -go_memstats_gc_sys_bytes 1.3884192e+07 -``` -~~~ - -## Validator port reference - -All validator-specific port configuration can be found in `$HOME/.nymd/config/config.toml`. If you do edit any port configs, remember to restart your validator. - -| Default port | Use | -|--------------|--------------------------------------| -| 1317 | REST API server endpoint | -| 26656 | Listen for incoming peer connections | -| 26660 | Listen for Prometheus connections | diff --git a/documentation/old_docs/operators/src/nodes/preliminary-steps.md b/documentation/old_docs/operators/src/nodes/preliminary-steps.md deleted file mode 100644 index 02b278c90e..0000000000 --- a/documentation/old_docs/operators/src/nodes/preliminary-steps.md +++ /dev/null @@ -1,10 +0,0 @@ -# Preliminary Steps - -> The `nym-node` binary was built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first. - -There are a couple of steps that need completing before starting to set up your `nym-node`: - -1. **[Prepare your wallet](wallet-preparation.md):** [desktop](https://nymtech.net/docs/wallet/desktop-wallet.html) or [CLI](https://nymtech.net/docs/wallet/cli-wallet.html). -2. **[Requisition and setup a VPS](vps-setup.md)** (Virtual Private Server) - -Make sure to follow these steps carefully as it prevents a lot of troubleshooting later on. diff --git a/documentation/old_docs/operators/src/nodes/proxy-configuration.md b/documentation/old_docs/operators/src/nodes/proxy-configuration.md deleted file mode 100644 index ff4864e801..0000000000 --- a/documentation/old_docs/operators/src/nodes/proxy-configuration.md +++ /dev/null @@ -1,841 +0,0 @@ -# Reversed Proxy & Web Secure Socket - -It's useful to put your Nym Node behind a reversed proxy and have it accessible via `https` domain, where you can host a [landing page](../legal/landing-pages.md). The guide is right [below](#reversed-proxy). - -More advanced and secure solution is to have your node behind Web Secure Socket (WSS). Follow this [this guide](#web-secure-socket-setup) for installation. - -```admonish info -For both of these configurations you will need to register a DNS domain and configure a record to your VPS. -``` - -## Variables Explanation - -This guide contains several variables. Substitute them with your own value, without `<>` brackets. Here is a list of variables we used below. - -| Variable | Description | Syntax example | -| :--- | :--- | :--- | -| `` | Your registered DNS domain, asigned to the VPS with `nym-node` | exit-gateway1.squad.nsl | -| `` | Port listening to WSS, default is `9001` | 9001 | -| `` | Any text you want to show on the landing page | Welcome to Nym Node, operator contact is example@email.me | -| `` | A sub-directory located at `/var/www/` containing html configuration files | `/var/www/exit-gateway1.squad.nsl` | -| `` | A local only `nym-node` identifier, specified by flag `--id`, default is `default-nym-node` | alice_super_node | -| `` | Specify a full path to the given file, directory or binary behind this variable | `/root/src/nym/target/release/` | - -```admonish warning title="" -The commands in this setup need to be run with root permission. Either add a prefix `sudo` or execute them from a root shell. -``` - -## Reversed Proxy Setup - -```admonish info -This guide was created by a Nym node operator, [Avril 14th](https://avril14th.org) as a part of [Nym Operators Community Counsel](../legal/community-counsel.md), edited by Nym. -``` - -The following snippet needs be modified as described below according to the public identity that you may want to show on this public notice, i.e. your graphics and your email. -It would allow you to serve it as a landing page resembling the one proposed by [Tor](https://gitlab.torproject.org/tpo/core/tor/-/raw/HEAD/contrib/operator-tools/tor-exit-notice.html) but with all the changes needed to adhere to the Nym's operators case. - - - -### HTML File Customization - -File for html configuration are by convention located at `/var/www/` directory and it's subdirectories. We refer to this directory as ``. - -1. Start by creating this directory: -```sh -mkdir -p /var/www/ -``` - -2. Use your own html code or copy the template below to a new file called `index.html` located in `/var/www/` directory. - -~~~admonish example collapsible=true title="An example template for `/var/www//index.html` page" -```html - - - - -This is a NYM Exit Gateway - - - - - - -
-

This is a NYM Exit Gateway

-

- -

- -

-You are most likely accessing this website because you've had some issue with -the traffic coming from this IP. This router is part of the NYM project, which is -dedicated to create outstanding -privacy software that is legally compliant without sacrificing integrity or -having any backdoors. -This router IP should be generating no other traffic, unless it has been -compromised.

- -

-The Nym mixnet is operated by a decentralised community of node operators -and stakers. The Nym mixnet is trustless, meaning that no parts of the system -nor its operators have access to information that might compromise the privacy -of users. Nym software enacts a strict principle of data minimisation and has -no back doors. The Nym mixnet works by encrypting packets in several layers -and relaying those through a multi-layered network called a mixnet, eventually -letting the traffic exit the Nym mixnet through an exit gateway like this one. -This design makes it very hard for a service to know which user is connecting to it, -since it can only see the IP-address of the Nym exit gateway:

- -

- -Illustration showing how a user might connect to a service through the Nym network. The user first sends their data through three daisy-chained encrypted Nym nodes that exist on three different continents. Then the last Nym node in the chain connects to the target service over the normal internet. - - - - - - - - - - - - - - - - - - - - - -The user -This server -Your service -Nym network link -Unencrypted link - - - - - - -

- -

-Read more about how Nym works.

- -

-Nym relies on a growing ecosystem of users, developers and researcher partners -aligned with the mission to make sure Nym software is running, remains usable -and solves real problems. While Nym is not designed for malicious computer -users, it is true that they can use the network for malicious ends. This -is largely because criminals and hackers have significantly better access to -privacy and anonymity than do the regular users whom they prey upon. Criminals -can and do build, sell, and trade far larger and more powerful networks than -Nym on a daily basis. Thus, in the mind of this operator, the social need for -easily accessible censorship-resistant private, anonymous communication trumps -the risk of unskilled bad actors, who are almost always more easily uncovered -by traditional police work than by extensive monitoring and surveillance anyway.

- -

-In terms of applicable law, the best way to understand Nym is to consider it a -network of routers operating as common carriers, much like the Internet -backbone. However, unlike the Internet backbone routers, Nym mixnodes do not -contain identifiable routing information about the source of a packet and do -mix the user internet traffic with that of other users, making communications -private and protecting not just the user content but the metadata -(user's IP address, who the user talks to, when, where, from what device and -more) and no single Nym node can determine both the origin and destination -of a given transmission.

- -

-As such, there is little the operator of this Exit Gateway can do to help you -track the connection further. This Exit Gateway maintains no logs of any of the -Nym mixnet traffic, so there is little that can be done to trace either legitimate or -illegitimate traffic (or to filter one from the other). Attempts to -seize this router will accomplish nothing.

- - - - - - -

To decentralise and enable privacy for a broad range of services, this -Exit Gateway adopts an Exit Policy -in accordance with the Tor Null ‘deny’ list -and the Tor reduced policy, -which are two established safeguards. -

- -

-That being said, if you still have a complaint about the router, you may email the - maintainer. If complaints are related - to a particular service that is being abused, the maintainer will submit that to the - NYM Operators Community in order to add it to the Exit Policy cited above. -If approved, that would prevent this router from allowing that traffic to exit through it. -That can be done only on an IP+destination port basis, however. Common P2P ports are already blocked.

- -

-You also have the option of blocking this IP address and others on the Nym network if you so desire. - The Nym project provides a - web service to fetch a list of all IP addresses of Nym Gateway Exit nodes that allow exiting to a -specified IP:port combination. Please be considerate when using these options.

- -
- - -``` -~~~ - -3. Before you save and close the file, make sure to edit the text, especially the information in these points: - -- Add your favicon logo on the line: -``` - -``` - -- Add your header logo on the line: -``` - -``` - -- By either setting the URl to the image (if you're hosting it publicly, i.e. on your web server) -``` -href="" - -# and - -src="" -``` - -- **or** by adding the image inline as base64 encoded image -``` -href="href="data:image/x-icon;base64,AAABAAMA...."" - -# and - -src="href="data:image/x-icon;base64,AAABAAMA...."" -``` - -- Add the email address you're willing to use for being contacted. -``` -maintainer -``` - -- If you're running the node within the US check the sections marked as `FIXME`, add your DNS name and un-comment those. - -4. Save and exit - -Now your html page is configured. - -### `nym-node` Configuration - -When done with the customization, you'll need to make sure your `nym-node` uploads the file and reference to it. This is done by opening your node configuration file located at `~/.nym/nym-nodes//config/config.toml` and changing the value of the line `landing_page_assets_path` on the `[http]` section: -``` -landing_page_assets_path = '' -``` - -### Reverse Proxy Configuration - -You may set up a [reverse proxy](https://www.nginx.com/resources/glossary/reverse-proxy-server/) in order to serve this landing page with proper SSL and DNS management, i.e. to resolve it to https://. - -The following assumes that you're owning a domain and that you've already set the Let's Encrypt certificates on your hosting, and you've copied those on your Gateway, i.e. copy the two Let's Encript pem files on your Gateway's home folder. -Else you may obtain a Let's Encrypt certificate using a [`--certonly` procedure](https://eff-certbot.readthedocs.io/en/latest/using.html#getting-certificates-and-choosing-plugins). - -**Configure Nginx** - -1. Install `nginx`: -```sh -sudo apt install nginx -``` - -2. Setup firewall with `ufw`. `ufw` has three profile pre-configured for `nginx`, we will need the first one for `nym-node`: - -- `Nginx Full`: This profile opens both port 80 (normal, unencrypted web traffic) and port 443 (TLS/SSL encrypted traffic) -- `Nginx HTTP`: This profile opens only port 80 (normal, unencrypted web traffic) -- `Nginx HTTPS`: This profile opens only port 443 (TLS/SSL encrypted traffic) - -```sh -ufw allow 'Nginx Full' - -# you can verify by -ufw status - -# possibly reload ufw by -ufw reload -``` - -3. Disable the default Nginx landing page -``` -systemctl status nginx -unlink /etc/nginx/sites-enabled/default -systemctl restart nginx -``` - -4. Add your endpoint configuration to Nginx by creating file: - - -```sh -nano /etc/nginx/sites-available/ -``` -- and changing `` occurrences below with your domain name: - -``` -server { - listen 443 ssl http2; - listen [::]:443 ssl http2; - - server_name nym-exit.; - - ssl_certificate /etc/letsencrypt/live//fullchain.pem; - ssl_certificate_key /etc/letsencrypt/live//privkey.pem; - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - location / { - proxy_pass http://127.0.0.1:8080; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header Host $host; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } -} - -server { - listen 80; - listen [::]:80; - - if ($host = ) { - return 301 https://$host$request_uri; - } - - server_name www.; - - return 301 https://$request_uri; -} -``` - - -5. Activate the configuration by creating a simlink to `/etc/nginx/sites-enabled`: -```sh -ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled -``` - -6. Test your configuration syntax: -```sh -nginx -t -``` - -7. Restart `nginx`: -```sh -systemctl daemon-reload && systemctl restart nginx -``` - -8. Get an `SSL` certificate using certbot: - -```sh -apt install certbot python3-certbot-nginx -certbot renew --dry-run -certbot --nginx -d -``` - -9. Restart your `nym-node` or if you're running your `nym-node` as a [`systemd` service](configuration.md#systemd), restart your service: -```sh -systemctl daemon-reload -service nym-node restart -``` - -10. Check for the page being served reading the service logs -```sh -journalctl -u nym-gateway.service | grep 8080 - -# where you should see -... Started NymNodeHTTPServer on 0.0.0.0:8080 -``` - -Now your `nginx` should be configured, up and running. Test it by inserting your `` as a URL in a browser. - - -## Web Secure Socket Setup - -For better security of transfered data, we recommend node operators to run their nodes through Secure Socket instead of be out in open. You can read more about *Secure Socket Layer* (SSL) in [here](https://www.geeksforgeeks.org/secure-socket-layer-ssl/). - -Before you start, don't forget to register a DNS and configure a record for your VPS with `nym-node`. - - -If you haven't configure reversed proxy before, start with [*Preliminary steps* chapter](#preliminary-steps) below and only then move to WSS setup. If you have reversed proxy already running and your `nym-node` can be reached via https, you can skip *Preliminary steps* and begin to setup WSS directly. Remember that there may be some unique variables and customization depending on the way your reversed proxy is done which you may have to adjust when installing WSS in order to make it work. - -```admonish tip -To see description of used variables (noted in `<>` brackets), scroll to the top of this page, chapter [*Variables Explanation*](#variables-explanation). -``` - -We documented two options for node operators to setup WSS for `nym-node`: - -1. [Using a script](#using-a-script) -2. [Step by step](#step-by-step) - - -### Preliminary Steps - -Whether you choose to setup WSS manually or using the script, the preliminary steps are mandatory to begin with before you continue with the installation. - -#### Firewall configuration - -Make sure to open all [needed ports](vps-setup.md#configure-your-firewall), adding your ``: - -```sh -ufw allow /tcp - -# for example -# ufw allow 9001/tcp -``` - -#### Landing page configuration - -1. Create server block directory for your https site: -```sh -sudo mkdir -p /var/www/ -``` - -2. Assign ownership using `$USER` environmental variable: -```sh -sudo chown -R $USER:$USER /var/www/ -``` - -3. Create a landing page in `/var/www/`. Either configure your own page (basic [syntax example](https://www.freecodecamp.org/news/introduction-to-html-basics/) or use our [template](#html-file-customization). Alternatively you can just make a simple welcome text using this command: -```sh -echo "

" | sudo tee /var/www//index.html -``` - -4. When done with the customization, you'll need to make sure your `nym-node` uploads the file and reference to it. This is done by opening your node configuration file located at `~/.nym/nym-nodes//config/config.toml` and changing the value of the line `landing_page_assets_path` on the `[http]` section: -```sh -landing_page_assets_path = '' - -# for example -# landing_page_assets_path = '/var/www/exit-gateway1.squad.nsl' -``` - -Now you are ready to set up WSS, ether using a [script](#using-a-script) or [step-by-step](#step-by-step) tutorial. - -### Using a Script - -Using a script is a more convenient option but it takes away some customization possibilities. If you like to have your setup fully in your hands, use [*Step by step guide*](#step-by-step-guide). Before you move on, make sure you went through [*Preliminary steps*](#preliminary-steps). - -1. Create a script by copying the block below and save it on your VPS as `wss_nginx_setup.sh`. - -~~~admonish example collapsible=true title="Script `wss_nginx_setup.sh`" -```bash -#!/bin/bash - -if [ "$#" -ne 2 ]; then - echo "usage: sudo ./wss_nginx_setup.sh " - exit 1 -fi - -host_name=$1 -port_value=$2 - -# preliminary checks -config_file_path="${HOME}/.nym/nym-nodes/*/config/config.toml" - -# check if the configuration file exists -if [ ! -f $config_file_path ]; then - echo "configuration file not found at $config_file_path" - exit 1 -fi - -# extract hostname and wss port -hostname=$(grep "hostname" $config_file_path | awk -F" = " '{print $2}' | tr -d "'") -wss_port=$(grep "announce_wss_port" $config_file_path | awk -F" = " '{print $2}' | tr -d ' ') - -# check if hostname is empty -if [ -z "$hostname" ]; then - echo "hostname is empty, updating it to ${host_name}" - sed -i "s|hostname = ''|hostname = '${host_name}'|" $config_file_path -else - echo "current hostname: $hostname" -fi - -# check if wss port is set to 0 and update it -if [ "$wss_port" -eq 0 ]; then - echo "wss port is 0, updating it to ${port_value}" - sed -i "s/announce_wss_port *= *0/announce_wss_port = ${port_value}/" $config_file_path -else - echo "current wss port: $wss_port" -fi - -# install nginx -apt update -apt install -y nginx - -# install certbot and the nginx plugin -apt install -y certbot python3-certbot-nginx - -# enable nginx service -systemctl enable nginx.service - -# create a consolidated nginx configuration file -nginx_config_file="/etc/nginx/sites-available/${host_name}" -cat < $nginx_config_file -# Reversed proxy configuration for landing page -server { - listen 443 ssl http2; - listen [::]:443 ssl http2; - - server_name ${host_name}; - - ssl_certificate /etc/letsencrypt/live/${host_name}/fullchain.pem; - ssl_certificate_key /etc/letsencrypt/live/${host_name}/privkey.pem; - include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot - ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot - - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - location / { - proxy_pass http://127.0.0.1:8080; - proxy_set_header X-Real-IP \$remote_addr; - proxy_set_header Host \$host; - proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for; - } -} - -# http configuration -server { - listen 80; - listen [::]:80; - - server_name ${host_name} www.${host_name}; - - return 301 https://${host_name}\$request_uri; -} - -# WSS configuration -server { - listen ${port_value} ssl http2; - listen [::]:${port_value} ssl http2; - - server_name ${host_name}; - - ssl_certificate /etc/letsencrypt/live/${host_name}/fullchain.pem; - ssl_certificate_key /etc/letsencrypt/live/${host_name}/privkey.pem; - include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot - ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot - - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - location / { - - add_header 'Access-Control-Allow-Origin' '*'; - add_header 'Access-Control-Allow-Credentials' 'true'; - add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, HEAD'; - add_header 'Access-Control-Allow-Headers' '*'; - - proxy_http_version 1.1; - proxy_set_header Upgrade \$http_upgrade; - proxy_set_header Connection "Upgrade"; - proxy_set_header X-Forwarded-For \$remote_addr; - proxy_pass http://localhost:9000; - proxy_intercept_errors on; # Enable intercepting errors from the proxy - } - -} -EOF - -# create a symbolic link in sites-enabled -ln -s /etc/nginx/sites-available/${host_name} /etc/nginx/sites-enabled/ - -# test nginx configuration -if ! nginx -t; then - echo "nginx configuration test failed" - exit 1 -fi - -# reload nginx service -systemctl reload nginx.service - -# obtain ssl certificates using certbot -if ! certbot --nginx -d ${host_name} --non-interactive --agree-tos -m your-email@example.com; then - echo "certbot failed to obtain certificates" - exit 1 -fi - -# test nginx configuration again -if ! nginx -t; then - echo "nginx configuration test failed after obtaining ssl certificates" - exit 1 -fi - -# reload nginx service to apply the new configuration -systemctl reload nginx.service - -echo "script completed successfully!" -echo "have a nice day!" -exit 0 -``` -~~~ - -2. Make the script executable: -```sh -chmod u+x wss_nginx_setup.sh -``` - -3. Run the script as root (with `sudo` or from the root shell): -```sh -./wss_nginx_setup.sh -# hostname is your domain -# wss default port is 9001 -``` - - -4. Restart your `nym-node` or if you're running your `nym-node` as a [`systemd` service](configuration.md#systemd), restart your service: -```sh -systemctl daemon-reload -service nym-node restart -``` - -Your `nym-node` should be configured to run over WSS now. Test it using the steps in the chapter [below](#test-wss-setup) - - -### Step by Step Guide - -Step by step guide is more advanced than using a [script](#using-a-script), but it allows for more customisation. Before you move on, make sure you finished [*Preliminary steps*](#preliminary-steps*). - - -#### Nginx Configuration - - -1. Install `nginx`: -```sh -apt install nginx -``` - -2. Setup firewall with `ufw`. `ufw` has three profile pre-configured for `nginx`, we will need the first one for `nym-node`: - -- `Nginx Full`: This profile opens both port 80 (normal, unencrypted web traffic) and port 443 (TLS/SSL encrypted traffic) -- `Nginx HTTP`: This profile opens only port 80 (normal, unencrypted web traffic) -- `Nginx HTTPS`: This profile opens only port 443 (TLS/SSL encrypted traffic) - -```sh -ufw allow 'Nginx Full' - -# you can verify by -ufw status -``` - -#### WSS & Landing page configuration - -We made the landing page customization directory in [*Preliminary steps*](#preliminary-steps), next steps will configure that with Nginx. - -3. Configure your site to work with `nginx`. Open a new text file `/etc/nginx/sites-available/` and paste the block below. Don't forget to insert your correct values. -~~~admonish example collapsible=true title="Site configuration `/etc/nginx/sites-available/`" -```bash -##################################################### -# EXCHANGE ALL & VARIABLES ! # -#################################################### - -# Reversed proxy configuration for landing page -server { - listen 443 ssl http2; - listen [::]:443 ssl http2; - - server_name ; - - ssl_certificate /etc/letsencrypt/live//fullchain.pem; - ssl_certificate_key /etc/letsencrypt/live//privkey.pem; - include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot - ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - location / { - proxy_pass http://127.0.0.1:8080; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header Host $host; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } -} - - -# http configuration -server { - listen 80; - listen [::]:80; - - if ($host = ) { - return 301 https://$host$request_uri; - } - - server_name www.; - - return 301 https://$request_uri; -} - - -# WSS configuration -server { - listen ssl http2; - listen [::]: ssl http2; - - server_name ; - - ssl_certificate /etc/letsencrypt/live//fullchain.pem; - ssl_certificate_key /etc/letsencrypt/live//privkey.pem; - include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot - ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - location / { - - add_header 'Access-Control-Allow-Origin' '*'; - add_header 'Access-Control-Allow-Credentials' 'true'; - add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, HEAD'; - add_header 'Access-Control-Allow-Headers' '*'; - - proxy_http_version 1.1; - proxy_set_header Upgrade $http_upgrade; - proxy_set_header Connection "Upgrade"; - proxy_set_header X-Forwarded-For $remote_addr; - - proxy_pass http://localhost:9000; - proxy_intercept_errors on; # Enable intercepting errors from the proxy - } - -} -``` -~~~ - -4. Activate the configuration by creating a simlink to `/etc/nginx/sites-enabled`: -```sh -ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled -``` - -5. Test your configuration syntax: -```sh -nginx -t -``` - -6. Restart `nginx`: -```sh -systemctl daemon-reload && systemctl restart nginx -``` - -#### SSL Setup using certbot - -7. Get an `SSL` certificate using certbot: - -```sh -apt install certbot python3-certbot-nginx -certbot renew --dry-run -certbot --nginx -d -``` - -8. Restart your `nym-node` or if you're running your `nym-node` as a [`systemd` service](configuration.md#systemd), restart your service: -```sh -systemctl daemon-reload -service nym-node restart -``` - -Your `nym-node` should be configured to run over WSS now. Test it using the steps in the chapter [below](#test-wss-setup). - -### Test WSS Setup - -You can do a few quick checks to test that your installation worked out and your `nym-node` is running correctly using WSS: - -- Check out connection with `wscat` from another (local) machine: -```sh -# install -sudo apt install node-ws - -# run -wscat -c ws://: -``` - -- Browse your `` as URL and see your landing page. - -- Check Swagger API of your node using the hostname: `https:///api/v1/swagger/#/` diff --git a/documentation/old_docs/operators/src/nodes/setup.md b/documentation/old_docs/operators/src/nodes/setup.md deleted file mode 100644 index 542dc7d883..0000000000 --- a/documentation/old_docs/operators/src/nodes/setup.md +++ /dev/null @@ -1,277 +0,0 @@ -# Nym Node Setup & Run - -This documentation page provides a guide on how to set up and run a [NYM NODE](nym-node.md), along with explanations of available flags, commands, and examples. - -## Current version - -``` - -``` - -```admonish info -**Migrating an existing node to a new `nym-node` is simple. The steps are documented [below](#migrate).** -``` - -```admonish note -If you are a `nym-mixnode` or `nym-gateway` operator and you are not familiar with the binary changes called *Project Smoosh*, you can read the archived [Smoosh FAQ](../archive/faq/smoosh-faq.md) page. -``` - -## Summary - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -To run a new node, you can simply execute the `nym-node` command without any flags. By default, the node will set necessary configurations. If you later decide to change a setting, you can use the `-w` flag. - -The most crucial aspect of running the node is specifying the `--mode`, which can be one of three: `mixnode`, `entry-gateway`, and `exit-gateway`. - -Currently the `nym-node` binary can only be run in a single `--mode` at any one time. In the future however, operators will be able to specify multiple modes that a single `nym-node` binary can run. Our goal is to have as many nodes as possible enabling multiple modes, and allow the Nym API to position the node according the network's needs in the beginning of each epoch. - -Every `exit-gateway` mode is basically an `entry-gateway` with NR (Network Requester) and IPR (IP Packet Router) enabled. This means that every `exit-gateway` is automatically seen as an `entry-gateway` but not the opposite. - -Gateway operators can check out the node performance, connectivity and much more in our new tool [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net/). - -To determine which mode your node is running, you can check the `:8080/api/v1/roles` endpoint. For example: -```sh -# sustitude or with a real one -# for http -http://:8080/api/v1/roles -# or -http:///api/v1/roles - -# for reversed proxy/WSS -https:///api/v1/roles -``` - -Everything necessary will exist on your node by default. For instance, if you're running a mixnode, you'll find that a NR (Network Requester) and IPR (IP Packet Router) address exist, but they will be ignored in `mixnode` mode. - -For more information about available endpoints and their status, you can refer to: -```sh -# sustitude or with a real one -# for http -http://:8080/api/v1/swagger/#/ -# or -http:///api/v1/swagger/#/ - -# for reversed proxy/WSS -https:///api/v1/swagger/#/ -``` - -## Usage - -### Help Command - -There are a few changes from the individual binaries used in the past. For example by default `run` command does `init` function as well, local node `--id` will be set by default unless specified otherwise etcetera. - -```admonish info -You can always use `--help` flag to see the commands or arguments associated with a given command. -``` - -Run `./nym-node --help` to see all available commands: - -~~~admonish example collapsible=true title="`./nym-node --help` output:" -``` - -``` -~~~ - -To list all available flags for each command, run `./nym-node --help` for example `./nym-node run --help`: - -~~~admonish example collapsible=true title="`./nym-node run --help` output:" -``` - -``` -~~~ - -```admonish warning -The Wireguard flags currently have limited functionality. From version `1.1.6` ([`v2024.9-topdeck`](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.9-topdeck)) wireguard is available and recommended to be switched on for nodes running as Gateways. Keep in mind that this option needs a bit of a special [configuration](configuration.md#wireguard-setup). -``` - -#### Flags Summary - -Some of the most useful flags and their explanation: - -~~~admonish example collapsible=true title="Flags explanation:" -- `--id `: Local identifier of your node. This `` determines your config path located at `~/.nym/nym-nodes//config/config.toml`, default value is `default-nym-node` -- `--accept-operator-terms-and-conditions`: Explicitly specify whether you agree with the terms and conditions of a nym node operator as defined at [nymtech.net/terms-and-conditions/operators/v1.0.0]({{toc_page}}) -- `--config-file `: Used for the migrate command to indicate the location of the existing node config file. Default path is `~/.nym/nym-nodes/default-nym-node/config/config.toml` -- `--deny-init`: Use this flag to prevent a new node from being initialized. It's recommended to use this after the first run to avoid accidental spinning up of a second node. -- `--init-only`: Use this flag if you want to set up a node without starting it. -- `--mode`: Determines the mode of the node and is always required. -- `--write-changes`: Used to change values within the `config.toml` file after the node has been run. -- `--mnemonic`: This is for when gateways are coconut-credentials-enforced, and this mnemonic is used as the `double_spend` prevention. This account needs credit in order for it to work. -- `--expose-system-info `: Sets your system info visibility on the network. -- `--expose-system-hardware `: Sets your system hardware info visibility on the network. -- `--expose-crypto-hardware `: Sets your crypto hardware info visibility on the network. -~~~ - -### Terms & Conditions - -```admonish info -From `nym-node` version `1.1.3` onward is required to accept [**Operators Terms & Conditions**]({{toc_page}}) in order to be part of the active set. Make sure to read them before you add the flag. -``` - -There has been a long ongoing discussion whether and how to apply Terms and Conditions for Nym network operators, with an aim to stay aligned with the philosophy of Free Software and provide legal defense for both node operators and Nym developers. To understand better the reasoning behind this decision, you can listen to the first [Nym Operator Town Hall](https://www.youtube.com/live/7hwb8bAZIuc?si=3mQ2ed7AyUA1SsCp&t=915) introducing the T&Cs or to [Operator AMA with CEO Harry Halpin](https://www.youtube.com/watch?v=yIN-zYQw0I0) from June 4th, 2024, explaining pros and cons of T&Cs implementation. - -Accepting T&Cs is done via a flag `--accept-operator-terms-and-conditions` added explicitly to `nym-node run` command every time. If you use [systemd](configuration.md#systemd) automation, add the flag to your service file's `ExecStart` line. - -To check whether any node has T&Cs accepted or not can be done by querying Swagger API endpoint `/auxiliary_details` via one of these ports (depending on node setup): -```sh -# sustitude or with a real one -http://:8080/api/v1/auxiliary_details -https:///api/v1/auxiliary_details -http:///api/v1/auxiliary_details -``` - -~~~admonish example collapsible=true title="Example of `/auxiliary_details` query" -```sh -# substitude with a real one -curl -X 'GET' \ - 'http://:8080/api/v1/auxiliary-details' \ - -H 'accept: application/json' - -{ - "location": "Kurdistan", - "accepted_operator_terms_and_conditions": true -} -``` -~~~ - -### Commands & Examples - -**`nym-node` introduces a default human readible ID (local only) `default-nym-node`, which is used if there is not an explicit custom `--id ` specified. All configuration is stored in `~/.nym/nym-nodes/default-nym-node/config/config.toml` or `~/.nym/nym-nodes//config/config.toml` respectively.** - -```admonish info -All commands with more options listed below include `--accept-operator-terms-and-conditions` flag, read [Terms & Conditions](#terms--conditions) chapter above before executing these commands. -``` - -### Initialise & Run - -When we use `run` command the node will do `init` as well, unless we specify with a flag `--deny-init`. Below are some examples of initialising and running `nym-node` with different modes (`--mode`) like `mixnode`, `entry-gateway`, `exit-gateway`. - -Please keep in mind that currently you can run only one functionality (`--mode`) per a `nym-node` instance. We are yet to finalise implement the multi-functionality solution under one node bonded to one Nyx account. Every `exit-gateway` can function as `entry-gateway` by default, not vice versa. - -```admonish success title="" -**We recommend operators to setup an [automation](configuration.md#systemd) flow for their nodes!** - -In such case, you can `run` a node to initalise it or try if everything works, but then stop the proces and paste your entire `run` command syntax (below) to the `ExecStart` line of your `/etc/systemd/system/nym-node.service` and start the node as a [service](configuration.md#following-steps-for-nym-nodes-running-as-systemd-service). -``` - -```admonish note -To prevent over-flooding of our documentation we cannot provide with every single command syntax as there is a large combination of possibilities. Please use a common sense and the explanation in `--help` option. -``` - -#### Mode: `exit-gateway` - -**Initialise and run** in one command: -```sh -# simple default -./nym-node run --mode exit-gateway - -# with other options -./nym-node run --id --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location --accept-operator-terms-and-conditions --wireguard-enabled true - -# is in format without 'https://' prefix -# is format like 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided. -# wireguard can be enabled from version 1.1.6 onwards -``` - -**Initialise only** without running the node with `--init-only` command : - -```sh -# simple default -./nym-node run --init-only --mode exit-gateway - -# with a custom `--id` and other options -./nym-node run --id --init-only --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location --accept-operator-terms-and-conditions --wireguard-enabled true - -# is in format without 'https://' prefix -# is format like 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided. -# wireguard can be enabled from version 1.1.6 onwards -``` - -Run the node with custom `--id` without initialising, using `--deny-init` command -```sh -./nym-node run --id --deny-init --mode exit-gateway --accept-operator-terms-and-conditions -``` - -#### Mode: `entry-gateway` - -**Initialise and run:** -```sh -./nym-node run --mode entry-gateway -``` - -Initialise & run with all options -```sh -./nym-node run --id --mode entry-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --accept-operator-terms-and-conditions --wireguard-enabled true - -# is in format without 'https://' prefix -# is format like 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided. -# wireguard can be enabled from version 1.1.6 onwards -``` - -Initialise only, with an `--init-only` command (a custom `--id` used): -```sh -./nym-node run --id --init-only --mode entry-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --accept-operator-terms-and-conditions -``` - -Run the node with custom `--id` without initialising: -```sh -./nym-node run --id --deny-init --mode entry-gateway --accept-operator-terms-and-conditions -``` - -#### Mode: `mixnode` - -**Initialise and run:** -```sh -./nym-node run --mode mixnode -``` - -Initialise only with a custom `--id` and `--init-only` command: -```sh -./nym-node run --id --init-only --mode mixnode --verloc-bind-address 0.0.0.0:1790 --public-ips "$(curl -4 https://ifconfig.me)" --accept-operator-terms-and-conditions -``` - -Run the node with custom `--id` without initialising: -```sh -./nym-node run --id --deny-init --mode mixnode --accept-operator-terms-and-conditions -``` - -### Migrate - -```admonish caution -Migration is a must for all deprecated nodes (`nym-mixnode`, `nym-gateway`). For backward compatibility we created an [archive section](../archive/nodes/setup-guides.md) with all the guides for individual binaries. However, the binaries from version 1.1.35 (`nym-gateway`) and 1.1.37 (`nym-mixnode`) onwards will no longer have `init` command. -``` - -Operators who are about to migrate their nodes need to configure their [VPS](vps-setup.md) and setup `nym-node` which can be downloaded as a [pre-built binary](../binaries/pre-built-binaries.md) or compiled from [source](../binaries/building-nym.md). - -To migrate a `nym-mixnode` or a `nym-gateway` to `nym-node` is fairly simple, use the `migrate` command with `--config-file` flag pointing to the original `config.toml` file, with a conditional argument defining which type of node this configuration belongs to. Examples are below. - -Make sure to use `--deny-init` flag to prevent initialisation of a new node. - -#### Mode: `mixnode` -```sh -# move relevant infor from config.toml -./nym-node migrate --config-file ~/.nym/mixnodes//config/config.toml mixnode - -# initialise with the new nym-node config -./nym-node run --mode mixnode --id --accept-operator-terms-and-conditions -``` - -#### Mode: `entry-gateway` and `exit-gateway` -```sh -# move relevant infor from config.toml -./nym-node migrate --config-file ~/.nym/gateways//config/config.toml gateway - -# initialise with the new nym-node config - entry-gateway -./nym-node run --mode entry-gateway --id --accept-operator-terms-and-conditions - -# or as exit-gateway -./nym-node run --id --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location --accept-operator-terms-and-conditions --wireguard-enabled false -``` - -### Next steps - -If there are any problems checkout the troubleshooting section or report an issue. - -Follow up with [configuration](configuration.md) page for automation, reversed proxy setup and other tweaks, then head straight to [bonding](bonding.md) page to finalise your setup. diff --git a/documentation/old_docs/operators/src/nodes/testing/docker-monitor.md b/documentation/old_docs/operators/src/nodes/testing/docker-monitor.md deleted file mode 100644 index 78f1e17d7d..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/docker-monitor.md +++ /dev/null @@ -1,246 +0,0 @@ - - -# Setup Prometheus and Grafana in a Docker - -This setup may seem more complex than running a few scripts, but it has certain advantages. -- Running things in a container - - -## Docker, Prometheus and Grafana Metric SETUP - -This setup can be done from the same VPS like your node or on a completelly remote machine. In any case it's setup in a Docker container so it works remotely from the environment where your node runs. - -### Docker setup - - - -### Prometheus Setup - -This entire installation shall be done with `root` privileges. If you not `root`, start with `su` command before the following steps. - -1. Get the latets system updates -```sh -apt update -``` - -2. Create a system user for Prometheus -```sh -groupadd --system prometheus -useradd -s /sbin/nologin --system -g prometheus prometheus -``` - -3. Create directories for Prometheus -```sh -mkdir /etc/prometheus -mkdir /var/lib/prometheus -``` - -4. Download and extract Prometheus -```sh -wget https://github.com/prometheus/prometheus/releases/download/v{{prometheus_latest_version}}/prometheus-{{prometheus_latest_version}}.linux-amd64.tar.gz -tar vxf prometheus-{{prometheus_latest_version}}.linux-amd64.tar.gz -``` -In case of errors, check Prometheus [release page](https://github.com/prometheus/prometheus/releases/) and get the correct binary for your system. - -5. Navigate to Prometheus directory and configure Prometheus -```sh -# change directory -cd prometheus-{{prometheus_latest_version}}.linux-amd64 - -# move the binary files -mv prometheus /usr/local/bin -mv promtool /usr/local/bin - -# set owner -chown prometheus:prometheus /usr/local/bin/prometheus -chown prometheus:prometheus /usr/local/bin/promtool - -# move the config files -mv consoles /etc/prometheus -mv console_libraries /etc/prometheus -mv prometheus.yml /etc/prometheus - - -# set owner -chown prometheus:prometheus /etc/prometheus -chown -R prometheus:prometheus /etc/prometheus/consoles -chown -R prometheus:prometheus /etc/prometheus/console_libraries -chown -R prometheus:prometheus /var/lib/prometheus -``` - -6. Open the main Prometheus config file `prometheus.yml` -```sh -nano /etc/prometheus/prometheus.yml -``` - -7. Paste the block below to your config `prometheus.yml`, change the line `credentials` and save it (`ctrl` + `x`) - - `credentials` value must be the same like in your node `config.toml` config file under `[http]` header - - In case you haven't set up yet a `` in your node `config.toml`, add it by opening a machine with your node and run [this script](https://gist.github.com/benedettadavico/1299b2c7b8b8282c15eafb1914fb3594) with an arbitrary `` of your own choice as an argument, follow these commands with your own **strong passphrase** -```sh -# get the script -curl -L https://gist.githubusercontent.com/benedettadavico/1299b2c7b8b8282c15eafb1914fb3594/raw/500c36037615a515f2f3e007baa25e6a2c277d4a/update_config.sh -o update_config.sh - -# make executable -chmod u+x ./update_config.sh - -# run with your own key as argument -sh ./update_config.sh - -# for example if you chose my passhphrase to be: "makemoresecurekeythanthis1234" -# the command would look like this -# sh ./update_config.sh makemoresecurekeythanthis1234 -``` - - Add this `` string to your monitoring Prometheus config `prometheus.yml` as a value to `credentials`, paste the block below to your `prometheus.yml` as below - -```yaml -# my global config -global: - scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. - evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. - # scrape_timeout is set to the global default (10s). - -# Alertmanager configuration -alerting: - alertmanagers: - - static_configs: - - targets: - # - alertmanager:9093 - -# Load rules once and periodically evaluate them according to the global 'evaluation_interval'. -rule_files: - # - "first_rules.yml" - # - "second_rules.yml" - -# A scrape configuration containing exactly one endpoint to scrape: - -scrape_configs: - # The job name is added as a label `job=` to any timeseries scraped from this config. - - job_name: "prometheus" - authorization: - # CHANGE THIS TO YOUR OWN STRING - credentials: - - static_configs: - - targets: ["localhost:9090"] - - file_sd_configs: - - files: - - /tmp/prom_targets.json -``` - -8. Create Prometheus systemd service by saving the block below to as `/etc/systemd/system/prometheus.service`: - -```sh -nano /etc/systemd/system/prometheus.service -``` - -```sh -[Unit] -Description=Prometheus -Wants=network-online.target -After=network-online.target - -[Service] -User=prometheus -Group=prometheus -Type=simple -ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - -[Install] -WantedBy=multi-user.target -``` - -9. Reload, enable, start and check Prometheus service -```sh -systemctl daemon-reload -systemctl enable prometheus -systemctl start prometheus -systemctl status prometheus - -# to observe journal log, run -journalctl -f -u prometheus -``` - -10. Open port for Prometheus web interface -```sh -ufw allow 9090/tcp -``` -11. Finally you can access Prometheus on `localhost:9090` or `:9090` - -Further reading on Prometheus functionalities: -- [Alerting overview](https://prometheus.io/docs/alerting/latest/overview/) -- [Exporters and Integration](https://prometheus.io/docs/instrumenting/exporters/) - -### Grafana Setup - - - -## Setup Access on your Node - -This part needs to be done on the machine where your node runs - -### Node Exporter Setup - - - -## Grafana Dashboard Access - -Finally we need to access Grafana dashboards. - -1. Open a browser at `http://:3000` or `https://` (depends on your setup), enter username `admin` and password `admin` and setup new credentials on prompt - -2. Setup *Data source* by opening menu -> `Connections` -> `Data sources` -> `+ Add new data source` -> `Prometheus` - -![](../images/grafana/add-data-sources.png) -![](../images/grafana/add-data-source-prometheus.png) - -3. In the field *Connection* next to `Prometheus server URL` enter `http://localhost:9090` (regardless if you accessing Grafana via `http` or `https` as this is for internal connection on the server). When you are done in the bottom confirm by `Save & Test` - -4. In the menu open: `Dashboards` -> `+ Create dashboard` -> `Import dashboard` - -![](../images/grafana/import-dashboard.png) - -5. ID field: enter `1860` -> `Load` - -![](../images/grafana/id-1860.png) - -6. In *Import dashboard* page select Prometheus in the bottom and finally `Import` - -![](../images/grafana/add-prometheus.png) - -Now you have your Prometheus panels displayed via Grafana dashboard for a simple monitoring of your node. - - - - -## Grafana Setup diff --git a/documentation/old_docs/operators/src/nodes/testing/explorenym-scripts.md b/documentation/old_docs/operators/src/nodes/testing/explorenym-scripts.md deleted file mode 100644 index 4b9ee6bdbe..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/explorenym-scripts.md +++ /dev/null @@ -1,131 +0,0 @@ -# ExploreNym Monitoring Scripts - -## Community Monitoring Tools - -Individual operators, node families and squads are the foundation of distributed network. There has been a great number of tools coming out of this community some of which can be deployed for the node monitoring setup. - -```admonish warning -Make sure you understand and properly evaluate what degree of control you give permission to before granting access to your data to any tools running on someone else's servers. -``` - -## ExploreNYM Tools - -Long term involved operator Pawnflake, an author of [ExploreNYM](https://explorenym.net/) explorer, created a monitoring flow, which can be used by other operators called [`self-hosted-monitor`](https://github.com/ExploreNYM/self-hosted-monitor). It utilises bash scripts to enable operators setup [Prometheus](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/prometheus.sh) and [Grafana](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/grafana.sh) together with [Node Exporter](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/node-exporter.sh) and [Nginx](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/nginx-certbot.sh) to run their metrics monitoring stack locally. - -In collaboration with ExploreNYM we published a [step by step guide](#setup) to set this up. - -ExploreNYM also has a network measuring instance called `enym-monitor`. This setup is very simple for users, however it means that their data are all aggregated into one server and that is a design we would like to discourage from using as a primary one because such setup always brings a risk of centralisation of distributed node's data into one computer. - -## Setup - -```admonish warning -This setup and the scripts included were not written by Nym developers. As always do your own audit before installing any scripts on your machine and familiarize yourself with the security risks involved when opening ports or allowing http access. -``` - -According to ExploreNYM the system requirements of the monitor stack are: -- 2 CPU -- 4 GB RAM -- 20 GB of free disk space. - -### The monitoring part setup - -This can be setup on another VPS than the node if desired. We recommend to try to set this up on the same VPS, as your node as we expect the machine to be strong enough to handle the node with enough capacity reserve for monitor. - -1. Install git -```sh -apt install git -``` - -2. Clone the repository to `~/self-hosted-monitor` -```sh -git clone https://github.com/ExploreNYM/self-hosted-monitor ~/self-hosted-monitor -``` - -3. Give permissions to [`prometheus.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/prometheus.sh) script and run it to setup Prometheus -```sh -chmod +x ~/self-hosted-monitor/prometheus.sh && ~/self-hosted-monitor/prometheus.sh -``` - -4. Give permissions to [`grafana.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/grafana.sh) script and run it to setup Grafana -```sh -chmod +x ~/self-hosted-monitor/grafana.sh && ~/self-hosted-monitor/grafana.sh -``` - -5. Open port `3000` to allow access to Grafana -```sh -sudo ufw allow 3000 -``` - -6. You can now access Grafana at `http://:3000`. - -7. (*Optional step*) If you have a registered domain and prefer to use it with `https`, give permissions to [`nginx-certbot.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/nginx-certbot.sh) script and run it to setup Nginx and Certbot -```sh -chmod +x ~/self-hosted-monitor/nginx-certbot.sh && ~/self-hosted-monitor/nginx-certbot.sh -``` - -8. Give permissions to [`prometheus-target.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/prometheus-target.sh) script and run it to add a scrape target. This can be run multiple times to add a new server to be monitored via Prometheus/ -```sh -chmod +x ~/self-hosted-monitor/prometheus-target.sh && ~/self-hosted-monitor/prometheus-target.sh -``` - -### The target server (the part to be monitored) setup - -If you run a monitoring stack and your node on two different VPS, the steps 9 and 10 need to be done on the VPS with the running node. In case you do it on the same VPS, skip directly to step 11 and continue. - -9. Install git -```sh -apt install git -``` - -10. Clone the repository to `~/self-hosted-monitor` -```sh -git clone https://github.com/ExploreNYM/self-hosted-monitor ~/self-hosted-monitor -``` -11. Give permissions to [`node-exporter.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/node-exporter.sh) script and run it to setup Node exporter. -```sh -chmod +x ~/self-hosted-monitor/node-exporter.sh && ~/self-hosted-monitor/node-exporter.sh -``` - -### Grafana dashboard setup - -Finally we need to access Grafana dashboards. - -12. Open a browser at `http://:3000` or `https://` (depends on your setup), enter username `admin` and password `admin` and setup new credentials on prompt - -13. Setup *Data source* by opening menu -> `Connections` -> `Data sources` -> `+ Add new data source` -> `Prometheus` - -![](../images/grafana/add-data-sources.png) -![](../images/grafana/add-data-source-prometheus.png) - -14. In the field *Connection* next to `Prometheus server URL` enter `http://localhost:9090` (regardless if you accessing Grafana via `http` or `https` as this is for internal connection on the server). When you are done in the bottom confirm by `Save & Test` - -15. In the menu open: `Dashboards` -> `+ Create dashboard` -> `Import dashboard` - -![](../images/grafana/import-dashboard.png) - -16. ID field: enter `1860` -> `Load` - -![](../images/grafana/id-1860.png) - -17. In *Import dashboard* page select Prometheus in the bottom and finally `Import` - -![](../images/grafana/add-prometheus.png) - -Now you have your Prometheus panels displayed via Grafana dashboard for a simple monitoring of your node. - -## Verification and Troubleshooting - -To ensure that your services are running correctly, you can verify that by running `systemctl status ` or run a `journalctl -f -u ` to print service logs. It shall return status `Active: active (running)`. For example: -```sh -# to check if Prometheus service is active -systemctl status prometheus - -# to check if Grafana service is active -systemctl status grafana-server - -# to check if node-exporter service is active -systemctl status node_exporter - -# to run journal log -journalctl -f -u prometheus # or any other service you want to see -``` diff --git a/documentation/old_docs/operators/src/nodes/testing/gateway-probe.md b/documentation/old_docs/operators/src/nodes/testing/gateway-probe.md deleted file mode 100644 index 235758faca..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/gateway-probe.md +++ /dev/null @@ -1,79 +0,0 @@ -# Nym Gateway Probe - -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/v1/gateways) -- [`explorer-api`](https://explorer.nymtech.net/api/v1/gateways) -- [`harbour-master`](https://harbourmaster.nymtech.net/) - - -## Preparation - -We recommend to have install all [the prerequisites](../binaries/building-nym.md#prerequisites) needed to build `nym-node` from source including latest [Rust Toolchain](https://www.rust-lang.org/tools/install). - -## Installation - -`nym-gateway-probe` source code is in [`nym-vpn-client`](https://github.com/nymtech/nym-vpn-client) repository. The client needs to be build from source. - -1. Clone the repository: - -```sh -git clone https://github.com/nymtech/nym-vpn-client.git -``` - -2. Build `nym-gateway-probe`: - -```sh -cd nym-vpn-client/nym-vpn-core - -cargo build --release -p nym-gateway-probe -``` - -## Running the client - -```sh -./target/release/nym-gateway-probe --help -``` -~~~admonish example collapsible=true title="`nym-gateway-probe --help`" -``` -Usage: nym-gateway-probe [OPTIONS] - -Options: - -c, --config-env-file Path pointing to an env file describing the network - -g, --gateway - -n, --no-log - -h, --help Print help - -V, --version Print version - -``` -~~~ - -To run the client, simply add a flag `--gateway` with a targeted gateway identity key. - -```sh -./target/release/nym-gateway-probe --gateway -``` - -For any `nym-node --mode exit-gateway` the aim is to have this outcome: -```sh -{ - "gateway": "", - "outcome": { - "as_entry": { - "can_connect": true, - "can_route": true - }, - "as_exit": { - "can_connect": true, - "can_route_ip_v4": true, - "can_route_ip_external_v4": true, - "can_route_ip_v6": true, - "can_route_ip_external_v6": true - } - } -} -``` - -If your Gateway is blacklisted, the probe will not work. - -If you don't provide a `--gateway` flag it will pick a random one to test. diff --git a/documentation/old_docs/operators/src/nodes/testing/node-api-check.md b/documentation/old_docs/operators/src/nodes/testing/node-api-check.md deleted file mode 100644 index 1e11ddeed7..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/node-api-check.md +++ /dev/null @@ -1,125 +0,0 @@ -# Node API Check - -> Any syntax in `<>` brackets is a user's unique variable/version. Exchange with a corresponding name without the `<>` brackets. - -Operating a `nym-node` is not a *"set and forget"* endeavor, it takes some work. To diagnose node performance querying APIs is a good knowledge to have. There are two main places to look for API endpoints regarding `nym-node`: - -- [`openapi.json`](https://validator.nymtech.net/api/v1/openapi.json): a list of all endpoints -- [Swagger UI page](https://validator.nymtech.net/api/swagger/index.html) - -Besides that, Gateway operators can check out their node performance, connectivity and much more on [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net/). - -### Basic API usage - -For information about available endpoints and their status, you can refer to: -```sh -# sustitude or with a real one -# for http -http://:8080/api/v1/swagger/#/ -# or -http:///api/v1/swagger/#/ - -# for reversed proxy/WSS -https:///api/v1/swagger/#/ -``` - -For example to determine which mode your node is running, you can check `:8080/api/v1/roles` endpoint: -```sh -# sustitude or with a real one -# for http -http://:8080/api/v1/roles -# or -http:///api/v1/roles - -# for reversed proxy/WSS -https:///api/v1/roles -``` - -## `node_api_check.py` - -To make this a bit easier, we made a CLI tool querying all available API endpoints based on node `Identity Key` (further denoted as ``) called `node_api_check.py`. To diagnose your node performance, whether by yourself or by sharing an output in our [operator channel](https://matrix.to/#/#operators:nymtech.chat), this tool provides you with a quick overview of live data. We recommend to run this checker alongside [`nym_gateway_probe`](gateway-probe.md) to triage both performance and an actual routing. - -Besides querying any bonded node APIs, `nym_api_check` has a function counting all existing nodes in provided version. - -### Setup - -#### Pre-requsities - -**Python3** - -1. Start with installing Python3: -```sh -sudo apt install python3 -``` - -2. Make sure Python3 is your default Python version: -```sh -update-alternatives --install /usr/bin/python python /usr/bin/python3 1 - -# controll -python --version - -# should return higher than 3 -``` - -3. Install Python modules `tabulate`, `pandas` and `argparse`: -- either using [`pip`](https://python.land/virtual-environments/installing-packages-with-pip) and then running: -```sh -pip install tabulate pandas argparse -``` -- or if you installed Python3 system-wide you can install modules directly: -```sh -sudo apt install python3-tabulate python3-pandas python3-argparse -``` - -**Installation** - -4. Get [`node_api_check.py`](https://github.com/nymtech/nym/tree/develop/scripts/node_api_check.py) and [`api_endpoints.json`](https://github.com/nymtech/nym/tree/develop/scripts/api_endpoints.json). If you [compiled from source](../binaries/building-nym.md), you already have both of these files. If you prefer to download them individually, do it by opening terminal in your desired location and running: -```sh -wget https://raw.githubusercontent.com/nymtech/nym/tree/develop/node_api_check.py - -wget https://raw.githubusercontent.com/nymtech/nym/tree/develop/api_endpoints.json -``` - -5. Make executable: -```sh -chmod u+x node_api_check.py -``` - -Now you are ready to check your node. - -### Usage - -Run with `--help` flag to see the available commands: - -~~~admonish example collapsible=true title="./node_api_check.py --help" -```python - -``` -~~~ - -#### `query_stats` - -When you want to see all the options connected to a command, add a `--help` flag after the command of your choice, like in this example: -~~~admonish example collapsible=true title="./node_api_check.py query_stats --help" -```python - -``` -~~~ - -The most common usage may be `./node_api_check.py query_stats ` where `` is required, substitute it with node Identity Key. - -**Optional arguments** - -| Flag | Shortcut | Description | -| :--- | :--- | :--- | -| `--markdown` | `-m` | returns output in markdown format | -| `--no_routing_history` | `-n` | returns output without routing history which can be lengthy | -| `--output` | `-o` | exports output to a file, possible to add a target path | - -#### `version_count` - -Another command is `version_count` where at least one `nym-node` version is required. In case of multiple version count, separate the versions with space. We recommend to run this command with `--markdown` flag for a nicer output. This is an example where we want to look up how many registered nodes are on versions `1.1.0`, `1.1.1`, `1.1.2` and `1.1.3`: -```sh -./node_api_check version_count 1.1.0 1.1.1 1.1.2 1.1.3 --markdown -``` diff --git a/documentation/old_docs/operators/src/nodes/testing/node-setup.md b/documentation/old_docs/operators/src/nodes/testing/node-setup.md deleted file mode 100644 index 0d27b52159..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/node-setup.md +++ /dev/null @@ -1,76 +0,0 @@ -# Node Setup for Performance Testing Event - -```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. -``` - -To join the [Performance testing event]({{performance_testing_webpage}}) node operators need to do proceed with the following tasks: - -1. **[Sign their node]({{performance_testing_webpage}}) into the testing environment** -2. **[Configure their node](#node-configuration) for the test** -3. (*Not mandatory*) [Setup metric monitoring system](performance.md#monitoring) to observe node performance at any time - -## Node Configuration - -> Any syntax in `<>` brackets is a user's unique variable/version. Exchange with a corresponding name without the `<>` brackets. - -After you signed your node (or several) into the Performance testing environment, open the machine with (each of) your nodes and follow the steps below to configure your node for the event. - - -#### 1. Download and upgrade to `{{performance_testing_release}}` binary - - Download the binary from Nym [release page](https://github.com/nymtech/nym/releases/) (use `wget` or `curl` and binary download URL, don't compile from `master`) - - Follow the steps to upgrade node on the [maintenance page](../nodes/manual-upgrade.md) - - Before you re-start your node, follow the steps below - - -#### 2. If you run `gateway` mode proceed with these steps. If not, go to the next point - - Make sure to have your `nym-node --exit-gateway` setup as [Nym Exit Gateway](../legal/exit-gateway.md) following the commands [here](..//nodes/nym-node.md#quick-nym-node---mode-exit-gateway-setup) - - - - -#### 3. Restart your node with root privileges and verify connectivity - - Either in a root shell or with `sudo -E` command - - In case you run your node as a [`systemd` service](../nodes/maintenance.md#systemd) make sure to run `systemctl daemon-reload` before the `service nym-node restart` - - Verify that it all worked out on [Nym Harbour Master](https://harbourmaster.nymtech.net/) - -## Troubleshooting - -If you come to any errors during the setup visit [troubleshooting page](../troubleshooting/nodes.md#gateways-mode). In case your issue isn't documented ask in our Element [Node Operators channel](https://matrix.to/#/#operators:nymtech.chat) or raise an [issue](https://github.com/nymtech/nym/issues) on Github. - diff --git a/documentation/old_docs/operators/src/nodes/testing/performance.md b/documentation/old_docs/operators/src/nodes/testing/performance.md deleted file mode 100644 index af98086fbe..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/performance.md +++ /dev/null @@ -1,58 +0,0 @@ -# Performance Monitoring & Testing - -Nym Mixnet has been running on mainnet for quite some time. There is still work to be done in order for the network to meet its full potential - mass adoption of privacy through fully distributed Mixnet. - -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! - -## Monitoring - -There are multiple ways to monitor performance of nodes and the machines on which they run. For the purpose of maximal privacy and decentralisation of the data - preventing Nym Mixnet from any global adversary takeover - we created these pages as a source of mutual empowerment, a place where operators can share and learn new skills to **setup metrics monitors on their own infrastructure**. - -### Guides to Setup Own Metrics - -A list of different scripts, templates and guides for easier navigation: - -* [`nym-gateway-probe`](gateway-probe.md) - a useful tool used under the hood of [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net) -* [Prometheus and Grafana](prometheus-grafana.md) self-hosted setup -* [Nym-node CPU cron service](https://gist.github.com/tommyv1987/97e939a7adf491333d686a8eaa68d4bd) - an easy bash script by Nym core developer [@tommy1987](https://gist.github.com/tommyv1987), designed to monitor a CPU usage of your node, running locally -* Nym's script [`prom_targets.py`](https://github.com/nymtech/nym/blob/develop/scripts/prom_targets.py) - a useful python program to request data from API and can be run on its own or plugged to more sophisticated flows - -### Collecting Testing Metrics - -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 - -```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. -``` - -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: - -1. Understanding of the network behavior under full load - - How many mixnet client users can all active set entry gateways handle simultaneously? - - How much sustained IP traffic can a subset of mainnet nodes sustain? -2. Needed improvements of Nym Node binaries to improve the throughput on mainnet -3. Measurement of required machine specs -4. Raw data record -5. Increase quality of Nym Nodes -6. Show each operator a way to monitor their nodes in a distributed fashion - -Visit [Fast and Furious web page]({{performance_testing_webpage}}) and [Nym Harbour Master](https://harbourmaster.nymtech.net/) Gateways monitoring page to read more about the performance testing and the results of it. - - - diff --git a/documentation/old_docs/operators/src/nodes/testing/prometheus-grafana.md b/documentation/old_docs/operators/src/nodes/testing/prometheus-grafana.md deleted file mode 100644 index 3ea0f88d5e..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/prometheus-grafana.md +++ /dev/null @@ -1,36 +0,0 @@ -# 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/self-hosted-monitor) or [No Trust Verify](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1). - - - -## Prometheus - -[Prometheus](https://prometheus.io) is a free and open source monitoring systems. It allows operators to have their metrics, events, and alerts under full control. This ecosystem offers multiple advantages: - -- collects and records metrics from servers, containers, and applications -- provides a [flexible query language (PromQL)](https://prometheus.io/docs/prometheus/latest/querying/basics/) -- multiple modes visualization tools -- an alerting mechanism that sends notifications - -Prometheus collects and stores its metrics as time series data, i.e. metrics information is stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels. - -## Grafana - -[Grafana](https://grafana.com/docs/grafana/latest/) is an open-source analytics and interactive front end. It is widely used for its easy to manage dashboards with visualizations like graphs, charts and alerts, all connected to live data sources. - -## Setup Guides - -There are various ways how to setup this stack. You can chose based on your preferences to do your own flow or follow some of the documented ones: - -- [ExploreNYM scripts](explorenym-scripts.md) for self-hosted monitoring -- Setup monitoring in a Docker container (*detailed guide will be published soon*) - - -## References and further reading - -* [Prometheus release page](https://prometheus.io/download/) -* [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/develop/scripts/prom_targets.py) - a python program to request data from API and can be plugged to this stack diff --git a/documentation/old_docs/operators/src/nodes/testing/templates.md b/documentation/old_docs/operators/src/nodes/testing/templates.md deleted file mode 100644 index d55213cfad..0000000000 --- a/documentation/old_docs/operators/src/nodes/testing/templates.md +++ /dev/null @@ -1,17 +0,0 @@ -# Metrics of Performance Testing - -At Nym as well as several core community operators had setup metrics monitors for a clear overview of node performance. - -It is beneficial for a one time event or a limited period to connect nodes to the existing monitoring infrastructure system that Nym developers built to collect useful metrics. For the purpose of maximal privacy and decentralisation of the data - preventing Nym Mixnet from any global adversary takeover - we created these pages as a source of mutual empowerment, a place where operators can share and learn new skills to **setup metrics monitors on their own infrastructure**. - -## Collecting Testing Metrics - -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. - -## Guides to Setup Own Metrics - -A list of different scripts, templates and guides for easier navigation: - -* [Prometheus and Grafana](prometheus-grafana.md) self-hosted setup -* [Nym-node CPU cron service](https://gist.github.com/tommyv1987/97e939a7adf491333d686a8eaa68d4bd) - an easy bash script by Nym core developer [@tommy1987](https://gist.github.com/tommyv1987), designed to monitor a CPU usage of your node, running locally -* Nym's script [`prom_targets.py`](https://github.com/nymtech/nym/blob/develop/scripts/prom_targets.py) - a useful python program to request data from API and can be run on its own or plugged to more sophisticated flows diff --git a/documentation/old_docs/operators/src/nodes/validator-setup.md b/documentation/old_docs/operators/src/nodes/validator-setup.md deleted file mode 100644 index 384d01f15c..0000000000 --- a/documentation/old_docs/operators/src/nodes/validator-setup.md +++ /dev/null @@ -1,553 +0,0 @@ -# Validators - -> 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 & maintained as a no-modification fork of [wasmd](https://github.com/CosmWasm/wasmd) - -The validator is a Go application which implements it's functionalities using [Cosmos SDK](https://v1.cosmos.network/sdk). The underlying state-replication engine is powered by [CometBFT](https://cometbft.com/), where the consensus mechanism is based on the [Tendermint Consensus Algorithm](https://arxiv.org/abs/1807.04938). Finally, a [CosmWasm](https://cosmwasm.com) smart contract module controls crucial mixnet functionalities like decentralised directory service, node bonding, and delegated mixnet staking. - -> We are currently running mainnet with a closed set of reputable validators. To ensure decentralisation of Nyx chain, we are working on a mechanism to onboard new validators to the network. To join the waitlist, please drop an email to `validators [at] nymtech.net` with details of your setup, experience and any other relevent information - -## Building your validator - -> Any syntax in `<>` brackets is a user's unique variable. Exchange it with a corresponding name without the `<>` brackets. - -### Prerequisites -#### `git`, `gcc`, `jq` - -* Debian-based systems: -``` -apt install git build-essential jq - -# optional additional manual pages can be installed with: -apt-get install manpages-dev -``` - -* Arch-based systems: -Install `git`, `gcc` and `jq` with the following: -``` -pacman -S git gcc jq -``` - -#### `Go` -`Go` can be installed via the following commands (taken from the [Go Download and install page](https://go.dev/doc/install)): - -``` -# First remove any existing old Go installation and extract the archive you just downloaded into /usr/local: -# You may need to run the command as root or through sudo -rm -rf /usr/local/go && tar -C /usr/local -xzf go1.20.10.linux-amd64.tar.gz - -# Add /usr/local/go/bin to the PATH environment variable -export PATH=$PATH:/usr/local/go/bin -source $HOME/.profile -``` - -Verify `Go` is installed with: - -``` -go version -# Should return something like: -go version go1.20.10 linux/amd64 -``` - -### Download a precompiled validator binary -You can find pre-compiled binaries for Ubuntu `22.04` and `20.04` [here](https://github.com/nymtech/nyxd/releases). - -### Manually compiling your validator binary -The codebase for the Nyx validators can be found [here](https://github.com/nymtech/nyxd). - -The validator binary can be compiled by running the following commands: -``` -git clone https://github.com/nymtech/nyxd.git -cd nyxd - -# Make sure to check releases for the latest version information -git checkout release/ - -# Build the binaries -make build -``` -At this point, you will have a copy of the `nyxd` binary in your `build/` directory. Test that it's compiled properly by running: - -``` -./build/nyxd -``` - -You should see a similar help menu printed to you: - -~~~admonish example collapsible=true title="Console output" -``` -Nyx Daemon (server) - -Usage: - nyxd [command] - -Available Commands: - completion Generate the autocompletion script for the specified shell - config Create or query an application CLI configuration file - debug Tool for helping with debugging your application - export Export state to JSON - genesis Application's genesis-related subcommands - help Help about any command - init Initialize private validator, p2p, genesis, and application configuration files - keys Manage your application's keys - prune Prune app history states by keeping the recent heights and deleting old heights - query Querying subcommands - rollback rollback cosmos-sdk and tendermint state by one height - rosetta spin up a rosetta server - start Run the full node - status Query remote node for status - tendermint Tendermint subcommands - testnet subcommands for starting or configuring local testnets - tx Transactions subcommands - version Print the application binary version information - -Flags: - -h, --help help for nyxd - --home string directory for config and data - --log_format string The logging format (json|plain) (default "plain") - --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) (default "info") - --trace print out full stack trace on errors - -Use "nyxd [command] --help" for more information about a command. -``` -~~~ - -### Linking `nyxd` to `libwasmvm.so` - -`libwasmvm.so` is the wasm virtual machine which is needed to execute smart contracts in `v0.26.1`. This file is renamed in `libwasmvm.x86_64.so` in `v0.31.1` and above. - -If you downloaded your `nyxd` binary from Github, you will have seen this file when un-`tar`-ing the `.tar.gz` file from the releases page. - -If you are seeing an error concerning this file when trying to run `nyxd`, then you need to move the `libwasmvm.x86_64.so` file to correct location. - -Simply `cp` or `mv` that file to `/lib/x86_64-linux-gnu/` and re-run `nyxd`. - -### Adding `nyxd` to your `$PATH` -You'll need to set `LD_LIBRARY_PATH` in your user's `~/.bashrc` or `~/.zshrc` file (depends on the terminal you use), and add that to our path. Replace `/home///binaries` in the command below to the locations of `nyxd` and `libwasmvm.so` and run it. If you have compiled these on the server, they will be in the `build/` folder: - -``` -NYX_BINARIES=/home/// - -# if you are using another shell like zsh replace '.bashrc' with the relevant config file -echo 'export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:'NYX_BINARIES >> ~/.bashrc -echo 'export PATH=$PATH:'${NYX_BINARIES} >> ~/.bashrc -source ~/.bashrc -``` - -Test everything worked: - -``` -nyxd -``` - -This should return the regular help menu: - -~~~admonish example collapsible=true title="Console output" -``` -Nyx Daemon (server) - -Usage: - nyxd [command] - -Available Commands: - completion Generate the autocompletion script for the specified shell - config Create or query an application CLI configuration file - debug Tool for helping with debugging your application - export Export state to JSON - genesis Application's genesis-related subcommands - help Help about any command - init Initialize private validator, p2p, genesis, and application configuration files - keys Manage your application's keys - prune Prune app history states by keeping the recent heights and deleting old heights - query Querying subcommands - rollback rollback cosmos-sdk and tendermint state by one height - rosetta spin up a rosetta server - start Run the full node - status Query remote node for status - tendermint Tendermint subcommands - testnet subcommands for starting or configuring local testnets - tx Transactions subcommands - version Print the application binary version information - -Flags: - -h, --help help for nyxd - --home string directory for config and data - --log_format string The logging format (json|plain) (default "plain") - --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) (default "info") - --trace print out full stack trace on errors - -Use "nyxd [command] --help" for more information about a command. -``` -~~~ - -## Initialising your validator -### Prerequisites: - -- FQDN Domain name -- IPv4 and IPv6 connectivity - -Choose a name for your validator and use it in place of `` in the following command: - -``` -# Mainnet -nyxd init --chain-id=nyx - -# Sandbox testnet -nyxd init --chain-id=sandbox -``` - -```admonish caution title="" -`init` generates `priv_validator_key.json` and `node_key.json`. - -If you have already set up a validator on a network, **make sure to back up the key located at** -`~/.nyxd/config/priv_validator_key.json`. - -If you don't save the validator key, then it can't sign blocks and will be jailed all the time, and -there is no way to deterministically (re)generate this key. -``` - -At this point, you have a new validator, with its own genesis file located at `$HOME/.nyxd/config/genesis.json`. You will need to replace the contents of that file that with either the Nyx Mainnet or Sandbox Testnet genesis file. - -You can use the following command to download them for the correct network: - -``` -# Mainnet -wget -O $HOME/.nyxd/config/genesis.json https://nymtech.net/genesis/genesis.json - -# Sandbox testnet -curl https://rpc.sandbox.nymtech.net/snapshots/genesis.json | jq '.result.genesis' > $HOME/.nyxd/config/genesis.json -``` - -### `config.toml` configuration - -Edit the following config options in `$HOME/.nyxd/config/config.toml` to match the information below for your network: - -``` -# Mainnet -persistent_peers = "ee03a6777fb76a2efd0106c3769daaa064a3fcb5@51.79.21.187:26656" -laddr = "tcp://0.0.0.0:26656" -``` - -``` -# Sandbox testnet -cors_allowed_origins = ["*"] -persistent_peers = "26f7782aff699457c8e6dd9a845e5054c9b0707e@:3.72.19.120:26656" -laddr = "tcp://0.0.0.0:26656" -``` - -These affect the following: -* `persistent_peers = "@.nymtech.net:26666"` allows your validator to start pulling blocks from other validators. **The main sandbox validator listens on `26666` instead of the default `26656` for debugging**. It is recommended you do not change your port from `26656`. -* `laddr = "tcp://0.0.0.0:26656"` is in your p2p configuration options - -Optionally, if you want to enable [Prometheus](https://prometheus.io/) metrics then the following must also match in the `config.toml`: - -- `prometheus = true` -- `prometheus_listen_addr = ":26660"` - -> Remember to enable metrics in the 'Configuring Prometheus metrics' section below as well. - -And if you wish to add a human-readable moniker to your node: - -- `moniker = ""` - -Finally, if you plan on using [Cockpit](https://cockpit-project.org/documentation.html) on your server, change the `grpc` port from `9090` as this is the port used by Cockpit. - -### `app.toml` configuration -In the file `$HOME/.nyxd/config/app.toml`, set the following values: - -``` -# Mainnet -minimum-gas-prices = "0.025unym,0.025unyx" -``` - -``` -# Sandbox Testnet -minimum-gas-prices = "0.025unym,0.025unyx" -``` - -### Setting up your validator's admin user -You'll need an admin account to be in charge of your validator. Set that up with: - -``` -nyxd keys add nyxd-admin -``` - -```admonish tip title="Key Backends" -Cosmos SDK offers multiple backends for securing your keys. Please refer to the Cosmos SDK [docs on available keyring backends](https://docs.cosmos.network/main/user/run-node/keyring#available-backends-for-the-keyring) to learn more -``` - -While using the default settings, this will add keys for your account to your system's keychain and log your name, address, public key, and mnemonic. As the instructions say, remember to **write down your mnemonic**. - -You can get the current account address with: - -``` -nyxd keys show nyxd-admin -a -``` - -Type in your keychain **password**, not the mnemonic, when asked. - -## Starting your validator - -Everything should now be ready to go. You've got the validator set up, all changes made in `config.toml` and `app.toml`, the Nym genesis file copied into place (replacing the initial auto-generated one). Now let's validate the whole setup: - -``` -nyxd validate-genesis -``` - -If this check passes, you should receive the following output: - -``` -File at /path/to/genesis.json is a valid genesis file -``` - -> If this test did not pass, check that you have replaced the contents of `//.nyxd/config/genesis.json` with that of the correct genesis file. - -### Setting up nyxd as full node (non-signing) - -```admonish danger title="" -Skip this section if you're planning to run a validator node to join network consensus. To ensure security & maximum availability of validators, do not expose additional services to the Internet -``` - -Unlike signing validators, full nodes do not propose / sign blocks. A full node is typically used for indexing blocks produced on the chain and for exposing web interfaces such as RPC, API and gRPC endpoints required for external applications/services to interact with the blockchain. - -By default, API server is disabled and RPC/gRPC servers listen to the loopback address only. In a production setup, it is recommended to use a webserver such as Nginx or caddy to proxy requests to the endpoints as required. - -To enable Cosmos REST API, you can enable it in `$HOME/.nyxd/config/app.toml` like : - -``` -[api] - -# Enable defines if the API server should be enabled. Toggle this to `true` -enable = true - -# Swagger defines if swagger documentation should automatically be registered. -# You can also expose swagger documentation by toggling the below configuration to true -swagger = true -``` - -For more information on enabling access to various endpoints via Nginx, refer to the [example configuration here](./maintenance.md#setup) - -### Open firewall ports - -Before starting the validator, we will need to open the firewall ports: - -``` -# if ufw is not already installed: -sudo apt install ufw -sudo ufw enable - -# Customise according to your port bindings. This is only for reference -# 26656 : p2p gossip port -# 26660: If prometheus is enabled -# 22 : Default SSH port -sudo ufw allow 26656,26660,22 - -## !! FOR FULL NODES ONLY !! - exposing Nginx for serving web requests -sudo ufw allow 80,443 - -# to check everything worked -sudo ufw status -``` - -For more information about your validator's port configuration, check the [validator port reference table](./maintenance.md#ports) below. These can be customised in `app.toml` and `config.toml` files. - -> If you are planning to use [Cockpit](https://cockpit-project.org/) on your validator server then you will have defined a different `grpc` port in your `config.toml` above: remember to open this port as well. - -Start the validator: - -``` -nyxd start -``` - -Once your validator starts, it will start requesting blocks from other validators. This may take several hours. Once it's up to date, you can issue a request to join the validator set with the command below. - -### Syncing from a snapshot -If you wish to sync from a snapshot on **mainnet** use Polkachu's [mainnet](https://polkachu.com/networks/nym) resources. - -If you wish to sync from a snapshot on **Sandbox testnet** use the below commands, which are a modified version of Polkachu's excellent resources. These commands assume you are running an OS with `apt` as the package manager: - -``` -# install lz4 if necessary -sudo apt install snapd -y -sudo snap install lz4 - -# download the snapshot -wget -O nyxd-sandbox-snapshot-data.tar.lz4 https://rpc.sandbox.nymtech.net/snapshots/nyxd-sandbox-snapshot-data.tar.lz4 - -# reset your validator state -nyxd tendermint unsafe-reset-all - -# unpack the snapshot -lz4 -c -d nyxd-sandbox-snapshot-data.tar.lz4 | tar -x -C $HOME/.nyxd -``` - -You can then restart `nyxd` - it should start syncing from a block > 2000000. - -### Joining Consensus -```admonish info title="" -You can skip this section if you are planning to run a full-node. This step will make your node a signing validator which joins network consensus -``` - -Once your validator has synced and you have received tokens, you can join consensus and produce blocks. - -``` -# Mainnet -nyxd tx staking create-validator - --amount=<10000000unyx> - --pubkey=$(/home///nyxd/binaries/nyxd tendermint show-validator) - --moniker="" - --chain-id=nyx - --commission-rate="0.10" - --commission-max-rate="0.20" - --commission-max-change-rate="0.01" - --min-self-delegation="1" - --gas="auto" - --gas-adjustment=1.15 - --gas-prices=0.025unyx - --from=<"KEYRING_NAME"> - --node=https://rpc.nymtech.net:443 -``` -``` -# Sandbox Testnet -nyxd tx staking create-validator - --amount=<10000000unyx> - --pubkey=$(/home///nym/binaries/nyxd tendermint show-validator) - --moniker="" - --chain-id=sandbox - --commission-rate="0.10" - --commission-max-rate="0.20" - --commission-max-change-rate="0.01" - --min-self-delegation="1" - --gas="auto" - --gas-adjustment=1.15 - --gas-prices=0.025unyx - --from=<"KEYRING_NAME"> - --node https://rpc.sandbox.nymtech.net:443 -``` - -You'll need Nyx tokens on mainnet / sandbox to perform the above tasks. - - -If you want to edit some details for your node you will use a command like this: - -``` -# Mainnet -nyxd tx staking edit-validator - --chain-id=nyx - --moniker="" - --details="Nyx validator" - --security-contact="" - --identity="" - --gas="auto" - --gas-adjustment=1.15 - --gas-prices=0.025unyx - --from="KEYRING_NAME" -``` -``` -# Sandbox testnet -nyxd tx staking edit-validator - --chain-id=sandbox - --moniker="" - --details="Sandbox testnet validator" - --security-contact="your email" - --identity="" - --gas="auto" - --gas-adjustment=1.15 - --gas-prices=0.025unyx - --from="KEYRING_NAME" -``` - -With above command you can specify the `gpg` key last numbers (as used in `keybase`) as well as validator details and your email for security contact. - -### Automating your validator with systemd -You will most likely want to automate your validator restarting if your server reboots. Checkout the [maintenance page](./maintenance.md#systemd) with a quick tutorial. - -### Setting the ulimit - -Linux machines limit how many open files a user is allowed to have. This is called a `ulimit`. We need to set it to a higher value than the default 1024. Follow the instructions in the [maintenance page](./maintenance.md#Setting-the-ulimit) to change the `ulimit` value for validators. - -## Using your validator -### Un-jailing your validator -If your validator gets jailed, you can fix it with the following command: - -``` -# Mainnet -nyxd tx slashing unjail - --broadcast-mode=block - --from="KEYRING_NAME" - --chain-id=nyx - --gas=auto - --gas-adjustment=1.4 - --gas-prices=0.025unyx -``` -``` -# Sandbox Testnet -nyxd tx slashing unjail - --broadcast-mode=block - --from="KEYRING_NAME" - --chain-id=sandbox - --gas=auto - --gas-adjustment=1.4 - --gas-prices=0.025unyx -``` - -### Upgrading your validator - -To upgrade your validator, follow the steps on the [maintenance page](./maintenance.md#setting-the-ulimit). - -#### Common reasons for your validator being jailed - -Your validator will be jailed if your node: - - misses _`x`_ amount of blocks in _`y`_ interval, where _`x`_ and _`y`_ are parameters set by chain governance - - performs double signing (two conflicting signatures on the same block using the same key) - -Double signing is a serious infraction. If a node double signs, all the delegators to the node (including self-delegation) will be slashed by 5%. Additionally, the node will be permanently jailed and removed from consensus (called _tombstoning_) - -One of the most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs. - -Running the command `df -H` will return the size of the various partitions of your VPS. If the partition with blockchain data is almost full, try pruning the blockchain data or expanding the storage size. - -### Day 2 operations with your validator - -You can check your current balances with: - -``` -nyxd query bank balances ${ADDRESS} -``` - -For example, on the Sandbox testnet this would return: - -```yaml -balances: -- amount: "919376" -denom: unym -pagination: -next_key: null -total: "0" -``` - -You can, of course, stake back the available balance to your validator with the following command. - -> Remember to save some tokens for gas costs! - -``` -# Mainnet -nyxd tx staking delegate VALOPERADDRESS AMOUNTunyx - --from="KEYRING_NAME" - --keyring-backend=os - --chain-id=nyx - --gas="auto" - --gas-adjustment=1.15 - --gas-prices=0.025unyx - -# Sandbox Testnet -nyxd tx staking delegate VALOPERADDRESS AMOUNTunyx - --from="KEYRING_NAME" - --keyring-backend=os - --chain-id=sandbox - --gas="auto" - --gas-adjustment=1.15 - --gas-prices=0.025unyx -``` - diff --git a/documentation/old_docs/operators/src/nodes/vps-setup.md b/documentation/old_docs/operators/src/nodes/vps-setup.md deleted file mode 100644 index 6cbba86cdf..0000000000 --- a/documentation/old_docs/operators/src/nodes/vps-setup.md +++ /dev/null @@ -1,264 +0,0 @@ -# VPS Setup & Configuration - -We aim for Nym Mixnet to be reliable and quality base layer of privacy accross the globe, while growing as distributed as possible. It's essential to have a fine tuned machine as a foundation for the nodes to meet the requirements and be rewarded for their work. - -```admonish info -A suboptimally configured VPS often results in a non-functional node. To follow these steps carefully will save you time and money later on. -``` - -## VPS Hardware Specs - -You will need to rent a VPS to run your node on. One key reason for this is that your node **must be able to send TCP data using both IPv4 and IPv6** (as other nodes you talk to may use either protocol). - -Tor community created a very helpful table called [*Good Bad ISPs*](https://community.torproject.org/relay/community-resources/good-bad-isps/), you can use that one as a guideline for your choice of ISP for your VPS. - -**Update:** Nym community started an ISP table called [*Where to host your nym node?*](../legal/isp-list.md), check it out and add your findings! - -### `nym-node` - -Before we conclude the testing with exact results, these are the rough specs: - -| **Hardware** | **Minimum Specification** w -| :--- | ---: | -| CPU Cores | 4 | -| Memory | 4 GB RAM | -| Storage | 40 GB | -| Connectivity | IPv4, IPv6, TCP/IP, UDP | -| Bandwidth | 1Tb | -| Port speed | 1Gbps | - -### Nyx validator - -The specification mentioned below is for running a full node alongside the nym-api. It is recommended to run `nym-api` and a full Nyx node on the same machine for optimum performance. - -Bear in mind that credential signing is primarily CPU-bound, so choose the fastest CPU available to you. - -#### Minimum Requirements - -| Hardware | **Minimum Specification** | -|----------|--------------------------------------------| -| CPU | 8-cores, 2.8GHz base clock speed or higher | -| RAM | 16GB DDR4+ | -| Disk | 500 GiB+ NVMe SSD | - -#### Recommended Requirements - -| Hardware | **Minimum Specification** | -|----------|---------------------------------------------| -| CPU | 16-cores, 2.8GHz base clock speed or higher | -| RAM | 32GB DDR4+ | -| Disk | 1 TiB+ NVMe SSD | - - -#### Full node configuration (validator) - -To install a full node from scratch, refer to the [validator setup guide](validator-setup.md) and follow the steps outlined there. - -## VPS Configuration - -Before node or validator setup, the VPS needs to be configured and tested, to verify your connectivity and make sure that your provider wasn't dishonest with the offered services. - -```admonish info -The commands listed in this chapter must be executed with a prefix `sudo` or from a root shell. -``` - -### Install Dependencies - -SSH to your server as `root` or become one running `sudo -i` or `su`. If you prefer to administrate your VPS from a user environment, supply the commands with prefix `sudo`. - -Start with setting up the essential tools on your server. -```sh -# get your system up to date -apt update -y && apt --fix-broken install - -# install dependencies -apt -y install ca-certificates jq curl wget ufw jq tmux pkg-config build-essential libssl-dev git - -# double check ufw is installed correctly -apt install ufw --fix-missing -``` - -### Configure your Firewall - -For a `nym-node` or Nyx validator to recieve traffic, you need to open ports on the server. The following commands will allow you to set up a firewall using `ufw`. - -1. Check `ufw`: -```sh -# check if you have ufw installed -ufw version - -# if it is not installed, install with -apt install ufw -y - -# enable ufw -ufw enable - -# check the status of the firewall -ufw status -``` - -2. Open all needed ports to have your firewall for `nym-node` working correctly: -```sh -ufw allow 22/tcp # SSH - you're in control of these ports -ufw allow 80/tcp # HTTP -ufw allow 443/tcp # HTTPS -ufw allow 1789/tcp # Nym specific -ufw allow 1790/tcp # Nym specific -ufw allow 8080/tcp # Nym specific - nym-node-api -ufw allow 9000/tcp # Nym Specific - clients port -ufw allow 9001/tcp # Nym specific - wss port -ufw allow 51822/udp # WireGuard -``` - -- In case of reverse proxy setup add: -```sh -ufw allow 443/tcp -``` - -- For validator setup open these ports: -```sh -ufw allow 1317,26656,26660,22,80,443/tcp -``` - -3. Check the status of the firewall: -```sh -ufw status -``` - -For more information about your node's port configuration, check the [port reference table](#ports-reference-table) below. - -## Setting the ulimit - -Linux machines limit how many open files a user is allowed to have. This is called a `ulimit`. - -`ulimit` is 1024 by default on most systems. It needs to be set higher, because Nym Nodes make and receive a lot of connections with each others. - -If you see errors such as: - -```sh -Failed to accept incoming connection - Os { code: 24, kind: Other, message: "Too many open files" } -``` - -This means that the operating system is preventing network connections from being made. - -### Set the `ulimit` via `systemd` service file - -> **Replace `` variable with the name of your service, for example `nym-node`** as we migrated from `nym-mixnode`, `nym-gateway` and `nym-network-requester`. - -The ulimit setup is relevant for maintenance of Nym Node only. - -Query the `ulimit` of your `` with: - -```sh -# for nym-node -grep -i "open files" /proc/$(ps -A -o pid,cmd|grep | grep -v grep |head -n 1 | awk '{print $1}')/limits - -# for nyx validator -grep -i "open files" /proc/$(ps -A -o pid,cmd|grep nymd | grep -v grep |head -n 1 | awk '{print $1}')/limits -``` - -You'll get back the hard and soft limits, which looks something like this: - -```sh -Max open files 65536 65536 files -``` - -If your output is **the same as above**, your node will not encounter any `ulimit` related issues. - -However if either value is `1024`, you must raise the limit via the systemd service file. Add the line: - -```sh -LimitNOFILE=65536 -``` - -Reload the daemon: - -```sh -systemctl daemon-reload -``` - -or execute this as root for system-wide setting of `ulimit`: - -```sh -echo "DefaultLimitNOFILE=65535" >> /etc/systemd/system.conf -``` - -Reboot your server, and restart your node. When it comes back, use: -```sh -# for nym-node -cat /proc/$(pidof )/limits | grep "Max open files" - -# for validator -cat /proc/$(pidof nym-validator)/limits | grep "Max open files" -``` -Make sure the limit has changed to `65535`. - -### Set the ulimit on `non-systemd` based distributions - -In case you chose tmux option for Nym Node automation, see your `ulimit` list by running: - -```sh -ulimit -a - -# watch for the output line -n --n: file descriptors 1024 -``` - -You can change it either by running a command: - -```sh -ulimit -u -n 4096 -``` - -or editing `etc/security/conf` and add the following lines: - -```sh -# Example hard limit for max opened files -username hard nofile 4096 - -# Example soft limit for max opened files -username soft nofile 4096 -``` - -Then reboot your server and restart your node. - - -## Ports reference tables - -All node-specific port configuration can be found in `$HOME/.nym///config/config.toml`. If you do edit any port configs, remember to restart your client and node processes. - -### Nym node port reference - -#### Mix Node functionality ports - -| Default port | Use | -| ------------ | ------------------------- | -| `1789` | Listen for Mixnet traffic | -| `1790` | Listen for VerLoc traffic | -| `8080` | Metrics http API endpoint | - -#### Gateway functionality ports - -| Default port | Use | -|-----------------|-------------------------------| -| `1789` | Listen for Mixnet traffic | -| `9000` | Listen for Client traffic | -| `9001` | WSS | -| `8080, 80, 443` | Reversed Proxy & Swagger page | -|`51822/udp` | WireGuard | - -#### Embedded Network Requester functionality ports - -| Default port | Use | -|--------------|---------------------------| -| `9000` | Listen for Client traffic | - -### Validator port reference - -All validator-specific port configuration can be found in `$HOME/.nymd/config/config.toml`. If you do edit any port configs, remember to restart your validator. - -| Default port | Use | -|--------------|--------------------------------------| -| `1317` | REST API server endpoint | -| `26656` | Listen for incoming peer connections | -| `26660` | Listen for Prometheus connections | diff --git a/documentation/old_docs/operators/src/nodes/wallet-preparation.md b/documentation/old_docs/operators/src/nodes/wallet-preparation.md deleted file mode 100644 index e89cebc3f9..0000000000 --- a/documentation/old_docs/operators/src/nodes/wallet-preparation.md +++ /dev/null @@ -1,17 +0,0 @@ -# Nym Wallet Preparation - -## Mainnet - -Head to our [website](https://nymtech.net/download/) and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren't available, you can build the wallet yourself with instructions [here](https://nymtech.net/docs/wallet/desktop-wallet.html). - -If you don't already have one, please create a Nym address using the wallet, and fund it with NYM tokens. The minimum amount required to bond a node is 100 `NYM`, but make sure you have a bit more to account for gas costs. - -`NYM` can be purchased via Bity from the wallet itself with BTC or fiat, and is currently present on several [exchanges](https://www.coingecko.com/en/coins/nym#markets). - -> Remember that you can **only** use Cosmos `NYM` tokens to bond your node. You **cannot** use ERC20 representations of `NYM` to run a node. - - -## Sandbox testnet - -Make sure to download a wallet and create an account as outlined above. Then head to our [Operators Element channel](https://matrix.to/#/#operators:nymtech.chat) and request testnet tokens. - diff --git a/documentation/old_docs/operators/src/not-found.md b/documentation/old_docs/operators/src/not-found.md deleted file mode 100644 index aafb70cba5..0000000000 --- a/documentation/old_docs/operators/src/not-found.md +++ /dev/null @@ -1,11 +0,0 @@ -# Page Not Found - -You seem to have followed a link to a page that no longer exists. Our documentation is changing and growing over time, so this page has most likely been moved somewhere else. - -For node setup guides, see the [Operator Guides book](https://nymtech.net/operators). - -For developer tutorials, app guides, and demo and community apps, see the [Developer Portal](https://nymtech.net/developers). - -If you are looking for information on setting up and maintaining infrastructure nodes, check the sitemap on the left hand side of the screen. - -If you still can't find what you're looking for get in touch with us via [Matrix](https://matrix.to/#/#nym-community:nymtech.chat). \ No newline at end of file diff --git a/documentation/old_docs/operators/src/release-cycle.md b/documentation/old_docs/operators/src/release-cycle.md deleted file mode 100644 index 0556bcbbbe..0000000000 --- a/documentation/old_docs/operators/src/release-cycle.md +++ /dev/null @@ -1,91 +0,0 @@ -# Release Cycle - -The Nym operator community is growing in quality and quantity. With node operators and developers joining the effort to make the Mixnet more robust and scalable, testing new features, sharing integration pull requests and generally taking an active part in Nym development, more transparency on the release cycle is required. - -The core team therefore established a flow with different environments: - -- ***local***: Developers use their local environments for feature building -- ***canary***: Nym internal testing environment managed by Qualty Assurance team (QA) -- [***sandbox***](sandbox.md): Public testnet, including testnet NYM token available in the [faucet](sandbox.md#sandbox-token-faucet) -- ***mainnet***: Nym Mixnet - the production version of Nym network - -## Release Flow - -Frequency of releases to mainnet is aimed to be every ~14 days. This time window is an optimal compromise between periodicity and quality assurance/testing, key factors playing an essential role in development. - -| **Stage** | **Environment** | **Branch** | **Ownership** | -| :-- | :-- | :-- | :-- | -| development work | local/canary | feature branches | devs | -| cut and test release | canary | release branch | QA | -| bug fixing | canary | directly on release branch | QA & devs | -| put release on sandbox | sandbox | release -> master/develop | QA | -| promote release to mainnet after 3-5 days | mainnet | master | QA | - -```ascii - ▲ ▲ - │ │ - │ merge back into develop │ - MAINNET ├─────────────────────────►│ - easy │ │ - autopromotion│ │ - ▲ │ │ - │ │ │ - │ │ │◄───────────────────────────────┐ - │ │ │ │ - └───release │ │ │ - to x◄───────────────┐ │ │ - sandbox ▲ │ │◄────────────────────────┐ │ - │ ┌────────────► │ │ │ - │ │ │ │ │ │ - │ │ bug │ │ │ │ - │ │ fix │ │◄─────────────────┐ │ │ - │ │ │ │ │ │ │ - │ │ │ │ M │ │ │ - │ └────────────┤ │ I │ │ │ - │ │ │ L │ │ │ - │ └─────────x E │ │ │ - │ release ▲ S │ │ │ - ^ │ cut │ T │ │ │ - : │ --- │ O │ │ │ - : │ fixed │ N │ │ │ - : │ release │ E │ │ │ - : │ every │ feature-bob3 │ │ │ - : │ 14 days ├──────────────────┘ │ │ - : │ │ │ │ - : │ │ │ │ - : │ │ feature-bob2 │ │ - : │ ├─────────────────────────┘ │ - : │ │ │ - : │ │ │ - : │ │ feature-bob1 │ - : │ ├────────────────────────────────┘ - : │ │ - : │ │ - :t │ │ - :i │ │ - :m │ │ - :e │ │ - - master develop feature branches - -ENVs -┌─────────┬────────┬──────────────────────────┬─────────────────────────────────┐ -│mainnet │sandbox │ QA / canary │ development │ -│ │ │ │ │ -└─────────┴────────┴──────────────────────────┴─────────────────────────────────┘ -``` - -### Changes & Collaboration - -To track changes easily, builders and operators can visit one of the following: - -- [*CHANGELOG.md*](https://github.com/nymtech/nym/blob/master/CHANGELOG.md): Raw changelog of the merged feauters in Nym's monorepo, managed by devs and QA. -- [*Changelog page*](changelog.md): A copy of *CHANGELOG.md* with more detailed explanation, testing steps and updated summary of documentation changes, managed by devrels. - -In case you want to propose changes or resolve some of the existing [issues](https://github.com/nymtech/nym/issues), start [here](https://github.com/nymtech/nym/issues/new/choose). If you want to add content to the Operators Guide, visit [this page](legal/add-content.md). - -```admonish tip -Feature tickets need explicit (while concise) wording because that title is eventually added to the changelog. Keep in mind that bad ticket naming results in bad changelog. - -If you want to run in the testing environment, follow our [Sandbox testnet](sandbox.md) guide. -``` diff --git a/documentation/old_docs/operators/src/sandbox.md b/documentation/old_docs/operators/src/sandbox.md deleted file mode 100644 index dee07d0245..0000000000 --- a/documentation/old_docs/operators/src/sandbox.md +++ /dev/null @@ -1,55 +0,0 @@ -# Sandbox Testnet - -Nym node operators can run their nodes in Nym Sandbox testnet environment. Whether it's testing new configuration, hot features from Nym developers or just trying to setup a node for the first time, this environment is for you. - -Below are steps to [setup your environment](#sandbox-environment-setup) and an introduction to [Sandbox token faucet](#sandbox-token-faucet). - -```admonish warning title="" -This page is for Nym node operators. If you want to run NymVPN CLI over Sandbox testnet, visit our [developers portal](https://nymtech.net/developers/nymvpn/cli.html#testnet-environment). -``` - -## Sandbox Environment Setup - -> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets. - -To run Nym binaries in Sandbox testnet, you need to get `sandbox.env` configuration file and point your binary to it. Follow the steps below: - -1. Create Sandbox environment config file by saving [this](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) as `sandbox.env` in the same directory as your binaries: -```sh -curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env - -# In case you want to save the file elswhere, change the path in '-o' flag -``` - -2. Run your `nym-node` with an additional flag `-c` or `--config-env-file` with a path to `sandbox.env` file followed by all needed commands and options. For example: -```sh -# this example is for nym-node in mixnode mode -./nym-node --config-env-file sandbox.env run --mode mixnode - -# this example is for nym-node in exit-gateway mode -./nym-node --config-file-env sandbox.env run --mode exit-gateway --id --public-ips "$(curl -4 https://ifconfig.me)" --hostname "" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 true --location - -# In case you downloaded sandbox.env to the same directory, is not needed -``` - -3. Bond your node to Nym Sandbox environment: - - Open [Nym Wallet](https://nymtech.net/download/wallet) and switch to testnet - - Go to [faucet.nymtech.net](https://faucet.nymtech.net) and aquire 101 testnet NYM tokens - - Follow the steps on the [bonding page](nodes/bonding.md) - -![](images/sandbox.png) - -~~~admonish tip -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 -export NYMNODE_CONFIG_ENV_FILE_ARG= -``` -~~~ - -## Sandbox Token Faucet - -To run your nodes in Sandbox environment, you need testnet version of NYM token, that can be aquired from [faucet.nymtech.net](https://faucet.nymtech.net). - -To prevent abuse, the faucet is rate-limited - your request will fail if the requesting wallet already has 101 NYM tokens. diff --git a/documentation/old_docs/operators/src/scripts/nyx-percent-stake.sh b/documentation/old_docs/operators/src/scripts/nyx-percent-stake.sh deleted file mode 100755 index 89b85f929c..0000000000 --- a/documentation/old_docs/operators/src/scripts/nyx-percent-stake.sh +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/bash - -stake_unyx=$(curl -s -L https://api.nymtech.net/cosmos/staking/v1beta1/pool | jq 'values["pool"]["bonded_tokens"]') -stake_unyx=$(python -c "print(int($stake_unyx))") -stake_nyx=$(python -c "print($stake_unyx / 1000000)") -voting288k_percent=$(python -c "print(288000 / $stake_nyx * 100)") -echo ${voting288k_percent:0:4}% diff --git a/documentation/old_docs/operators/src/scripts/nyx-total-stake.sh b/documentation/old_docs/operators/src/scripts/nyx-total-stake.sh deleted file mode 100755 index 1f000428cf..0000000000 --- a/documentation/old_docs/operators/src/scripts/nyx-total-stake.sh +++ /dev/null @@ -1,4 +0,0 @@ -#!/bin/bash - -stake=$(curl -s -L https://api.nymtech.net/cosmos/staking/v1beta1/pool | jq 'values["pool"]["bonded_tokens"]') -echo ${stake:1:2}.${stake:3:3} diff --git a/documentation/old_docs/operators/src/toc.md b/documentation/old_docs/operators/src/toc.md deleted file mode 100644 index 3dc2d6d689..0000000000 --- a/documentation/old_docs/operators/src/toc.md +++ /dev/null @@ -1,9 +0,0 @@ -# Terms and Conditions - -With `nym-node` version `1.1.3`, NymTech SA introduced [**Operators Terms & Conditions**]({{toc_page}}) for operators who want their nodes to become a part of the active set of Nym Mixnet. - -There has been a long ongoing discussion whether and how to apply Terms and Conditions for Nym network operators, with an aim to stay aligned with the philosophy of Free Software and provide legal defense for both node operators and Nym developers. To understand better the reasoning behind this decision, you can listen to the first [Nym Operator Town Hall](https://www.youtube.com/live/7hwb8bAZIuc?si=3mQ2ed7AyUA1SsCp&t=915) introducing the T&Cs or to [Operator AMA with CEO Harry Halpin](https://www.youtube.com/watch?v=yIN-zYQw0I0) from June 4th, 2024, explaining pros and cons of T&Cs implementation. - -Accepting T&Cs is done via an explicit flag `--accept-operator-terms-and-conditions` added to `nym-node run` command. - -More information on how to setup your node or check whether any node has T&C accepted can be found in [`nym-node` setup guide](nodes/setup.md#terms--conditions). diff --git a/documentation/old_docs/operators/src/tokenomics/mixnet-rewards.md b/documentation/old_docs/operators/src/tokenomics/mixnet-rewards.md deleted file mode 100644 index f0856b6757..0000000000 --- a/documentation/old_docs/operators/src/tokenomics/mixnet-rewards.md +++ /dev/null @@ -1,46 +0,0 @@ - - - - -### Mix Node Reward Estimation API endpoint - -The Reward Estimation API endpoint allows Mix Node operators to estimate the rewards they could earn for running a Nym Mix Node with a specific `MIX_ID`. - -> The `` can be found in the "Mix ID" column of the [Network Explorer](https://explorer.nymtech.net/network-components/mixnodes/active). - -The endpoint is a particularly common for Mix Node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the Mix Node, the quality of the Mix Node's performance, and the overall demand for Mix Nodes in the network. This information can be useful for Mix Node operators in deciding whether or not to run a Mix Node and in optimizing its operations for maximum profitability. - -Using this API endpoint returns information about the Reward Estimation: - -```sh -/status/mixnode//reward-estimation -``` - -Query Response: - -```sh - "estimation": { - "total_node_reward": "942035.916721770541325331", - "operator": "161666.263307386408152071", - "delegates": "780369.65341438413317326", - "operating_cost": "54444.444444444444444443" - }, -``` - -> The unit of value is measured in `uNYM`. - -- `estimated_total_node_reward` - An estimate of the total amount of rewards that a particular Mix Node can expect to receive during the current epoch. This value is calculated by the Nym Validator based on a number of factors, including the current state of the network, the number of Mix Nodes currently active in the network, and the amount of network traffic being processed by the Mix Node. - -- `estimated_operator_reward` - An estimate of the amount of rewards that a particular Mix Node operator can expect to receive. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the operator's stake in the network. - -- `estimated_delegators_reward` - An estimate of the amount of rewards that Mix Node delegators can expect to receive individually. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the delegator's stake in the network. - -- `estimated_node_profit` - An estimate of the profit that a particular Mix node operator can expect to earn. This value is calculated by subtracting the Mix Node operator's `operating_costs` from their `estimated_operator_reward` for the current epoch. - -- `estimated_operator_cost` - An estimate of the total cost that a particular Mix Node operator can expect to incur for their participation. This value is calculated by the Nym Validator based on a number of factors, including the cost of running a Mix Node, such as server hosting fees, and other expenses associated with operating the Mix Node. - -### Validator: Installing and configuring nginx for HTTPS -#### Setup -[Nginx](https://www.nginx.com/resources/glossary/nginx) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security. - -Install `nginx` and allow the 'Nginx Full' rule in your firewall: diff --git a/documentation/old_docs/operators/src/tokenomics/validator-rewards.md b/documentation/old_docs/operators/src/tokenomics/validator-rewards.md deleted file mode 100644 index f4b1210704..0000000000 --- a/documentation/old_docs/operators/src/tokenomics/validator-rewards.md +++ /dev/null @@ -1,55 +0,0 @@ -# Nyx Validator Rewards - -## Summary - -* Nyx Validators are rewarded in NYM tokens from the Nym mixmining pool and increasingly from apps that run on the Nym mixnet, the first of which is the NymVPN. -* Validators are rewarded for two different types of work: signing blocks in the Nyx chain and running the NymAPI to monitor mixnet routing and sign zk-nym credentials. -* New validators can join via a NYM-to-NYX swap contract. The contract will not allow more than 1% of total stake increase per month to prevent sudden hostile takeovers. Current stake is million Nyx. Rate: 1:4.8 ~ 288k NYX for 60k NYM => voting power -* NYX tokens serve no other purpose than self-delegation for voting power and governance. All rewards are in NYM and distributed directly to the validators self-delegation address and are not distributed to stakers. -* The contract will only allow swapping NYM to NYX and will **not** allow exchanging NYX back to NYM. A NYX holder who wishes to sell their NYX stake will have to do so via OTC trades. - -## Validator Rewards - -Nyx Validators perform two types of work for which they will be rewarded: - -### 1. Signing blocks in the Nyx chain - -A “block signing monitor" monitors blocks being produced on the Nyx chain and gathers the signatures present on every block. After an epoch ends, the monitor will assess performance of a validator and distribute tokens (to the self-delegation wallet) proportional to the voting period and uptime of the validator. - -### 2. Running the NymAPI to monitor Mixnet routing and sign zk-nyms (Nym’s anonymous credentials) - -Validator rewards initially come from the Nym mixmining pool with additional rewards increasingly coming from paid applications running on the Nym mixnet. The first paid application is the NymVPN. Nyx validators will be rewarded for their work directly in NYM tokens to their validator self-delegation address. - -1. **From mixmining pool** - at a rate of 1000 NYM per hour, of which 2/3 are distributed for signing blocks and 1/3 for zk-nyms. These are stable in NYM, and therefore will fluctuate in their fiat value depending on exchange rate. - -2. **From vpn user subscriptions** - the rate is tied to the growth of NymVPN subscriptions and will be stable in fiat, fluctuating in NYM depending on exchange rate. 1/3 will be distributed for signing blocks and 2/3 for zk-nyms. - -| Source | Signing blocks | Running NymAPI | Currency | -| :-- | --: | --: | :---: | -| Mixmining pool | 2/3 | 1/3 | NYM | -| NymVPN | 1/3 | 2/3 | fiat | - -#### zk-nyms - -The zk-nyms enable people to anonymously prove access rights to the upcoming NymVPN client without having to reveal payment details that might compromise their privacy. This is the first of what we imagine to be many possible use-cases for the zk-nym scheme. - -### Allocation of Rewards from Nym mixmining pool - -Rewards for validators will be distributed at an hourly rate from the mixmining pool. The amount is 1000 NYM per hour to be distributed among all validators. The fraction of mixmining rewards received by each individual validator is proportional to its contributions to the network. - -Two thirds of the available rewards (670 NYM per hour) are distributed proportionally to each validator’s share when signing blocks in the chain, for which tx fees are also received in the same proportion; while the last third (330 NYM per hour) is allocated to validators running the NymAPI, proportionally to their contribution to signing zk-nym credentials. - -The rewards are stable in NYM and fluctuate in their fiat value depending on the exchange rate of NYM tokens. - -## Permissionless Nyx Chain - -To allow new validators to join Nyx chain a new smart contract will be set up to release NYX in exchange for NYM. This contract allows a limited amount of NYM tokens to be deposited per month. The deposited NYM tokens are added to the mixmining pool and thus contribute to future rewards of all nodes and validators. - -The smart contract will have two parameters: - -1. the maximum amount of NYX available for purchase per month -2. the NYM-to-NYX exchange rate offered by the contract - -### Maximum Amount of NYX Available for Purchase per Month - -The contract will not allow more than 1% of total stake increase per month to prevent sudden hostile takeovers. Current stake level is million Nyx. diff --git a/documentation/old_docs/operators/src/troubleshooting/nodes.md b/documentation/old_docs/operators/src/troubleshooting/nodes.md deleted file mode 100644 index 3d1fa42d3d..0000000000 --- a/documentation/old_docs/operators/src/troubleshooting/nodes.md +++ /dev/null @@ -1,421 +0,0 @@ -# Nym Node Troubleshooting - -## Binary Build Problems - -### I am trying to build from the GitHub archive files and the build fails - -GitHub automatically includes .zip and tar.gz files of the Nym repository in its release. You cannot extract these and build - you'll see something like this: - -``` - process didn't exit successfully: `/build/nym/src/nym-0.12.1/target/release/build/nym-socks5-client-c1d0f76a8c7d7e9a/build-script-build` (exit status: 101) - --- stderr - thread 'main' panicked at 'failed to extract build metadata: could not find repository from '/build/nym/src/nym-0.12.1/clients/socks5'; class=Repository (6); code=NotFound (-3)', clients/socks5/build.rs:7:31 - note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace -warning: build failed, waiting for other jobs to finish... -error: build failed -``` - -Why does this happen? - -We have scripts which automatically include the Git commit hash and Git tag in the binary for easier debugging later. If you download a .zip and try building from that, it's not a Git repository and build will fail as above. - -What to do? - -* Open terminal in the directory where you want to have a git repository -* To get Nym repository for the first time, run: -``` -git clone https://github.com/nymtech/nym.git -``` -* Follow the instructions to build the platform -* To upgrade, pause your nodes, in the same terminal window run `git pull`, follow the upgrade instructions and re-start your nodes. - -## General Node Config - -### Where can I find my private and public keys and config? - -All config and keys files are stored in a directory named after your `id` which you chose during the `init` process, and can be found at the following PATH: `$HOME/.nym//` where `$HOME` is a home directory of the user (your current user in this case) that launched the node or client. - -The directory structure for each node will be roughly as follows: - -``` -bob@desktop:~/nym/target/release# tree ~/.nym/nym-nodes/ -~/.nym/nym-nodes/ -└── default-nym-node - ├── config - │   └── config.toml - └── data - ├── aes128ctr_ipr_ack - ├── aes128ctr_nr_ack - ├── clients.sqlite - ├── cosmos_mnemonic - ├── description.toml - ├── ed25519_identity - ├── ed25519_identity.pub - ├── ed25519_ipr_identity - ├── ed25519_ipr_identity.pub - ├── ed25519_nr_identity - ├── ed25519_nr_identity.pub - ├── ipr_gateways_info_store.sqlite - ├── nr_gateways_info_store.sqlite - ├── nr_persistent_reply_store.sqlite - ├── x25519_ipr_dh - ├── x25519_ipr_dh.pub - ├── x25519_noise - ├── x25519_noise.pub - ├── x25519_nr_dh - ├── x25519_nr_dh.pub - ├── x25519_sphinx - └── x25519_sphinx.pub -``` - -> If you `cat` the `public_sphinx.pem` key, the output will be different from the public key you will see on Nym [dashboard](https://sandbox-explorer.nymtech.net/). The reason for this is that `.pem` files are encoded in **base64**, however on the web they are in **base58**. Don't be confused if your keys look different. They are the same keys, just with different encoding :) - - -## Mixnode Mode - -### How can I tell my node is up and running and mixing traffic? - -First of all check the 'Mixnodes' section of either of the Nym Network Explorers: -* [Mainnet](https://explorer.nymtech.net/) -* [Sandbox testnet](https://sandbox-explorer.nymtech.net/) - -Enter your **identity key** to find your node. Check the contents of the `Mixnode stats` and `Routing score` sections. - -There are 2 community explorers currently, which have been created by [Nodes Guru](https://nodes.guru): -* [Mainnet](https://mixnet.explorers.guru/) -* [Sandbox testnet](https://sandbox.mixnet.explorers.guru/) - -You can run [Node API Check CLI](../testing/node-api-check.md) to query all API endpoints of your node at once. - -[Here](https://github.com/cosmos/chain-registry/blob/master/nyx/chain.json#L158-L187) is a dictionary with Nyx chain registry entry regarding all explorers. - -If you want more information, or if your node isn't showing up on the explorer of your choice and you want to double-check, here are some examples on how to check if the node is configured properly. - -#### Check from your VPS - -Additional details can be obtained via various methods after you connect to your VPS: - -##### Socket statistics with `ss` - -``` -sudo ss -s -t | grep 1789 # if you have specified a different port in your Mix Node config, change accordingly -``` - -This command should return a lot of data containing `ESTAB`. This command should work on every unix based system. - -##### List open files and reliant processes with `lsof` - -``` -# check if lsof is installed: -lsof -v -# install if not installed -sudo apt install lsof -# run against nym-mix-node node port -sudo lsof -i TCP:1789 # if you have specified a different port in your mixnode config, change accordingly -``` - -This command should return something like this: - -``` -nym-node 103349 root 53u IPv6 1333229972 0t0 TCP [2a03:b0c0:3:d0::ff3:f001]:57844->[2a01:4f9:c011:38ae::5]:1789 (ESTABLISHED) -nym-node 103349 root 54u IPv4 1333229973 0t0 TCP nym:57104->194.5.78.73:1789 (ESTABLISHED) -nym-node 103349 root 55u IPv4 1333229974 0t0 TCP nym:48130->static.236.109.119.168.clients.your-server.de:1789 (ESTABLISHED) -nym-node 103349 root 56u IPv4 1333229975 0t0 TCP nym:52548->vmi572614.contaboserver.net:1789 (ESTABLISHED) -nym-node 103349 root 57u IPv6 1333229976 0t0 TCP [2a03:b0c0:3:d0::ff3:f001]:43244->[2600:1f18:1031:2401:c04b:2f25:ca79:fef3]:1789 (ESTABLISHED) -``` - -##### Query `systemd` journal with `journalctl` - -```sh -sudo journalctl -u nym-node -o cat | grep "Since startup mixed" -``` - -If you have created `nym-node.service` file (i.e. you are running your Ny, Node via `systemd`) then this command shows you how many packets have you mixed so far, and should return a list of messages like this: - -```sh -2021-05-18T12:35:24.057Z INFO nym_node::node::metrics > Since startup mixed 233639 packets! -2021-05-18T12:38:02.178Z INFO nym_node::node::metrics > Since startup mixed 233739 packets! -2021-05-18T12:40:32.344Z INFO nym_node::node::metrics > Since startup mixed 233837 packets! -2021-05-18T12:46:08.549Z INFO nym_node::node::metrics > Since startup mixed 234081 packets! -2021-05-18T12:56:57.129Z INFO nym_node::node::metrics > Since startup mixed 234491 packets! -``` - -You can add ` | tail` to the end of the command to watch for new entries in real time if needed. - -##### 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. - -For example `./target/debug/nym-node --no-banner build-info --output json` will return: - -```sh -{"binary_name":"nym-network-requester","build_timestamp":"2023-07-24T15:38:37.00657Z","build_version":"1.1.23","commit_sha":"c70149400206dce24cf20babb1e64f22202672dd","commit_timestamp":"2023-07-24T14:45:45Z","commit_branch":"feature/simplify-cli-parsing","rustc_version":"1.71.0","rustc_channel":"stable","cargo_profile":"debug"} -``` - -#### Check from your local machine - -##### Scan ports with `nmap`: - -```sh -nmap -p 1789 -Pn -``` - -If your Nym Node is configured properly it should output something like this: - -```sh -bob@desktop:~$ nmap -p 1789 95.296.134.220 -Pn - -Host is up (0.053s latency). - -PORT STATE SERVICE -1789/tcp open hello -``` - -##### Check with `telnet` - -Your node should connect to telnet when running: -```sh -telnet -``` - -##### Query online nodes: - -```sh -curl --location --request GET 'https://validator.nymtech.net/api/v1/mixnodes/' -``` - -Will return a list all nodes currently online. - -You can query Gateways by replacing `nym-mixnodes` with `nym-gateways` in the above command, and can query for the Mix Nodes and Gateways on the Sandbox testnet by replacing `validator` with `sandbox-validator`. - - -#### Check with Network API - -We currently have an API set up returning our metrics tests of the network. There are two endpoints to ping for information about your Mix Node, `report` and `history`. Find more information about this in the [Mixnodes metrics documentation](../nodes/maintenance.md#metrics--api-endpoints). - -For more information about available endpoints and their status, you can refer to: -```sh -# for http -http://:8080/api/v1/swagger/#/ - -# for https reversed proxy -https:///api/v1/swagger/#/ -``` - -### Why is my node not mixing any packets? - -If you are still unable to see your node on the dashboard, or your node is declaring it has not mixed any packets, there are several potential issues: - -- The firewall on your host machine is not configured properly. Checkout the [instructions](../nodes/vps-setup.md#configure-your-firewall). -- You provided incorrect information when bonding your node. -- You are running your node from a VPS without IPv6 support. -- You did not configure your router firewall while running the node from your local machine behind NAT, or you are lacking IPv6 support -- Your Mix Node is not running at all, it has either exited / panicked or you closed the session without making the node persistent. Check out the [instructions](../nodes/configuration.md#automating-your-node-with-tmux-and-systemd). - -```admonish caution title="" -Your Nym Node **must speak both IPv4 and IPv6** in order to cooperate with other nodes and route traffic. This is a common reason behind many errors we are seeing among node operators, so check with your provider that your VPS is able to do this! -``` - -#### Check IPv6 Connectivity - -You can always check IPv6 address and connectivity by using some of these methods: - -```sh -# locally listed IPv6 addresses -ip -6 addr - -# globally reachable IPv6 addresses -ip -6 addr show scope global - -# with DNS -dig -6 TXT +short o-o.myaddr.l.google.com @ns1.google.com -dig -t aaaa +short myip.opendns.com @resolver1.opendns.com - -# https check -curl -6 https://ifconfig.co -curl -6 https://ipv6.icanhazip.com - -# using telnet -telnet -6 ipv6.telnetmyip.com -``` -If your connection doesn't work make sure to follow [VPS IPv6 setup](../nodes/configuration.md#connectivity-test-and-configuration). If there is more troubleshooting needed, check out [VPS IPv6 troubleshooting](vps-isp.md#ipv6-troubleshooting) page. - - -#### Incorrect bonding information - -Check that you have provided the correct information when bonding your Nym Node in the web wallet interface. When in doubt, un-bond and then re-bond your node! - -> All delegated stake will be lost when un-bonding! However the Nym Node must be operational in the first place for the delegation to have any effect. - -### Running on a local machine behind NAT with no fixed IP address - -Your ISP has to be IPv6 ready if you want to run a Nym Node on your local machine. Sadly, in 2020, most of them are not and you won't get an IPv6 address by default from your ISP. Usually it is an extra paid service or they simply don't offer it. - -Before you begin, check if you have IPv6 [here](https://test-ipv6.cz/) or by running command explained in the [section above](#no-ipv6-connectivity). If not, then don't waste your time to run a node which won't ever be able to mix any packet due to this limitation. Call your ISP and ask for IPv6, there is a plenty of it for everyone! - -If all goes well and you have IPv6 available, then you will need to `init` the Nym Node with an extra flag, `--announce-host`. You will also need to edit your `config.toml` file each time your IPv4 address changes, that could be a few days or a few weeks. Check the your IPv4 in the [section above](#no-ipv6-connectivity). - -Additional configuration on your router might also be needed to allow traffic in and out to port 1789 and IPv6 support. - - -- `--host 0.0.0.0` should work every time even if your local machine IPv4 address changes. For example on Monday your router gives your machine an address `192.168.0.13` and on Wednesday, the [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) lease will end and you will be assigned `192.168.0.14`. Using `0.0.0.0` should avoid this without having to set any static IP in your router's configuration. - -- you can get your current IPv4 address by either using `curl ipinfo.io` if you're on MacOS or Linux or visiting [whatsmyip site](https://www.whatsmyip.org/). Simply copy it and use it as `--anounce-host` address. - -Make sure you check if your node is really mixing. We are aiming to improve the setup for operators running locally, however you may need a bit of patience to set this up from your home behind NAT. - -### Accidentally killing your node process on exiting session - -When you close your current terminal session, you need to make sure you don't kill the Mix Node process! There are multiple ways on how to make it persistent even after exiting your ssh session, the easiest solution is to use `tmux` or `nohup`, and the more elegant solution is to run the node with `systemd`. Read the automation manual [here](../nodes/configuration.md#automating-your-node-with-tmux-and-systemd). - -### Common errors and warnings - -Most of the `ERROR` and `WARN` messages in your node logs are benign - as long as your node outputs `since startup mixed X packets!` (`X` bust be > 0) in your logs (and this number increases over time), your node is mixing packets. If you want to be sure, check the Nym [dashboard](https://sandbox-explorer.nymtech.net/) or see other ways on how to check if your node is mixing properly as outlined in the section [**How can I tell my node is up and running and mixing traffic?**](#how-can-i-tell-my-node-is-up-and-running-and-mixing-traffic?) above. - -More specific errors and warnings are covered below. - - -### What is `verloc` and do I have to configure my Nym Node to implement it? - -`verloc` is short for _verifiable location_. Mix Nodes and Gateways now measure speed-of-light distances to each other, in an attempt to verify how far apart they are. In later releases, this will allow us to algorithmically verify node locations in a non-fake-able and trustworthy manner. - -You don't have to do any additional configuration for your node to implement this, it is a passive process that runs in the background of the mixnet from version `0.10.1` onward. - -## Gateways Mode - -### My `exit-gateway` is running but appears offline in the explorer - -Let your Gateway run and follow these steps: - -1. Check if your [firewall configuration](../nodes/vps-setup.md#configure-your-firewall) is active and if the necessary ports are open / allowed, including the ones for Swagger page and Reversed proxy/WSS if this is your case. -2. See if the Gateway is not on the [list of blacklisted Gateways](https://validator.nymtech.net/api/v1/gateways/blacklisted) -3. If it's blacklisted, check out the [point below](#my-gateway-is-blacklisted) - -### My Gateway is blacklisted - -Nym API measures performance by routing traffic through the Mixnet. If the average of a Gateway's routing score in past 24h is less than 50%, the Gateway gets blacklisted and it remains so until its performance is higher than 50%. - -In case your Gateway appeared on the [blacklist](https://validator.nymtech.net/api/v1/gateways/blacklisted), it's because there is some flaw in the configuration. The most common sources of problems are: - -- Outdated version of `nym-node` -- Bonding before starting the node/service -- Bonding before opening [needed ports](../nodes/vps-setup.md#configure-your-firewall) -- VPS restarted without operator having a [systemd automation](../nodes/configuration.md#systemd) or some alert notification flow setup (so the operator doesn't know the node was stopped) -- IP address or host is incorrectly configured -- Process logs grew too big -- Node is wrapped in [systemd service](../nodes/configuration.md#systemd) and the operator forgot to run `systemctl daemon-reload` after last changes - -**What to do** - -Begin with a sanity check by opening [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net) and check your node there. To query all API endpoints of your node at once, you can run [Node API Check CLI](../testing/node-api-check.md). To see IPv4 and IPv6 routing in real time (harbourmaster can have a cache up to 90 min), run [Gateway Probe CLI](../testing/gateway-probe.md). - -Then follow these steps: - -1. Make sure your node is on the [latest version](../changelog.md) and it's running . Do *not* stop it if there is no need! -2. Open all [needed ports](../nodes/vps-setup.md#configure-your-firewall) -3. Check your `config.toml` - often people have filled `hostname` without the domain being registered to `nym-node` IP, or a wrong IP address after moving their node. -4. [Check Gateway Connectivity](#check-gateway-connectivity) -5. See logs of your Gateway and search [for errors](#nym-node-errors) - if you find any unusual one, you can ask in the [Element Node Operators](https://matrix.to/#/#operators:nymtech.chat) channel - - If your logs show that your Node has `cover down: 0.00` that means that the embedded IPR and NR is not sending any cover traffic. -6. [Check out if your `syslog`s](vps-isp.md#pruning-logs) aren't eating all your disk space and prune them -7. When all problems are addressed: Restart the node/service (don't forget `systemctl daemon-reload`) and wait until your node gets above 50% of performance (average of last 24h) - this will likely take 24-48 hours. During this time your node is tested by `nym-api` and every positive response picks up your routing score. -8. If your node doesn't pick up the routing score within 24h at all and it was running in `--mode exit-gateway`, run it as `--mode entry-gateway`. When your node is above 75% performance (past 24h), switch back to `--mode exit-gateway`. - -**Do not repeatedly restart your Nym Node without reason, your routing score will only get worse!** - -### Check Gateway connectivity - -**1. Check out the API endpoints** - -Start with checking if your Gateway IPR and NR is active. To determine which mode your node is running, you can check the `:8080/api/v1/roles` endpoint. For example: -```sh -# sustitude or with a real one -# for http -http://:8080/api/v1/roles -# or -http:///api/v1/roles - -# for reversed proxy/WSS -https:///api/v1/roles -``` - -Everything necessary will exist on your node by default. For instance, if you're running a mixnode, you'll find that a NR (Network Requester) and IPR (IP Packet Router) address exist, but they will be ignored in `mixnode` mode. - -For more information about available endpoints and their status, you can refer to: -```sh -# sustitude or with a real one -# for http -http://:8080/api/v1/swagger/#/ -# or -http:///api/v1/swagger/#/ - -# for reversed proxy/WSS -https:///api/v1/swagger/#/ -``` - - -**2. Configure IPv4 and IPv6 tables and rules** - -- In case you haven't, follow the steps in the node [configuration](../nodes/configuration.md) chapter [connectivity test and configurastion](../nodes/configuration.md#connectivity-test-and-configuration). - - -**3. Test connectivity** - -- Telnet - from your local machine try to connect to your VPS bu running: - -```sh -telnet -``` - -- [Websocket wcat](https://github.com/websockets/wscat): - - Install on your local machine: -```sh -sudo apt install node-ws -``` - - Run `wscat` pointing to the IP of your VPS with port `9000`: -``` -wscat -c ws://: -``` - -### My exit Gateway "is still not online..." - -The Nyx chain epoch takes up to 60 min. To prevent the Gateway getting blacklisted, it's essential to start it before the bonding process and let it running. In case it already got [blacklisted](#my-gateway-is-backlisted) check the steps above. - - diff --git a/documentation/old_docs/operators/src/troubleshooting/validators.md b/documentation/old_docs/operators/src/troubleshooting/validators.md deleted file mode 100644 index f0fedf8f80..0000000000 --- a/documentation/old_docs/operators/src/troubleshooting/validators.md +++ /dev/null @@ -1,16 +0,0 @@ -# Validators Troubleshooting - -### Common reasons for your validator being jailed - -The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs. - -Running the command `df -H` will return the size of the various partitions of your VPS. - -If the `/dev/sda` partition is almost full, try pruning some of the `.gz` syslog archives and restart your validator process. - - -## Where can I get more help? - -The fastest way to reach one of us or get a help from the community, visit our [Telegram Node Setup Help Chat](https://t.me/nymchan_help_chat) or head to our [Discord](https://nymtech.net/go/discord). - -For more tech heavy question join our [Matrix core community channel](https://matrix.to/#/#general:nymtech.chat), where you can meet other builders and Nym core team members. diff --git a/documentation/old_docs/operators/src/troubleshooting/vps-isp.md b/documentation/old_docs/operators/src/troubleshooting/vps-isp.md deleted file mode 100644 index a7c8ce212b..0000000000 --- a/documentation/old_docs/operators/src/troubleshooting/vps-isp.md +++ /dev/null @@ -1,131 +0,0 @@ -# Troubleshooting VPS Setup - -```admonish info -To monitor the connectivity of your Exit Gateway, use results of probe testing displayed in [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net). -``` - -## IPv6 troubleshooting - -### Incorrect Gateway Network Check - -Nym operators community is working on a Nym version of tors [good bad ISP table](https://community.torproject.org/relay/community-resources/good-bad-isps/). There is no one solution fits all when it comes to connectivity setup. The operation of `nym-node` will vary depending on your ISP and chosen system/distribution. While few machines will work out of the box, most will work after uisng our connectivity configuration guide, some need more adjustments. - -Begin with the steps listed in [*Connectivity Test and Configuration*](../nodes/vps-setup.md#connectivity-test-and-configuration) chapter of VPS Setup page. If you still have a problem with the IPv6 connectivity try: - -1. Tor community created a helpful [table of ISPs](https://community.torproject.org/relay/community-resources/good-bad-isps/). Make sure your one is listed there as a *"good ISP"*. If not, consider migrating! -2. Checkout your VPS dashboard and make sure your IPv6-public enabled. -3. If you are able to add IPv6 address `/64` range, do it. - -**Update:** Nym community started an ISP table called [*Where to host your nym node?*](../legal/isp-list.md), check it out and add your findings! - -![](../images/ipv6_64.png) - -4. Search or ask your ISP for additional documentation related to IPv6 routing and ask them to provide you with `IPv6 IP address` and `IPv6 IP gateway address` -- For example Digital Ocean setup isn't the most straight forward, but it's [well documented](https://docs.digitalocean.com/products/networking/ipv6/how-to/enable/#on-existing-droplets) and it works. - -5. Search for guides regarding your particular system and distribution. For Debian based distributions using systemd, some generic guides such as [this one](https://cloudzy.com/blog/configure-ipv6-on-ubuntu/) or [this one](https://help.ovhcloud.com/csm/en-ie-vps-configuring-ipv6?id=kb_article_view&sysparm_article=KB0047567) work as well. - -### Network configuration - -On modern Debian based Linux distributions, the network is configured by either [Netplan](https://netplan.io/) or [ifup/ifdown](https://manpages.debian.org/testing/ifupdown/ifup.8.en.html) utilities . It is very easy to check which one you have. - -1. If you have the following folder `/etc/netplan` which has got a YAML file - you are likely to have Netplan. -2. If you have the following folder `/etc/network` and it is not empty - you are likely to have ifup/down. - -Most contemporary Ubuntu/Debian distributions come with Netplan, however it is possible that your hosting provider is using a custom version of ISO. For example, Debian 12 (latest version as of June 2024) may come with ifup/down. - -Nym operator community members have tested a VPS with Netplan and where in some cases `nym-node --mode exit-gateway` was not routing IP packets properly even after running `network_tunnel_manager.sh` script. We are working on a guide to setup Netplan configuration manually for such cases. - -Configuration of ifup/ifdown is a bit simpler. If the `network_tunnel_manager.sh` script doesn't do the job, open `/etc/network/interfaces` file (research if your system uses a different naming for it) and configure it similarly to this: - -```sh -auto lo -iface lo inet loopback - -auto eth0 -iface eth0 inet static -address -netmask NETMASK - -gateway -iface eth0 inet6 static - accept_ra 0 - address - netmask 64 - gateway -post-up /sbin/ip -r route add dev eth0 -post-up /sbin/ip -r route add default via -``` -Last two lines are particularly important as they enable IPv6 routing. You can find YOUR_IPV6_GATEWAY using your server's control panel. There is no single way to find the gateway, so please access your control panel to find yours or open a support ticket. Here is an example of how it looks on [OVH](https://help.ovhcloud.com/csm/en-ie-vps-configuring-ipv6?id=kb_article_view&sysparm_article=KB0047567). - -```admonish warning title="WARNING" -Be extra careful editing this file since you may lock yourself out of the server. If it happens, you can always access the server via the hoster's VNC panel. -``` - -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](../nodes/configuration.md#ipv6-configuration). - -## Other VPS troubleshooting - -### Virtual IPs and hosting via Google & AWS - -For true internet decentralization we encourage operators to use diverse VPS providers instead of the largest companies offering such services. If for some reasons you have already running AWS or Google and want to setup a `` there, please read the following. - -On some services (AWS, Google, etc) the machine's available bind address is not the same as the public IP address. In this case, bind `--host` to the local machine address returned by `$(curl -4 https://ifconfig.me)`, but that may not the public IP address to bond your `` in the wallet. - -You can run `ifconfig` command. For example, on a Google machine, you may see the following output: - -```sh -ens4: flags=4163 mtu 1460 - inet 10.126.5.7 netmask 255.255.255.255 broadcast 0.0.0.0 - ... -``` - -The `ens4` interface has the IP `10.126.5.7`. But this isn't the public IP of the machine, it's the IP of the machine on Google's internal network. Google uses virtual routing, so the public IP of this machine is something else, maybe `36.68.243.18`. - -To find the right IP configuration, contact your VPS provider for support to find the right public IP and use it to bond your `` with the `nym-api` via Nym wallet. - -On self-hosted machine it's a bit more tricky. In that case as an operator you must be sure that your ISP allows for public IPv4 and IPv6 and then it may be a bit of playing around to find the right configuration. One way may be to bind your binary with the `--host` flag to local address `127.0.0.1` and run `echo "$(curl -4 https://ifconfig.me)"` to get a public address which you use to bond your Mix Node to `nym-api` via Nym wallet. - -It's up to you as a node operator to ensure that your public and private IPs match up properly. - -### Pruning Logs - -Running a `nym-node` as a standalone process or wrapped in a service can produce gigabytes of logs. Eventually your operation can malfunction due to the logs chewing up too much disk space or memory. Below are two scripts that can help you clean this up. - -```admonish warning -`rm` is a powerful tool, without an easy way of revoking. If you need to extract or backup anything, do it now. Make sure you understand what you removing before you execute these commands. -``` - -```sh -# I WANT TO SEE WHATS EATING ALL MY DISKSPACE -sudo find /var -type f -printf "%s\t%p\n" | sort -n -r | head -n 20 | ls -lh -sudo find /var -type f -exec ls -lh {} + 2>/dev/null | sort -k 5 -n -r | head -n 20 - -sudo du -h --max-depth=1 /var -sudo du -h /var/log - -#PRUNE THOSE LOGS -sudo rm -f /var/log/syslog.1 -sudo rm -f /var/log/syslog -journalctl --disk-usage -sudo journalctl --vacuum-time=3d -sudo journalctl --vacuum-size=50M - -#ENFORCE LOG ROTATION -sudo logrotate --force /etc/logrotate.conf -sudo service rsyslog restart - -# REMOVE ALL THOSE OLD PACKAGES... -sudo apt-get clean -sudo apt-get autoremove - -sudo apt-get clean -sudo rm -rf /var/lib/apt/lists/* -sudo apt-get update - -for snap in $(sudo snap list --all | awk '/disabled/{print $1, $3}'); do - sudo snap remove $snap -done -``` diff --git a/documentation/old_docs/operators/themes/css/chrome.css b/documentation/old_docs/operators/themes/css/chrome.css deleted file mode 100644 index e16262342c..0000000000 --- a/documentation/old_docs/operators/themes/css/chrome.css +++ /dev/null @@ -1,608 +0,0 @@ -/* CSS for UI elements (a.k.a. chrome) */ - -@import 'variables.css'; - -html { - scrollbar-color: var(--scrollbar) var(--bg); -} -#searchresults a, -.content a:link, -a:visited, -a > .hljs { - color: var(--links); -} - -/* - body-container is necessary because mobile browsers don't seem to like - overflow-x on the body tag when there is a tag. -*/ -#body-container { - /* - This is used when the sidebar pushes the body content off the side of - the screen on small screens. Without it, dragging on mobile Safari - will want to reposition the viewport in a weird way. - */ - overflow-x: clip; -} - -/* Menu Bar */ - -#menu-bar, -#menu-bar-hover-placeholder { - z-index: 101; - margin: auto calc(0px - var(--page-padding)); -} -#menu-bar { - position: relative; - display: flex; - flex-wrap: wrap; - background-color: var(--bg); - border-block-end-color: var(--bg); - border-block-end-width: 1px; - border-block-end-style: solid; -} -#menu-bar.sticky, -.js #menu-bar-hover-placeholder:hover + #menu-bar, -.js #menu-bar:hover, -.js.sidebar-visible #menu-bar { - position: -webkit-sticky; - position: sticky; - top: 0 !important; -} -#menu-bar-hover-placeholder { - position: sticky; - position: -webkit-sticky; - top: 0; - height: var(--menu-bar-height); -} -#menu-bar.bordered { - border-block-end-color: var(--table-border-color); -} -#menu-bar i, #menu-bar .icon-button { - position: relative; - padding: 0 8px; - z-index: 10; - line-height: var(--menu-bar-height); - cursor: pointer; - transition: color 0.5s; -} -@media only screen and (max-width: 420px) { - #menu-bar i, #menu-bar .icon-button { - padding: 0 5px; - } -} - -.icon-button { - border: none; - background: none; - padding: 0; - color: inherit; -} -.icon-button i { - margin: 0; -} - -.right-buttons { - margin: 0 15px; -} -.right-buttons a { - text-decoration: none; -} - -.left-buttons { - display: flex; - margin: 0 5px; -} -.no-js .left-buttons button { - display: none; -} - -.menu-title { - position: absolute; - left: 50%; - display: inline-block; - font-weight: 200; - font-size: 2.4rem; - line-height: var(--menu-bar-height); - text-align: center; - margin: 0; - flex: 1; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; -} -.js .menu-title { - cursor: pointer; -} - -.menu-bar, -.menu-bar:visited, -.nav-chapters, -.nav-chapters:visited, -.mobile-nav-chapters, -.mobile-nav-chapters:visited, -.menu-bar .icon-button, -.menu-bar a i { - color: var(--icons); -} - -.menu-bar i:hover, -.menu-bar .icon-button:hover, -.nav-chapters:hover, -.mobile-nav-chapters i:hover { - color: var(--icons-hover); -} - -/* Nav Icons */ - -.nav-chapters { - font-size: 2.5em; - text-align: center; - text-decoration: none; - - position: fixed; - top: 0; - bottom: 0; - margin: 0; - max-width: auto; - min-width: auto; - - display: flex; - justify-content: center; - align-content: center; - flex-direction: column; - - transition: color 0.5s, background-color 0.5s; -} - -.nav-chapters:hover { - text-decoration: none; - background-color: var(--theme-hover); - transition: background-color 0.15s, color 0.15s; -} - -.nav-wrapper { - margin-block-start: 50px; - display: none; -} - -.mobile-nav-chapters { - font-size: 2.5em; - text-align: center; - text-decoration: none; - width: 90px; - border-radius: 5px; - background-color: var(--sidebar-bg); -} - -/* Only Firefox supports flow-relative values */ -.previous { float: left; } -[dir=rtl] .previous { float: right; } - -/* Only Firefox supports flow-relative values */ -.next { - float: right; - right: var(--page-padding); -} -[dir=rtl] .next { - float: left; - right: unset; - left: var(--page-padding); -} - -/* Use the correct buttons for RTL layouts*/ -[dir=rtl] .previous i.fa-angle-left:before {content:"\f105";} -[dir=rtl] .next i.fa-angle-right:before { content:"\f104"; } - -@media only screen and (max-width: 1080px) { - .nav-wide-wrapper { display: none; } - .nav-wrapper { display: block; } -} - -/* sidebar-visible */ -@media only screen and (max-width: 1380px) { - #sidebar-toggle-anchor:checked ~ .page-wrapper .nav-wide-wrapper { display: none; } - #sidebar-toggle-anchor:checked ~ .page-wrapper .nav-wrapper { display: block; } -} - -/* Inline code */ - -:not(pre) > .hljs { - display: inline; - padding: 0.1em 0.3em; - border-radius: 3px; -} - -:not(pre):not(a) > .hljs { - color: var(--inline-code-color); - overflow-x: initial; -} - -a:hover > .hljs { - text-decoration: underline; -} - -pre { - position: relative; -} -pre > .buttons { - position: absolute; - z-index: 100; - right: 0px; - top: 2px; - margin: 0px; - padding: 2px 0px; - - color: var(--sidebar-fg); - cursor: pointer; - visibility: hidden; - opacity: 0; - transition: visibility 0.1s linear, opacity 0.1s linear; -} -pre:hover > .buttons { - visibility: visible; - opacity: 1 -} -pre > .buttons :hover { - color: var(--sidebar-active); - border-color: var(--icons-hover); - background-color: var(--theme-hover); -} -pre > .buttons i { - margin-inline-start: 8px; -} -pre > .buttons button { - cursor: inherit; - margin: 0px 5px; - padding: 3px 5px; - font-size: 14px; - - border-style: solid; - border-width: 1px; - border-radius: 4px; - border-color: var(--icons); - background-color: var(--theme-popup-bg); - transition: 100ms; - transition-property: color,border-color,background-color; - color: var(--icons); -} -@media (pointer: coarse) { - pre > .buttons button { - /* On mobile, make it easier to tap buttons. */ - padding: 0.3rem 1rem; - } - - .sidebar-resize-indicator { - /* Hide resize indicator on devices with limited accuracy */ - display: none; - } -} -pre > code { - display: block; - padding: 1rem; -} - -/* FIXME: ACE editors overlap their buttons because ACE does absolute - positioning within the code block which breaks padding. The only solution I - can think of is to move the padding to the outer pre tag (or insert a div - wrapper), but that would require fixing a whole bunch of CSS rules. -*/ -.hljs.ace_editor { - padding: 0rem 0rem; -} - -pre > .result { - margin-block-start: 10px; -} - -/* Search */ - -#searchresults a { - text-decoration: none; -} - -mark { - border-radius: 2px; - padding-block-start: 0; - padding-block-end: 1px; - padding-inline-start: 3px; - padding-inline-end: 3px; - margin-block-start: 0; - margin-block-end: -1px; - margin-inline-start: -3px; - margin-inline-end: -3px; - background-color: var(--search-mark-bg); - transition: background-color 300ms linear; - cursor: pointer; -} - -mark.fade-out { - background-color: rgba(0,0,0,0) !important; - cursor: auto; -} - -.searchbar-outer { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); -} - -#searchbar { - width: 100%; - margin-block-start: 5px; - margin-block-end: 0; - margin-inline-start: auto; - margin-inline-end: auto; - padding: 10px 16px; - transition: box-shadow 300ms ease-in-out; - border: 1px solid var(--searchbar-border-color); - border-radius: 3px; - background-color: var(--searchbar-bg); - color: var(--searchbar-fg); -} -#searchbar:focus, -#searchbar.active { - box-shadow: 0 0 3px var(--searchbar-shadow-color); -} - -.searchresults-header { - font-weight: bold; - font-size: 1em; - padding-block-start: 18px; - padding-block-end: 0; - padding-inline-start: 5px; - padding-inline-end: 0; - color: var(--searchresults-header-fg); -} - -.searchresults-outer { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); - border-block-end: 1px dashed var(--searchresults-border-color); -} - -ul#searchresults { - list-style: none; - padding-inline-start: 20px; -} -ul#searchresults li { - margin: 10px 0px; - padding: 2px; - border-radius: 2px; -} -ul#searchresults li.focus { - background-color: var(--searchresults-li-bg); -} -ul#searchresults span.teaser { - display: block; - clear: both; - margin-block-start: 5px; - margin-block-end: 0; - margin-inline-start: 20px; - margin-inline-end: 0; - font-size: 0.8em; -} -ul#searchresults span.teaser em { - font-weight: bold; - font-style: normal; -} - -/* Sidebar */ - -.sidebar { - position: fixed; - left: 0; - top: 0; - bottom: 0; - width: var(--sidebar-width); - font-size: 1em; - box-sizing: border-box; - -webkit-overflow-scrolling: touch; - overscroll-behavior-y: contain; - background-color: var(--sidebar-bg); - color: var(--sidebar-fg); -} -[dir=rtl] .sidebar { left: unset; right: 0; } -.sidebar-resizing { - -moz-user-select: none; - -webkit-user-select: none; - -ms-user-select: none; - user-select: none; -} -.no-js .sidebar, -.js:not(.sidebar-resizing) .sidebar { - transition: transform 0.3s; /* Animation: slide away */ -} -.sidebar code { - line-height: 2em; -} -.sidebar .sidebar-scrollbox { - overflow-y: auto; - position: absolute; - top: 0; - bottom: 0; - left: 0; - right: 0; - padding: 10px 10px; -} -.sidebar .sidebar-resize-handle { - position: absolute; - cursor: col-resize; - width: 0; - right: calc(var(--sidebar-resize-indicator-width) * -1); - top: 0; - bottom: 0; - display: flex; - align-items: center; -} - -.sidebar-resize-handle .sidebar-resize-indicator { - width: 100%; - height: 12px; - background-color: var(--icons); - margin-inline-start: var(--sidebar-resize-indicator-space); -} - -[dir=rtl] .sidebar .sidebar-resize-handle { - left: calc(var(--sidebar-resize-indicator-width) * -1); - right: unset; -} -.js .sidebar .sidebar-resize-handle { - cursor: col-resize; - width: calc(var(--sidebar-resize-indicator-width) - var(--sidebar-resize-indicator-space)); -} -/* sidebar-hidden */ -#sidebar-toggle-anchor:not(:checked) ~ .sidebar { - transform: translateX(calc(0px - var(--sidebar-width) - var(--sidebar-resize-indicator-width))); - z-index: -1; -} -[dir=rtl] #sidebar-toggle-anchor:not(:checked) ~ .sidebar { - transform: translateX(calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width))); -} -.sidebar::-webkit-scrollbar { - background: var(--sidebar-bg); -} -.sidebar::-webkit-scrollbar-thumb { - background: var(--scrollbar); -} - -/* sidebar-visible */ -#sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: translateX(calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width))); -} -[dir=rtl] #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: translateX(calc(0px - var(--sidebar-width) - var(--sidebar-resize-indicator-width))); -} -@media only screen and (min-width: 620px) { - #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: none; - margin-inline-start: calc(var(--sidebar-width) + var(--sidebar-resize-indicator-width)); - } - [dir=rtl] #sidebar-toggle-anchor:checked ~ .page-wrapper { - transform: none; - } -} - -.chapter { - list-style: none outside none; - padding-inline-start: 0; - line-height: 2em; -} - -.chapter ol { - width: 100%; -} - -.chapter li { - display: flex; - color: var(--sidebar-non-existant); -} -.chapter li a { - display: block; - padding: 0; - text-decoration: none; - color: var(--sidebar-fg); -} - -.chapter li a:hover { - color: var(--sidebar-active); -} - -.chapter li a.active { - color: var(--sidebar-active); -} - -.chapter li > a.toggle { - cursor: pointer; - display: block; - margin-inline-start: auto; - padding: 0 10px; - user-select: none; - opacity: 0.68; -} - -.chapter li > a.toggle div { - transition: transform 0.5s; -} - -/* collapse the section */ -.chapter li:not(.expanded) + li > ol { - display: none; -} - -.chapter li.chapter-item { - line-height: 1.5em; - margin-block-start: 0.6em; -} - -.chapter li.expanded > a.toggle div { - transform: rotate(90deg); -} - -.spacer { - width: 100%; - height: 3px; - margin: 5px 0px; -} -.chapter .spacer { - background-color: var(--sidebar-spacer); -} - -@media (-moz-touch-enabled: 1), (pointer: coarse) { - .chapter li a { padding: 5px 0; } - .spacer { margin: 10px 0; } -} - -.section { - list-style: none outside none; - padding-inline-start: 20px; - line-height: 1.5em; -} - -/* Theme Menu Popup */ - -.theme-popup { - position: absolute; - left: 10px; - top: var(--menu-bar-height); - z-index: 1000; - border-radius: 4px; - font-size: 0.7em; - color: var(--fg); - background: var(--theme-popup-bg); - border: 1px solid var(--theme-popup-border); - margin: 0; - padding: 0; - list-style: none; - display: none; - /* Don't let the children's background extend past the rounded corners. */ - overflow: hidden; -} -[dir=rtl] .theme-popup { left: unset; right: 10px; } -.theme-popup .default { - color: var(--icons); -} -.theme-popup .theme { - width: 100%; - border: 0; - margin: 0; - padding: 2px 20px; - line-height: 25px; - white-space: nowrap; - text-align: start; - cursor: pointer; - color: inherit; - background: inherit; - font-size: inherit; -} -.theme-popup .theme:hover { - background-color: var(--theme-hover); -} - -.theme-selected::before { - display: inline-block; - content: "✓"; - margin-inline-start: -14px; - width: 14px; -} diff --git a/documentation/old_docs/operators/themes/css/general.css b/documentation/old_docs/operators/themes/css/general.css deleted file mode 100644 index df8c1d12d2..0000000000 --- a/documentation/old_docs/operators/themes/css/general.css +++ /dev/null @@ -1,234 +0,0 @@ -/* Base styles and content styles */ - -@import 'variables.css'; - -:root { - /* Browser default font-size is 16px, this way 1 rem = 10px */ - font-size: 70%; - color-scheme: var(--color-scheme); -} - -html { - font-family: "Open Sans", sans-serif; - color: var(--fg); - background-color: var(--bg); - text-size-adjust: none; - -webkit-text-size-adjust: none; -} - -body { - margin: 0; - font-size: 1.5rem; - overflow-x: hidden; -} - -code { - font-family: var(--mono-font) !important; - font-size: 0.9em; - direction: ltr !important; -} - -/* make long words/inline code not x overflow */ -main { - overflow-wrap: break-word; -} - -/* make wide tables scroll if they overflow */ -.table-wrapper { - overflow-x: auto; -} - -/* Don't change font size in headers. */ -h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { - font-size: unset; -} - -.left { float: left; } -.right { float: right; } -.boring { opacity: 0.6; } -.hide-boring .boring { display: none; } -.hidden { display: none !important; } - -h2, h3 { margin-block-start: 2.5em; } -h4, h5 { margin-block-start: 2em; } - -.header + .header h3, -.header + .header h4, -.header + .header h5 { - margin-block-start: 1em; -} - -h1:target::before, -h2:target::before, -h3:target::before, -h4:target::before, -h5:target::before, -h6:target::before { - display: inline-block; - content: "»"; - margin-inline-start: -30px; - width: 30px; -} - -/* This is broken on Safari as of version 14, but is fixed - in Safari Technology Preview 117 which I think will be Safari 14.2. - https://bugs.webkit.org/show_bug.cgi?id=218076 -*/ -:target { - /* Safari does not support logical properties */ - scroll-margin-top: calc(var(--menu-bar-height) + 0.5em); -} - -.page { - outline: 0; - padding: 0 var(--page-padding); - margin-block-start: calc(0px - var(--menu-bar-height)); /* Compensate for the #menu-bar-hover-placeholder */ -} -.page-wrapper { - box-sizing: border-box; - background-color: var(--bg); -} -.no-js .page-wrapper, -.js:not(.sidebar-resizing) .page-wrapper { - transition: margin-left 0.3s ease, transform 0.3s ease; /* Animation: slide away */ -} -[dir=rtl] .js:not(.sidebar-resizing) .page-wrapper { - transition: margin-right 0.3s ease, transform 0.3s ease; /* Animation: slide away */ -} - -.content { - overflow-y: auto; - padding: 0 10px; -} -.content main { - margin-inline-start: auto; - margin-inline-end: auto; - max-width: var(--content-max-width); -} -.content p { line-height: 1.45em; } -.content ol { line-height: 1.45em; } -.content ul { line-height: 1.45em; } -.content a { text-decoration: none; } -.content a:hover { text-decoration: underline; } -.content img, .content video { max-width: 100%; } -.content .header:link, -.content .header:visited { - color: var(--fg); -} -.content .header:link, -.content .header:visited:hover { - text-decoration: none; -} - -table { - margin: 0 auto; - border-collapse: collapse; -} -table td { - padding: 3px 20px; - border: 1px var(--table-border-color) solid; -} -table thead { - background: var(--table-header-bg); -} -table thead td { - font-weight: 700; - border: none; -} -table thead th { - padding: 3px 20px; -} -table thead tr { - border: 1px var(--table-header-bg) solid; -} -/* Alternate background colors for rows */ -table tbody tr:nth-child(2n) { - background: var(--table-alternate-bg); -} - - -blockquote { - margin: 20px 0; - padding: 0 20px; - color: var(--fg); - background-color: var(--quote-bg); - border-block-start: .1em solid var(--quote-border); - border-block-end: .1em solid var(--quote-border); -} - -.warning { - margin: 20px; - padding: 0 20px; - border-inline-start: 2px solid var(--warning-border); -} - -.warning:before { - position: absolute; - width: 3rem; - height: 3rem; - margin-inline-start: calc(-1.5rem - 21px); - content: "ⓘ"; - text-align: center; - background-color: var(--bg); - color: var(--warning-border); - font-weight: bold; - font-size: 2rem; -} - -blockquote .warning:before { - background-color: var(--quote-bg); -} - -kbd { - background-color: var(--table-border-color); - border-radius: 4px; - border: solid 1px var(--theme-popup-border); - box-shadow: inset 0 -1px 0 var(--theme-hover); - display: inline-block; - font-size: var(--code-font-size); - font-family: var(--mono-font); - line-height: 10px; - padding: 4px 5px; - vertical-align: middle; -} - -:not(.footnote-definition) + .footnote-definition, -.footnote-definition + :not(.footnote-definition) { - margin-block-start: 2em; -} -.footnote-definition { - font-size: 0.9em; - margin: 0.5em 0; -} -.footnote-definition p { - display: inline; -} - -.tooltiptext { - position: absolute; - visibility: hidden; - color: #fff; - background-color: #333; - transform: translateX(-50%); /* Center by moving tooltip 50% of its width left */ - left: -8px; /* Half of the width of the icon */ - top: -35px; - font-size: 0.8em; - text-align: center; - border-radius: 6px; - padding: 5px 8px; - margin: 5px; - z-index: 1000; -} -.tooltipped .tooltiptext { - visibility: visible; -} - -.chapter li.part-title { - color: var(--sidebar-fg); - margin: 5px 0px; - font-weight: bold; -} - -.result-no-output { - font-style: italic; -} diff --git a/documentation/old_docs/operators/themes/css/variables.css b/documentation/old_docs/operators/themes/css/variables.css deleted file mode 100644 index 51b94cfc5a..0000000000 --- a/documentation/old_docs/operators/themes/css/variables.css +++ /dev/null @@ -1,287 +0,0 @@ - -/* Globals */ - -:root { - --sidebar-width: 280px; - --sidebar-resize-indicator-width: 8px; - --sidebar-resize-indicator-space: 2px; - --page-padding: 15px; - --content-max-width: 80%; - --menu-bar-height: 40px; - --mono-font: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace; - --code-font-size: 0.875em /* please adjust the ace font size accordingly in editor.js */ - --pagetoc-width: 13%; - --pagetoc-fontsize: 14.5px; -} - -@media only screen and (max-width:1439px) { - :root{ - --content-max-width: 98%; - } -} - -/* Themes */ - -.ayu { - --bg: hsl(210, 25%, 8%); - --fg: #c5c5c5; - - --sidebar-bg: #14191f; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #5c6773; - --sidebar-active: #ffb454; - --sidebar-spacer: #2d334f; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #b7b9cc; - - --links: #0096cf; - - --inline-code-color: #ffb454; - - --theme-popup-bg: #14191f; - --theme-popup-border: #5c6773; - --theme-hover: #191f26; - - --quote-bg: hsl(226, 15%, 17%); - --quote-border: hsl(226, 15%, 22%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(210, 25%, 13%); - --table-header-bg: hsl(210, 25%, 28%); - --table-alternate-bg: hsl(210, 25%, 11%); - - --searchbar-border-color: #848484; - --searchbar-bg: #424242; - --searchbar-fg: #fff; - --searchbar-shadow-color: #d4c89f; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #252932; - --search-mark-bg: #e3b171; - - --color-scheme: dark; -} - -.coal { - --bg: hsl(200, 7%, 8%); - --fg: #98a3ad; - - --sidebar-bg: #292c2f; - --sidebar-fg: #a1adb8; - --sidebar-non-existant: #505254; - --sidebar-active: #3473ad; - --sidebar-spacer: #393939; - - --scrollbar: var(--sidebar-fg); - - --icons: #43484d; - --icons-hover: #b3c0cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #141617; - --theme-popup-border: #43484d; - --theme-hover: #1f2124; - - --quote-bg: hsl(234, 21%, 18%); - --quote-border: hsl(234, 21%, 23%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(200, 7%, 13%); - --table-header-bg: hsl(200, 7%, 28%); - --table-alternate-bg: hsl(200, 7%, 11%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #b7b7b7; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #98a3ad; - --searchresults-li-bg: #2b2b2f; - --search-mark-bg: #355c7d; - - --color-scheme: dark; -} - -.light { - --bg: hsl(0, 0%, 100%); - --fg: hsl(0, 0%, 0%); - - --sidebar-bg: #fafafa; - --sidebar-fg: hsl(0, 0%, 0%); - --sidebar-non-existant: #aaaaaa; - --sidebar-active: #1f1fff; - --sidebar-spacer: #f4f4f4; - - --scrollbar: #8F8F8F; - - --icons: #747474; - --icons-hover: #000000; - - --links: #1f1fff; - - --inline-code-color: #F42C4C; - - --theme-popup-bg: #fafafa; - --theme-popup-border: #cccccc; - --theme-hover: #e6e6e6; - - --quote-bg: hsl(197, 37%, 96%); - --quote-border: hsl(197, 37%, 91%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(0, 0%, 95%); - --table-header-bg: hsl(0, 0%, 80%); - --table-alternate-bg: hsl(0, 0%, 97%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #fafafa; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #e4f2fe; - --search-mark-bg: #a2cff5; - - --color-scheme: light; -} - -.navy { - --bg: hsl(226, 23%, 11%); - --fg: #bcbdd0; - - --sidebar-bg: #282d3f; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #505274; - --sidebar-active: #2b79a2; - --sidebar-spacer: #2d334f; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #b7b9cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #161923; - --theme-popup-border: #737480; - --theme-hover: #282e40; - - --quote-bg: hsl(226, 15%, 17%); - --quote-border: hsl(226, 15%, 22%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(226, 23%, 16%); - --table-header-bg: hsl(226, 23%, 31%); - --table-alternate-bg: hsl(226, 23%, 14%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #aeaec6; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #5f5f71; - --searchresults-border-color: #5c5c68; - --searchresults-li-bg: #242430; - --search-mark-bg: #a2cff5; - - --color-scheme: dark; -} - -.rust { - --bg: hsl(60, 9%, 87%); - --fg: #262625; - - --sidebar-bg: #3b2e2a; - --sidebar-fg: #c8c9db; - --sidebar-non-existant: #505254; - --sidebar-active: #e69f67; - --sidebar-spacer: #45373a; - - --scrollbar: var(--sidebar-fg); - - --icons: #737480; - --icons-hover: #262625; - - --links: #2b79a2; - - --inline-code-color: #6e6b5e; - - --theme-popup-bg: #e1e1db; - --theme-popup-border: #b38f6b; - --theme-hover: #99908a; - - --quote-bg: hsl(60, 5%, 75%); - --quote-border: hsl(60, 5%, 70%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(60, 9%, 82%); - --table-header-bg: #b3a497; - --table-alternate-bg: hsl(60, 9%, 84%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #fafafa; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #888; - --searchresults-li-bg: #dec2a2; - --search-mark-bg: #e69f67; - - --color-scheme: light; -} - -@media (prefers-color-scheme: dark) { - .light.no-js { - --bg: hsl(200, 7%, 8%); - --fg: #98a3ad; - - --sidebar-bg: #292c2f; - --sidebar-fg: #a1adb8; - --sidebar-non-existant: #505254; - --sidebar-active: #3473ad; - --sidebar-spacer: #393939; - - --scrollbar: var(--sidebar-fg); - - --icons: #43484d; - --icons-hover: #b3c0cc; - - --links: #2b79a2; - - --inline-code-color: #c5c8c6; - - --theme-popup-bg: #141617; - --theme-popup-border: #43484d; - --theme-hover: #1f2124; - - --quote-bg: hsl(234, 21%, 18%); - --quote-border: hsl(234, 21%, 23%); - - --warning-border: #ff8e00; - - --table-border-color: hsl(200, 7%, 13%); - --table-header-bg: hsl(200, 7%, 28%); - --table-alternate-bg: hsl(200, 7%, 11%); - - --searchbar-border-color: #aaa; - --searchbar-bg: #b7b7b7; - --searchbar-fg: #000; - --searchbar-shadow-color: #aaa; - --searchresults-header-fg: #666; - --searchresults-border-color: #98a3ad; - --searchresults-li-bg: #2b2b2f; - --search-mark-bg: #355c7d; - } -} diff --git a/documentation/old_docs/operators/themes/custom.css b/documentation/old_docs/operators/themes/custom.css deleted file mode 100644 index 6613d3e08b..0000000000 --- a/documentation/old_docs/operators/themes/custom.css +++ /dev/null @@ -1,57 +0,0 @@ -:root { - --mono-font: Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace; -} - -.coal { - --fg: #f2f2f2; - --sidebar-fg: #f2f2f2; - --sidebar-active: #fb6e4e; - --icons-hover: #fb6e4e; - --links: #fb6e4e; - - ::selection { - color: #121726; - background-color: #c5573d; - } - - select option { - background-color: #121726; - } -} - -.light { - --sidebar-active: #fb6e4e; - --icons-hover: #fb6e4e; - --links: #fb6e4e; - - ::selection { - color: #f2f2f2; - background-color: #c5573d; - } -} - -/*properly centering the title given the additional header items*/ -.menu-title { - left: 45%; -} - -.menu-bar .a:hover, - -/*necessary because of ^*/ -.right-buttons { - position: absolute; - right: 0; -} - -select { - font-size: 16px; -} - - - -footer { - font-size: 0.8em; - text-align: center; - border-top: 1px solid black; - padding: 5px 0; -} diff --git a/documentation/old_docs/operators/themes/index.hbs b/documentation/old_docs/operators/themes/index.hbs deleted file mode 100644 index d0bb54d0c3..0000000000 --- a/documentation/old_docs/operators/themes/index.hbs +++ /dev/null @@ -1,358 +0,0 @@ - - - - - - {{ title }} - {{#if is_print }} - - {{/if}} - {{#if base_url}} - - {{/if}} - - - - {{> head}} - - - - - - {{#if favicon_svg}} - - {{/if}} - {{#if favicon_png}} - - {{/if}} - - - - {{#if print_enable}} - - {{/if}} - - - - {{#if copy_fonts}} - - {{/if}} - - - - - - - - {{#each additional_css}} - - {{/each}} - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
- -
- {{> header}} - - - - {{#if search_enabled}} - - {{/if}} - - - - -
-
-
-
- -
-
- - {{{ content }}} -
-
-
- - -
-
- - - -
- - {{#if live_reload_endpoint}} - - - {{/if}} - - {{#if playground_line_numbers}} - - {{/if}} - - {{#if playground_copyable}} - - {{/if}} - - {{#if playground_js}} - - - - - - {{/if}} - - {{#if search_js}} - - - - {{/if}} - - - - - - - {{#each additional_js}} - - {{/each}} - - {{#if is_print}} - {{#if mathjax_support}} - - {{else}} - - {{/if}} - {{/if}} - - -
- - diff --git a/documentation/old_docs/operators/themes/mdbook-admonish.css b/documentation/old_docs/operators/themes/mdbook-admonish.css deleted file mode 100644 index 45aeff0511..0000000000 --- a/documentation/old_docs/operators/themes/mdbook-admonish.css +++ /dev/null @@ -1,348 +0,0 @@ -@charset "UTF-8"; -:is(.admonition) { - display: flow-root; - margin: 1.5625em 0; - padding: 0 1.2rem; - color: var(--fg); - page-break-inside: avoid; - background-color: var(--bg); - border: 0 solid black; - border-inline-start-width: 0.4rem; - border-radius: 0.2rem; - box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1); -} -@media print { - :is(.admonition) { - box-shadow: none; - } -} -:is(.admonition) > * { - box-sizing: border-box; -} -:is(.admonition) :is(.admonition) { - margin-top: 1em; - margin-bottom: 1em; -} -:is(.admonition) > .tabbed-set:only-child { - margin-top: 0; -} -html :is(.admonition) > :last-child { - margin-bottom: 1.2rem; -} - -a.admonition-anchor-link { - display: none; - position: absolute; - left: -1.2rem; - padding-right: 1rem; -} -a.admonition-anchor-link:link, a.admonition-anchor-link:visited { - color: var(--fg); -} -a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover { - text-decoration: none; -} -a.admonition-anchor-link::before { - content: "§"; -} - -:is(.admonition-title, summary.admonition-title) { - position: relative; - min-height: 4rem; - margin-block: 0; - margin-inline: -1.6rem -1.2rem; - padding-block: 0.8rem; - padding-inline: 4.4rem 1.2rem; - font-weight: 700; - background-color: rgba(68, 138, 255, 0.1); - print-color-adjust: exact; - -webkit-print-color-adjust: exact; - display: flex; -} -:is(.admonition-title, summary.admonition-title) p { - margin: 0; -} -html :is(.admonition-title, summary.admonition-title):last-child { - margin-bottom: 0; -} -:is(.admonition-title, summary.admonition-title)::before { - position: absolute; - top: 0.625em; - inset-inline-start: 1.6rem; - width: 2rem; - height: 2rem; - background-color: #448aff; - print-color-adjust: exact; - -webkit-print-color-adjust: exact; - mask-image: url('data:image/svg+xml;charset=utf-8,'); - -webkit-mask-image: url('data:image/svg+xml;charset=utf-8,'); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-size: contain; - content: ""; -} -:is(.admonition-title, summary.admonition-title):hover a.admonition-anchor-link { - display: initial; -} - -details.admonition > summary.admonition-title::after { - position: absolute; - top: 0.625em; - inset-inline-end: 1.6rem; - height: 2rem; - width: 2rem; - background-color: currentcolor; - mask-image: var(--md-details-icon); - -webkit-mask-image: var(--md-details-icon); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-size: contain; - content: ""; - transform: rotate(0deg); - transition: transform 0.25s; -} -details[open].admonition > summary.admonition-title::after { - transform: rotate(90deg); -} - -:root { - --md-details-icon: url("data:image/svg+xml;charset=utf-8,"); -} - -:root { - --md-admonition-icon--admonish-note: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-abstract: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-info: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-tip: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-success: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-question: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-warning: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-failure: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-danger: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-bug: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-example: url("data:image/svg+xml;charset=utf-8,"); - --md-admonition-icon--admonish-quote: url("data:image/svg+xml;charset=utf-8,"); -} - -:is(.admonition):is(.admonish-note) { - border-color: #448aff; -} - -:is(.admonish-note) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(68, 138, 255, 0.1); -} -:is(.admonish-note) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #448aff; - mask-image: var(--md-admonition-icon--admonish-note); - -webkit-mask-image: var(--md-admonition-icon--admonish-note); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-abstract, .admonish-summary, .admonish-tldr) { - border-color: #00b0ff; -} - -:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 176, 255, 0.1); -} -:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00b0ff; - mask-image: var(--md-admonition-icon--admonish-abstract); - -webkit-mask-image: var(--md-admonition-icon--admonish-abstract); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-info, .admonish-todo) { - border-color: #00b8d4; -} - -:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 184, 212, 0.1); -} -:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00b8d4; - mask-image: var(--md-admonition-icon--admonish-info); - -webkit-mask-image: var(--md-admonition-icon--admonish-info); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-tip, .admonish-hint, .admonish-important) { - border-color: #00bfa5; -} - -:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 191, 165, 0.1); -} -:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00bfa5; - mask-image: var(--md-admonition-icon--admonish-tip); - -webkit-mask-image: var(--md-admonition-icon--admonish-tip); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-success, .admonish-check, .admonish-done) { - border-color: #00c853; -} - -:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(0, 200, 83, 0.1); -} -:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #00c853; - mask-image: var(--md-admonition-icon--admonish-success); - -webkit-mask-image: var(--md-admonition-icon--admonish-success); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-question, .admonish-help, .admonish-faq) { - border-color: #64dd17; -} - -:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(100, 221, 23, 0.1); -} -:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #64dd17; - mask-image: var(--md-admonition-icon--admonish-question); - -webkit-mask-image: var(--md-admonition-icon--admonish-question); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-warning, .admonish-caution, .admonish-attention) { - border-color: #ff9100; -} - -:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 145, 0, 0.1); -} -:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff9100; - mask-image: var(--md-admonition-icon--admonish-warning); - -webkit-mask-image: var(--md-admonition-icon--admonish-warning); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-failure, .admonish-fail, .admonish-missing) { - border-color: #ff5252; -} - -:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 82, 82, 0.1); -} -:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff5252; - mask-image: var(--md-admonition-icon--admonish-failure); - -webkit-mask-image: var(--md-admonition-icon--admonish-failure); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-danger, .admonish-error) { - border-color: #ff1744; -} - -:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(255, 23, 68, 0.1); -} -:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #ff1744; - mask-image: var(--md-admonition-icon--admonish-danger); - -webkit-mask-image: var(--md-admonition-icon--admonish-danger); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-bug) { - border-color: #f50057; -} - -:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(245, 0, 87, 0.1); -} -:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #f50057; - mask-image: var(--md-admonition-icon--admonish-bug); - -webkit-mask-image: var(--md-admonition-icon--admonish-bug); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-example) { - border-color: #7c4dff; -} - -:is(.admonish-example) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(124, 77, 255, 0.1); -} -:is(.admonish-example) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #7c4dff; - mask-image: var(--md-admonition-icon--admonish-example); - -webkit-mask-image: var(--md-admonition-icon--admonish-example); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -:is(.admonition):is(.admonish-quote, .admonish-cite) { - border-color: #9e9e9e; -} - -:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title) { - background-color: rgba(158, 158, 158, 0.1); -} -:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title)::before { - background-color: #9e9e9e; - mask-image: var(--md-admonition-icon--admonish-quote); - -webkit-mask-image: var(--md-admonition-icon--admonish-quote); - mask-repeat: no-repeat; - -webkit-mask-repeat: no-repeat; - mask-size: contain; - -webkit-mask-repeat: no-repeat; -} - -.navy :is(.admonition) { - background-color: var(--sidebar-bg); -} - -.ayu :is(.admonition), -.coal :is(.admonition) { - background-color: var(--theme-hover); -} - -.rust :is(.admonition) { - background-color: var(--sidebar-bg); - color: var(--sidebar-fg); -} -.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited { - color: var(--sidebar-fg); -} diff --git a/documentation/old_docs/operators/themes/pagetoc.css b/documentation/old_docs/operators/themes/pagetoc.css deleted file mode 100644 index a68e5b8e21..0000000000 --- a/documentation/old_docs/operators/themes/pagetoc.css +++ /dev/null @@ -1,47 +0,0 @@ -/* src: https://github.com/JorelAli/mdBook-pagetoc */ - -@media only screen and (max-width:1439px) { - .sidetoc { - display: none; - } -} - -@media only screen and (min-width:1440px) { - main { - position: relative; - } - .sidetoc { - margin-left: auto; - margin-right: auto; - /* left: calc(90% + (var(--content-min-width))/4 - 110px); */ - left: 101%; - position: absolute; - font-size: var(--pagetoc-fontsize); - } - .pagetoc { - position: fixed; - width: var(--pagetoc-width); - } - .pagetoc a { - border-left: 1px solid var(--sidebar-bg); - /* color: var(--fg); */ - /* color: var(--sidebar-fg); */ - color: var(--links); - display: block; - padding-bottom: 5px; - padding-top: 5px; - padding-left: 10px; - text-align: left; - text-decoration: none; - font-weight: normal; - background: var(--sidebar-bg); - } - .pagetoc a:hover, - .pagetoc a.active { - background: var(--sidebar-bg); - /* color: var(--sidebar-fg); */ - color: var(--sidebar-active); - font-weight: bold; - font-size: var(--pagetoc-fontsize); - } -} diff --git a/documentation/old_docs/operators/themes/pagetoc.js b/documentation/old_docs/operators/themes/pagetoc.js deleted file mode 100644 index b11052427e..0000000000 --- a/documentation/old_docs/operators/themes/pagetoc.js +++ /dev/null @@ -1,68 +0,0 @@ -// src: https://github.com/JorelAli/mdBook-pagetoc - -// Un-active everything when you click it -Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.addEventHandler("click", function() { - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.classList.remove("active"); - }); - el.classList.add("active"); - }); -}); - -var updateFunction = function() { - - var id; - var elements = document.getElementsByClassName("header"); - Array.prototype.forEach.call(elements, function(el, i) { - if (window.pageYOffset >= el.offsetTop) { - id = el; - } - }); - - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - el.classList.remove("active"); - }); - - Array.prototype.forEach.call(document.getElementsByClassName("pagetoc")[0].children, function(el, i) { - if (id.href.localeCompare(el.href) == 0) { - el.classList.add("active"); - } - }); -}; - -// Populate sidebar on load -window.addEventListener('load', function() { - var pagetoc = document.getElementsByClassName("pagetoc")[0]; - var elements = document.getElementsByClassName("header"); - Array.prototype.forEach.call(elements, function(el, i) { - var link = document.createElement("a"); - - // Indent shows hierarchy - var indent = ""; - switch (el.parentElement.tagName) { - case "H2": - indent = "20px"; - break; - case "H3": - indent = "40px"; - break; - case "H4": - indent = "60px"; - break; - default: - break; - } - - link.appendChild(document.createTextNode(el.text)); - link.style.paddingLeft = indent; - link.href = el.href; - pagetoc.appendChild(link); - }); - updateFunction.call(); -}); - - - -// Handle active elements on scroll -window.addEventListener("scroll", updateFunction); diff --git a/documentation/remove_existing_config.sh b/documentation/remove_existing_config.sh deleted file mode 100755 index ae2b767512..0000000000 --- a/documentation/remove_existing_config.sh +++ /dev/null @@ -1,23 +0,0 @@ -#!/usr/bin/env bash - -set -o errexit -set -o nounset -set -o pipefail - -# Script to remove existing ~'/.nym/ files on docs deployment. Used to avoid issues with `mdbook-cmdrun` output when -# e.g. erroring about overwriting existing keys. `mdbook-cmdrun` output for the moment has to be checked manually. - -DIR=~/.nym - -# check for config directory -if [ ! -d $DIR ]; then - echo "config dir doesn't exist: nothing to do" -else - echo "config dir exists - deleting" - rm -rf $DIR - # check exit code of rm -rf - if !0 then exit - if [ $? -ne 0 ]; then - echo "exit code was $?. looks like the something went wrong with deleting the directory" - exit 1 - fi -fi \ No newline at end of file