Docs sections overhaul (#441)

* oh boy here goes nothing

* adding new CSM page

* creating new pages, adding pictures

* chaing CSM walkthrough to v1.1.2

* adding all redirects

* adding "next" or else it doesn't pass checks

* Update docs/run/integrations/lido-csm.md

Co-authored-by: Kaloyan Tanev <[email protected]>

* Update docs/learn/intro/obol-vs-others.md

Co-authored-by: Kaloyan Tanev <[email protected]>

* Update docs/learn/intro/obol-vs-others.md

Co-authored-by: Kaloyan Tanev <[email protected]>

* Update docs/learn/intro/obol-vs-others.md

Co-authored-by: Kaloyan Tanev <[email protected]>

* Update docs/learn/intro/obol-vs-others.md

Co-authored-by: Kaloyan Tanev <[email protected]>

* Update docs/learn/intro/obol-vs-others.md

Co-authored-by: Kaloyan Tanev <[email protected]>

* fix links

* Update docs/guides/walkthroughs/walkthrough-guides.md

Co-authored-by: Oisín Kyne <[email protected]>

* Update docs/guides/walkthroughs/walkthrough-guides.md

Co-authored-by: Oisín Kyne <[email protected]>

* Update docs/guides/walkthroughs/walkthrough-guides.md

Co-authored-by: Oisín Kyne <[email protected]>

* fixing stuff suggested by Oisin

* updating CSM page to latest version (copy pasted markdown from current docs version)

* adding "the components" of the staking stack

* adding relative links to "how_where_DVs"

* fixes as proposed by Oisin to the "Obol vs others" page

* fixing links in CSM guide

---------

Co-authored-by: “Max <“[email protected]”>
Co-authored-by: Kaloyan Tanev <[email protected]>
Co-authored-by: HananINouman <[email protected]>
Co-authored-by: Oisín Kyne <[email protected]>

docs/adv/_category_.json

@@ -0,0 +1,7 @@
+{
+  "label": "ADVANCED & TROUBLESHOOTING",
+  "position": 3,
+  "collapsed": false,
+  "collapsible": false,
+  "className": "menuSection"
+}

docs/advanced/_category_.json → docs/adv/advanced/_category_.json

@@ -1,5 +1,5 @@
 {
     "label": "Advanced Guides",
-    "position": 3,
+    "position": 1,
     "collapsed": true
-  }
+}

docs/advanced/adv-docker-configs.md → docs/adv/advanced/adv-docker-configs.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 12
+sidebar_position: 6
 description: Use advanced docker-compose features to have more flexibility and power to change the default configuration.
 ---
 

docs/advanced/quickstart-combine.md → docs/adv/advanced/quickstart-combine.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 8
+sidebar_position: 4
 description: Combine distributed validator private key shares to recover the validator private key.
 ---
 

docs/advanced/quickstart-sdk.mdx → docs/adv/advanced/quickstart-sdk.mdx

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 2
 description: Create a DV cluster using the Obol Typescript SDK
 ---
 
@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';
 
 # Create a DV using the SDK
 
-This is a walkthrough of using the [Obol-SDK](https://www.npmjs.com/package/@obolnetwork/obol-sdk) to propose a four-node distributed validator cluster for creation using the [DV Launchpad](../dvl/intro.md).
+This is a walkthrough of using the [Obol-SDK](https://www.npmjs.com/package/@obolnetwork/obol-sdk) to propose a four-node distributed validator cluster for creation using the [DV Launchpad](../../learn/intro/launchpad.md).
 
 ## Pre-requisites
 
@@ -81,9 +81,9 @@ console.log(
 
 ## Invite the Operators to complete the DKG
 
-Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../dvl/intro.md) to complete the process
+Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../../learn/intro/launchpad.md) to complete the process
 
-1. Operators navigate to `https://<NETWORK_NAME_HERE>.launchpad.obol.org/dv?configHash=<CONFIG_HASH_HERE>` and complete the [run a DV with others](../start/quickstart_group.mdx) flow.
+1. Operators navigate to `https://<NETWORK_NAME_HERE>.launchpad.obol.org/dv?configHash=<CONFIG_HASH_HERE>` and complete the [run a DV with others](../../run/start/quickstart_group.mdx) flow.
 1. Once the DKG is complete, and operators are using the `--publish` flag, the created cluster details will be posted to the Obol API.
 1. The creator will be able to retrieve this data with `obol.getClusterLock(configHash)`, to use for activating the newly created validator.
 

docs/advanced/quickstart-split.md → docs/adv/advanced/quickstart-split.md

@@ -1,17 +1,17 @@
 ---
-sidebar_position: 7
+sidebar_position: 3
 description: Migrate an existing validator by splitting its private key into shares
 ---
 
-# Migrate a validator
+# Migrate an existing validator
 
 :::warning
 This process should only be used if you want to split an *existing validator private key* into multiple private key shares for use in a Distributed Validator Cluster. **If your existing validator is not properly shut down before the Distributed Validator starts, your validator may be slashed**.
 
-If you are starting a new validator, you should follow a [quickstart guide](../start/quickstart_overview.md) instead.
+If you are starting a new validator, you should follow a [quickstart guide](../../run/start/quickstart_overview.md) instead.
 :::
 
-Split an existing Ethereum validator key into multiple key shares for use in an [Obol Distributed Validator Cluster](../int/key-concepts.md#distributed-validator-cluster).
+Split an existing Ethereum validator key into multiple key shares for use in an [Obol Distributed Validator Cluster](../../learn/intro/key-concepts.md#distributed-validator-cluster).
 
 ## Pre-requisites
 
@@ -94,7 +94,7 @@ These split keys can now be used to start a Charon cluster.
 
 ## Step 3. (Optional) Encrypt artifacts for distribution
 
-Within each folder are the encrypted [private key shares](../int/key-concepts.md#distributed-validator-key-share), along with the decryption passwords. To transmit these folders to the operators/machines where they will run, it might be prudent to encrypt the folder as a `.zip` to transport them.
+Within each folder are the encrypted [private key shares](../../learn/intro/key-concepts.md#distributed-validator-key-share), along with the decryption passwords. To transmit these folders to the operators/machines where they will run, it might be prudent to encrypt the folder as a `.zip` to transport them.
 
 ```shell
 # For each folder in ./cluster/ encrypt it with a different password

docs/advanced/self-relay.md → docs/adv/advanced/self-relay.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 9
+sidebar_position: 5
 description: Self-host a relay
 ---
 
@@ -35,4 +35,4 @@ Configure **ALL** charon nodes in your cluster to use this relay:
 
 Note that a local `relay/.charon/charon-enr-private-key` file will be created next to `relay/docker-compose.yml` to ensure a persisted relay ENR across restarts.
 
-A list of publicly available relays that can be used is maintained [here](../faq/risks.md).
+A list of publicly available relays that can be used is maintained [here](../../adv/security/risks.md).

docs/sec/bug-bounty.md → docs/adv/security/bug-bounty.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 2
+sidebar_position: 3
 description: Bug Bounty Policy
 ---
 
@@ -34,7 +34,7 @@ Submissions related to the following are considered out of scope:
 - Physical security breaches
 - Non-security related UX/UI issues
 - Third-party application vulnerabilities
-- The [Obol](https://obol.tech) static website or the Obol infrastructure
+- The [Obol](https://obol.org) static website or the Obol infrastructure
 - The operational security of node operators running or using Obol software
 
 ## Program Rules

docs/sec/contact.md → docs/adv/security/contact.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 7
 description: Security details for the Obol Network
 ---
 

docs/sec/ev-assessment.md → docs/adv/security/ev-assessment.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 4
+sidebar_position: 5
 description: Software Development Security Assessment
 ---
 
@@ -64,9 +64,9 @@ Obol’s business model is to eventually capture a portion of the revenue genera
 
 Obol’s product consists of three main components, each run by its own team: a webapp, a client, and smart contracts.
 
-- [DV Launchpad](../dvl/intro.md): A webapp to create and manage distributed validators.
-- [Charon](../charon/intro.md): A middleware client that enables operators to run distributed validators.
-- [Solidity](../sc/introducing-obol-splits.mdx): Withdrawal and fee recipient contracts for use with distributed validators.
+- [DV Launchpad](../../learn/intro/launchpad.md): A webapp to create and manage distributed validators.
+- [Charon](../../learn/charon/intro.md): A middleware client that enables operators to run distributed validators.
+- [Solidity](../../learn/intro/obol-splits.mdx): Withdrawal and fee recipient contracts for use with distributed validators.
 
 ## Analysis - Cluster Setup and DKG
 

docs/faq/risks.md → docs/adv/security/risks.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 2
 description: Centralization Risks and mitigation
 ---
 
@@ -9,9 +9,10 @@ description: Centralization Risks and mitigation
 
 **Mitigation**: Self-host a relay.
 
-One of the risks associated with Obol hosting the [LibP2P relays](../charon/networking.mdx) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays.
+One of the risks associated with Obol hosting the [LibP2P relays](../../learn/charon/networking.mdx) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays.
+
+The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../../learn/charon/charon-cli-reference.md#the-run-command)):
 
-The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../charon/charon-cli-reference.md#the-run-command)):
 
 | Entity    | Relay URL                                   |
 |-----------|---------------------------------------|
@@ -25,13 +26,13 @@ The following non-Obol entities run relays that you can consider adding to your
 
 **Mitigation**: Pin specific docker versions or compile from source on a trusted commit.
 
-Another risk associated with Obol is the Labs team having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) used by node operators within DV clusters, which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the Docker image or git repo that have been [thoroughly tested](../sec/overview.md#list-of-security-audits-and-assessments) and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community, and only introduced into a running cluster gradually. The labs team will strive to communicate the security or operational impact any Charon update entails, giving operators the chance to decide whether they want potential performance or quality of experience improvements, or whether they remain on a trusted version for longer.
+Another risk associated with Obol is the Labs team having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) used by node operators within DV clusters, which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the Docker image or git repo that have been [thoroughly tested](../security/overview.md#list-of-security-audits-and-assessments) and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community, and only introduced into a running cluster gradually. The labs team will strive to communicate the security or operational impact any Charon update entails, giving operators the chance to decide whether they want potential performance or quality of experience improvements, or whether they remain on a trusted version for longer.
 
 ## Risk: Obol hosting the DV Launchpad
 
-**Mitigation**: Use [`create cluster`](../charon/charon-cli-reference.md#the-create-command) or [`create dkg`](../charon/charon-cli-reference.md#creating-the-configuration-for-a-dkg-ceremony) locally and distribute the files manually.
+**Mitigation**: Use [`create cluster`](../../learn/charon/charon-cli-reference.md#the-create-command) or [`create dkg`](../../learn/charon/charon-cli-reference.md#creating-the-configuration-for-a-dkg-ceremony) locally and distribute the files manually.
 
-Hosting the first Charon frontend, the [DV Launchpad](../dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally.
+Hosting the first Charon frontend, the [DV Launchpad](../../learn/intro/launchpad.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally.
 
 To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually.
 

docs/sec/smart_contract_audit.mdx → docs/adv/security/smart_contract_audit.mdx

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 4
 description: Smart Contract Audit
 ---
 

docs/sec/threat_model.md → docs/adv/security/threat_model.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 6
+sidebar_position: 5
 description: Threat model for a Distributed Validator
 ---
 

docs/start/_category_.json → docs/adv/troubleshooting/_category_.json

@@ -1,5 +1,5 @@
 {
-  "label": "Getting started",
+  "label": "Troubleshooting",
   "position": 2,
   "collapsed": true
 }

docs/faq/client_configurations.md → docs/adv/troubleshooting/client_configurations.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 3
 description: A reference for extra configuration of Ethereum Clients when running in DVs. 
 ---
 
@@ -14,7 +14,7 @@ Many execution, consensus, and validator clients need custom flags or parameters
 
 ### Consensus Client
 
-Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../advanced/quickstart-builder-api.mdx#consensus-clients).
+Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../../run/start/quickstart-builder-api.mdx#consensus-clients).
 
 ### Validator Client
 
@@ -27,7 +27,7 @@ Required flags:
 
 ### Consensus Client
 
-Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../advanced/quickstart-builder-api.mdx#consensus-clients).
+Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../../run/start/quickstart-builder-api.mdx#consensus-clients).
 
 ### Validator Client
 
@@ -56,7 +56,7 @@ Required flags:
 
 ### Consensus Client
 
-Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../advanced/quickstart-builder-api.mdx#consensus-clients).
+Nothing specific for distributed validators is required. If you are configuring MEV-boost, consult the settings you need [here](../../run/start/quickstart-builder-api.mdx#consensus-clients).
 
 ### Validator Client
 

docs/faq/dkg_failure.md → docs/adv/troubleshooting/dkg_failure.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 4
+sidebar_position: 2
 description: Handling DKG failure
 ---
 

docs/faq/errors.mdx → docs/adv/troubleshooting/errors.mdx

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 2
+sidebar_position: 1
 description: Errors & Resolutions
 ---
 

docs/gov/_category_.json

@@ -0,0 +1,7 @@
+{
+  "label": "COMMUNITY & GOVERNANCE",
+  "position": 4,
+  "collapsed": false,
+  "collapsible": false,
+  "className": "menuSection"
+}

docs/gov/community/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Community",
+  "position": 2,
+  "collapsed": true
+}

docs/gov/community/staking-masters.md

@@ -0,0 +1,8 @@
+---
+description: Information about the Staking Mastery Program
+sidebar_position: 1
+---
+
+# Staking Mastery Program
+
+Information about the Staking Mastery Program can be found at https://squadstaking.com/mastery.