[DOCs/bugfix]: Fix broken URLs (#4745)

* create archive nym connect page & add redirections

* add info to socks5 page

* fix dev-portal links

* finish URL edits and redirection

documentation/dev-portal/src/SUMMARY.md

@@ -2,7 +2,7 @@
 - [Introduction](introduction.md)
 - [Clients Overview - Start Here!](clients-overview.md)
 
-# SDKs 
+# SDKs
 - [Rust SDK](sdk/rust/rust.md)
 	- [Message Types](sdk/rust/message-types.md)
 	- [Message Helpers](sdk/rust/message-helpers.md)
@@ -30,7 +30,7 @@
 	- [Using Your Client](clients/websocket/usage.md)
 	- [Examples](clients/websocket/examples.md)
 - [Socks5 Client](clients/socks5-client.md)
-  - [Setup & Run](clients/socks5/setup.md) 
+  - [Setup & Run](clients/socks5/setup.md)
   - [Using Your Client](clients/socks5/usage.md)
 - [Webassembly Client](clients/webassembly-client.md)
 
@@ -54,8 +54,13 @@
 # User Manuals
 - [NymVPN alpha](nymvpn/intro.md)
     - [CLI](nymvpn/cli.md)
+---
+
+# Archive
+- [NymConnect Setup](archive/nym-connect.md)
 
 ---
+
 # Misc.
 - [Code of Conduct](coc.md)
 - [Licensing](licensing.md)

documentation/dev-portal/src/binaries/building-nym.md

@@ -52,10 +52,10 @@ git checkout master # master branch has the latest release version: `develop` wi
 cargo build --release # build your binaries with **mainnet** configuration
 ```
 
-Quite a bit of stuff gets built. The key working parts for devs are the Client binaries and the CLI tool: 
+Quite a bit of stuff gets built. The key working parts for devs are the Client binaries and the CLI tool:
 
 * [websocket client](../clients/websocket-client.md): `nym-client`
 * [socks5 client](../clients/socks5-client.md): `nym-socks5-client`
-* [nym-cli tool](https://nymtech.net/docs/tools/nym-cli.md): `nym-cli`
+* [nym-cli tool](https://nymtech.net/docs/tools/nym-cli.html): `nym-cli`
 
 > You cannot build from GitHub's .zip or .tar.gz archive files on the releases page - the Nym build scripts automatically include the current git commit hash in the built binary during compilation, so the build will fail if you use the archive code (which isn't a Git repository). Check the code out from github using `git clone` instead.

documentation/dev-portal/src/clients/socks5-client.md

@@ -104,8 +104,6 @@ The `--use-reply-surbs` field denotes whether you wish to send [SURBs](https://n
 
 The `--provider` field needs to be filled with the Nym address of a Network Requester that can make network requests on your behalf. If you don't want to [run your own](https://nymtech.net/operators/nodes/network-requester.md) you can select one from the [mixnet explorer](https://explorer.nymtech.net/network-components/service-providers) by copying its `Client ID` and using this as the value of the `--provider` flag. Alternatively, you could use [this list](https://harbourmaster.nymtech.net/).
 
-Since the nodes on this list are the infrastructure for [Nymconnect](https://nymtech.net/developers/quickstart/nymconnect-gui.html) they will support all apps on the [default whitelist](https://nymtech.net/operators/nodes/network-requester.md#network-requester-whitelist): Keybase, Telegram, Electrum, Blockstream Green, and Helios.
-
 #### Choosing a Gateway
 By default - as in the example above - your client will choose a random gateway to connect to.
 

documentation/dev-portal/src/clients/socks5/setup.md

@@ -1,9 +1,14 @@
-# Setup 
+# Setup
 
 > `nym-socks5-client` now also supports SOCKS4 and SOCKS4A protocols as well as SOCKS5.
 
 The Nym socks5 client allows you to proxy traffic from a desktop application through the mixnet, meaning you can send and receive information from remote application servers without leaking metadata which can be used to deanonymise you, even if you're using an encrypted application such as Signal.
 
+```admonish info
+Since the beginning of 2024 NymConnect is no longer maintained. Nym is developing a new client called [NymVPN](https://nymvpn.com), an application routing all users traffic thorugh the mixnet.
+If users want to route their traffic through socks5 we advice to use this client. If you want to run deprecated NymConnect, visit [NymConnect archive page](../../archive/nym-connect.md) with setup and application examples.
+```
+
 ## Setup and Run
 
 ### Download or compile socks5 client
@@ -38,5 +43,3 @@ Now your client is initialised, start it with the following:
 ```
 ./nym-socks5-client run --id <ID>
 ```
-
-

documentation/dev-portal/src/clients/websocket/examples.md

@@ -12,4 +12,6 @@ All of these code examples will do the following:
 
 By varying the message content, you can easily build sophisticated service provider apps. For example, instead of printing the response received from the mixnet, your service provider might take some action on behalf of the user - perhaps initiating a network request, a blockchain transaction, or writing to a local data store.
 
+<!-- THIS PAGE IS NOT WORKING AT THE MOMENT:
 > You can find an example of building both frontend and service provider code with the websocket client in the [Simple Service Provider Tutorial](https://nymtech.net/developers/tutorials/simple-service-provider/simple-service-provider.html) in the Developer Portal.
+-->

documentation/dev-portal/src/clients/websocket/usage.md

@@ -1,17 +1,17 @@
 # Using Your Client
 The Nym native client exposes a websocket interface that your code connects to. The **default** websocket port is `1977`, you can override that in the client config if you want.
 
-Once you have a websocket connection, interacting with the client involves piping messages down the socket and listening for incoming messages. 
+Once you have a websocket connection, interacting with the client involves piping messages down the socket and listening for incoming messages.
 
-# Message Requests 
-There are a number of message types that you can send up the websocket as defined [here](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs):  
+# Message Requests
+There are a number of message types that you can send up the websocket as defined [here](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs):
 
 ```rust,noplayground
 {{#include ../../../../../clients/native/websocket-requests/src/requests.rs:55:97}}
 ```
 
 ## Getting your own address
-When you start your app, it is best practice to ask the native client to tell you what your own address is (from the generated configuration files - see [here](https://nymtech.net/docs/architecture/addressing-system.md) for more on Nym's addressing scheme). If you are running a service, you need to do this in order to know what address to give others. In a client-side piece of code you can also use this as a test to make sure your websocket connection is running smoothly. To do this, send:
+When you start your app, it is best practice to ask the native client to tell you what your own address is (from the generated configuration files <!--add link -->. If you are running a service, you need to do this in order to know what address to give others. In a client-side piece of code you can also use this as a test to make sure your websocket connection is running smoothly. To do this, send:
 
 ```json
 {
@@ -28,9 +28,9 @@ You'll receive a response of the format:
 }
 ```
 
-See [here](https://github.com/nymtech/nym/blob/93cc281abc2cc951023b51746fa6f2ead1f56c46/clients/native/examples/python-examples/websocket/textsend.py#L16C9-L16C9) for an example of this being used. 
+See [here](https://github.com/nymtech/nym/blob/93cc281abc2cc951023b51746fa6f2ead1f56c46/clients/native/examples/python-examples/websocket/textsend.py#L16C9-L16C9) for an example of this being used.
 
-> Note that all the pieces of native client example code begin with printing the selfAddress. Examples exist for Rust, Go, Javascript, and Python. 
+> Note that all the pieces of native client example code begin with printing the selfAddress. Examples exist for Rust, Go, Javascript, and Python.
 
 ## Sending text
 If you want to send text information through the mixnet, format a message like this one and poke it into the websocket:
@@ -65,26 +65,26 @@ Your client will send along a number of `replySurbs` to the recipient of the mes
 ```json
 {
     "type": "sendAnonymous",
-    "message": "something you want to keep secret", 
-    "recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm", 
+    "message": "something you want to keep secret",
+    "recipient": "71od3ZAupdCdxeFNg8sdonqfZTnZZy1E86WYKEjxD4kj@FWYoUrnKuXryysptnCZgUYRTauHq4FnEFu2QGn5LZWbm",
     "replySurbs": 20 // however many reply SURBs to send along with your message
 }
 ```
 
-See ['Replying to SURB Messages'](#replying-to-surb-messages) below for an example of how to deal with incoming messages that have SURBs attached. 
+See ['Replying to SURB Messages'](#replying-to-surb-messages) below for an example of how to deal with incoming messages that have SURBs attached.
 
-Deciding on the amount of SURBs to generate and send along with outgoing messages depends on the expected size of the reply. You might want to send a lot of SURBs in order to make sure you get your response as quickly as possible (but accept the minor additional latency when sending, as your client has to generate and encrypt the packets), or you might just send a few (e.g. 20) and then if your response requires more SURBs, send them along, accepting the additional latency in getting your response. 
+Deciding on the amount of SURBs to generate and send along with outgoing messages depends on the expected size of the reply. You might want to send a lot of SURBs in order to make sure you get your response as quickly as possible (but accept the minor additional latency when sending, as your client has to generate and encrypt the packets), or you might just send a few (e.g. 20) and then if your response requires more SURBs, send them along, accepting the additional latency in getting your response.
 
 ## Sending binary data
 You can also send bytes instead of JSON. For that you have to send a binary websocket frame containing a binary encoded
 Nym [`ClientRequest`](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/requests.rs#L25) containing the same information.
 
-> As a response the `native-client` will send a `ServerResponse` to be decoded. See [Message Responses](#message-responses) below for more. 
+> As a response the `native-client` will send a `ServerResponse` to be decoded. See [Message Responses](#message-responses) below for more.
 
 You can find examples of sending and receiving binary data in the [code examples](https://github.com/nymtech/nym/tree/master/clients/native/examples), and an example project from the Nym community [BTC-BC](https://github.com/sgeisler/btcbc-rs/): Bitcoin transaction transmission via Nym, a client and service provider written in Rust.
 
 ## Replying to SURB messages
-Each bucket of `replySURBs`, when received as part of an incoming message, has a unique session identifier, which **only identifies the bucket of pre-addressed packets**. This is necessary to make sure that your app is replying to the correct people with the information meant for them in a situation where multiple clients are sending requests to a single service. 
+Each bucket of `replySURBs`, when received as part of an incoming message, has a unique session identifier, which **only identifies the bucket of pre-addressed packets**. This is necessary to make sure that your app is replying to the correct people with the information meant for them in a situation where multiple clients are sending requests to a single service.
 
 Constructing a reply with SURBs looks something like this (where `senderTag` was parsed from the incoming message)
 
@@ -107,9 +107,9 @@ Errors from the app's client, or from the gateway, will be sent down the websock
 ```
 
 ## LaneQueueLength
-This is currently only used in the [Socks Client](../socks5-client.md) to keep track of the number of Sphinx packets waiting to be sent to the mixnet via being slotted amongst cover traffic. As this value becomes larger, the client signals to the application it should slow down the speed with which it writes to the proxy. This is to stop situations arising whereby an app connected to the client appears as if it has sent (e.g.) a bunch of messages and is awaiting a reply, when they in fact have not been sent through the mixnet yet.  
+This is currently only used in the [Socks Client](../socks5-client.md) to keep track of the number of Sphinx packets waiting to be sent to the mixnet via being slotted amongst cover traffic. As this value becomes larger, the client signals to the application it should slow down the speed with which it writes to the proxy. This is to stop situations arising whereby an app connected to the client appears as if it has sent (e.g.) a bunch of messages and is awaiting a reply, when they in fact have not been sent through the mixnet yet.
 
-# Message Responses 
+# Message Responses
 Responses to your messages are defined [here](https://github.com/nymtech/nym/blob/develop/clients/native/websocket-requests/src/responses.rs):
 
 ```rust,noplayground

documentation/dev-portal/src/examples/browser-only.md

@@ -1,12 +1,12 @@
 # Browser only
-With the Typescript SDK you can run a Nym client in a webworker - meaning you can connect to the mixnet through the browser without having to worry about any other code than your web framework. 
+With the Typescript SDK you can run a Nym client in a webworker - meaning you can connect to the mixnet through the browser without having to worry about any other code than your web framework.
 
-- Oreowallet have integrated `mixFetch` into their browser-extension wallet to run transactions through the mixnet. 
-  - [Codebase](https://github.com/oreoslabs/oreowallet-extension/tree/mixFetch) 
+- Oreowallet have integrated `mixFetch` into their browser-extension wallet to run transactions through the mixnet.
+  - [Codebase](https://github.com/oreoslabs/oreowallet-extension/tree/mixFetch)
 
-- [NoTrustVerify](https://notrustverify.ch/) have set up an example application using [`mixFetch`](https://sdk.nymtech.net/examples/mix-fetch) to fetch crypto prices from CoinGecko over the mixnet. 
-  - [Website](https://notrustverify.github.io/mixfetch-examples/) 
-  - [Codebase](https://github.com/notrustverify/mixfetch-examples)  
+- [NoTrustVerify](https://notrustverify.ch/) have set up an example application using [`mixFetch`](https://sdk.nymtech.net/examples/mix-fetch) to fetch crypto prices from CoinGecko over the mixnet.
+  - [Website](https://notrustverify.github.io/mixfetch-examples/)
+  - [Codebase](https://github.com/notrustverify/mixfetch-examples)
 
 - There is a coconut-scheme based Credential Library playground [here](https://coco-demo.nymtech.net/). This is a WASM implementation of our Coconut libraries which generate raw Coconut credentials. Test it to create and re-randomize your own credentials. For more information on what is happening here check out the [Coconut docs](https://nymtech.net/docs/coconut.html).
 

documentation/dev-portal/src/examples/using-nrs.md

@@ -1,17 +1,17 @@
 # Apps Using Network Requesters
-These applications utilise custom app logic in the user-facing apps in order to communicate using the mixnet as a transport layer, without having to rely on custom server-side logic. Instead, they utilise existing Nym infrastructure - [Network Requesters](https://nymtech.net/operators/nodes/network-requester-setup.html) - with a custom whitelist addition. 
+These applications utilise custom app logic in the user-facing apps in order to communicate using the mixnet as a transport layer, without having to rely on custom server-side logic. Instead, they utilise existing Nym infrastructure - Network Requesters - now embeded in `nym-node` running as `exit-gateway`.
 
-If you are sending 'normal' application traffic, and/or don't require and custom logic to be happening on the 'other side' of the mixnet, this is most likely the best option to take as a developer who wishes to privacy-enhance their application. 
+If you are sending 'normal' application traffic, and/or don't require and custom logic to be happening on the 'other side' of the mixnet, this is most likely the best option to take as a developer who wishes to privacy-enhance their application.
+
+> Nym will soon be switching from a whitelist-based approach to a blocklist-based approach to filtering traffic. As such, it will soon be even easier for developers to utilise the mixnet, as they will not have to run their own NRs or have to add their domains to the whitelist
 
-> Nym will soon be switching from a whitelist-based approach to a blocklist-based approach to filtering traffic. As such, it will soon be even easier for developers to utilise the mixnet, as they will not have to run their own NRs or have to add their domains to the whitelist 
- 
 - DarkFi over Nym leverages Nym’s mixnet as a pluggable transport for DarkIRC, their p2p IRC variant. Users can anonymously connect to peers over the network, ensuring secure and private communication within the DarkFi ecosystem. Written in **Rust**.
   - [Docs](https://darkrenaissance.github.io/darkfi/clients/nym_outbound.html?highlight=nym#3--run)
-  - [Github](https://github.com/darkrenaissance/darkfi/tree/master/doc) 
+  - [Github](https://github.com/darkrenaissance/darkfi/tree/master/doc)
 
-- MiniBolt is a complete guide to building a Bitcoin & Lightning full node on a personal computer. It has the capacity to run network traffic (transactions and syncing) over the mixnet, so you can privately sync your node and not expose your home IP to the wider world when interacting with the rest of the network! 
+- MiniBolt is a complete guide to building a Bitcoin & Lightning full node on a personal computer. It has the capacity to run network traffic (transactions and syncing) over the mixnet, so you can privately sync your node and not expose your home IP to the wider world when interacting with the rest of the network!
   - [Docs](https://v2.minibolt.info/bonus-guides/system/nym-mixnet#proxying-bitcoin-core)
   - [Codebase](https://github.com/minibolt-guide/minibolt)
 
-- Email over Nym is a set of configuration options to set up a Network Requester to send and recieve emails over Nym, using something like Thunderbird. 
-  - [Codebase](https://github.com/dial0ut/nymstr-email)
+- 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)

documentation/dev-portal/src/nymvpn/cli.md

@@ -171,7 +171,7 @@ If you want to run NymVPN CLI in Nym Sandbox environment, there are a few adjust
 curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env
 ```
 
-2. Check available Gateways at [nymvpn.com/en/alpha/api/gateways](https://nymvpn.com/en/alpha/api/gateways)
+2. Check available Gateways at [Sandbox API](https://sandbox-nym-api1.nymtech.net/api/v1/gateways) or [Sandbox Swagger page](https://sandbox-nym-api1.nymtech.net/api/swagger/index.html)
 
 3. Run with a flag `-c`
 ```sh

documentation/dev-portal/src/sdk/rust/examples/credential.md

@@ -5,5 +5,4 @@ The following code shows how you can use the SDK to create and use a credential
 {{#include ../../../../../../sdk/rust/nym-sdk/examples/bandwidth.rs}}
 ```
 
-You can read more about Coconut credentials (also referred to as `zk-Nym`) [here](https://nymtech.net/docs/coconut.md).
-
+You can read more about Coconut credentials (also referred to as `zk-Nym`) [here](https://nymtech.net/docs/coconut.html).

documentation/dev-portal/src/sdk/rust/examples/surbs.md

@@ -1,7 +1,7 @@
 # Anonymous Replies with SURBs (Single Use Reply Blocks)
 Both functions used to send messages through the mixnet (`send_message` and `send_plain_message`) send a pre-determined number of SURBs along with their messages by default.
 
-You can read more about how SURBs function under the hood [here](https://nymtech.net/docs/architecture/traffic-flow.md#private-replies-using-surbs).
+You can read more about how SURBs function under the hood [here](https://nymtech.net/docs/architecture/traffic-flow.html#private-replies-using-surbs).
 
 In order to reply to an incoming message using SURBs, you can construct a `recipient` from the `sender_tag` sent along with the message you wish to reply to: