chore: fix sidebar index links (#3942)

Make the index page clickable for each section. The pretty [docusaurus categories shorthand](https://docusaurus.io/docs/sidebar/items#category-shorthand) didn't seem to support this. --------- Co-authored-by: LHerskind <[email protected]>
AztecProtocol · Jan 11, 2024 · 984f1f8 · 984f1f8
1 parent 23bbf75
commit 984f1f8
Show file tree

Hide file tree

Showing 5 changed files with 94 additions and 36 deletions.
diff --git a/yellow-paper/docs/contract-deployment/classes.md b/yellow-paper/docs/contract-deployment/classes.md
@@ -12,7 +12,7 @@ Read the following discussions for additional context:
 - [Abstracting contract deployment](https://forum.aztec.network/t/proposal-abstracting-contract-deployment/2576)
 - [Implementing contract upgrades](https://forum.aztec.network/t/implementing-contract-upgrades/2570)
 - [Contract classes, upgrades, and default accounts](https://forum.aztec.network/t/contract-classes-upgrades-and-default-accounts/433)
-  :::
+:::
 
 ## Structure
 

diff --git a/yellow-paper/docs/cross-chain-communication/da.md b/yellow-paper/docs/cross-chain-communication/da.md
@@ -22,7 +22,7 @@ Security is often used quite in an unspecific manner, "good" security etc, witho
 
 - **Liveness**: Eventually something good will happen.
 - **Safety**: Nothing bad will happen.
-  :::
+:::
 
 In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node. For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)):
 

diff --git a/yellow-paper/docs/cross-chain-communication/index.md b/yellow-paper/docs/cross-chain-communication/index.md
@@ -11,7 +11,7 @@ The purpose of the L1 contracts are simple:
 
 - Facilitate cross-chain communication such that L1 liquidity can be used on L2
 - Act as a validating light node for L2 that every L1 node implicitly run
-  :::
+:::
 
 ## Overview
 

diff --git a/yellow-paper/docs/decentralization/block-production.md b/yellow-paper/docs/decentralization/block-production.md
@@ -29,7 +29,7 @@ We should probably introduce the PXE somewhere
 - **Network**: 40KB for a transaction with proof (see [P2P network](./p2p-network.md#network-bandwidth)). Assuming gossiping grows the data upload/download 10x, ~400KB per tx. With 10 tx/s that's 4MB/s or 32mb/s.
 - **Storage**: [~1548 bytes per transaction](../cross-chain-communication/da.md#aztec-specific-data) + tree overhead, ~ 0.4 TB per year.
 - **RAM**: Help
-  :::
+:::
 
 ### Sequencers
 
@@ -113,7 +113,7 @@ Anyone ->> Network: eligible as a sequencer
 - In Diagram
   - add a dedicated timeline from the block production's PoV
   - get rid of "pre-confirmed"
-    :::
+:::
 
 ![Governance Summary Image](./images/Aztec-Block-Production-1.png)
 

diff --git a/yellow-paper/sidebars.js b/yellow-paper/sidebars.js
@@ -21,35 +21,55 @@ const sidebars = {
   yellowPaperSidebar: [
     "intro",
     {
-      "Addresses & keys": [
-        "addresses-and-keys/index",
+      label: "Addresses & Keys",
+      type: "category",
+      link: { type: "doc", id: "addresses-and-keys/index" },
+      items: [
         "addresses-and-keys/specification",
         "addresses-and-keys/precompiles",
         "addresses-and-keys/diversified-and-stealth",
       ],
-      State: [
-        "state/index",
+    },
+    {
+      label: "State",
+      type: "category",
+      link: { type: "doc", id: "state/index" },
+      items: [
         "state/tree-implementations",
         "state/archive",
         "state/note-hash-tree",
         "state/nullifier-tree",
         "state/public-data-tree",
       ],
-      Transactions: [
-        "transactions/index",
+    },
+    {
+      label: "Transactions",
+      type: "category",
+      link: { type: "doc", id: "transactions/index" },
+      items: [
         "transactions/local-execution",
         "transactions/public-execution",
         "transactions/tx-object",
         "transactions/validity",
       ],
-      Bytecode: ["bytecode/index"],
-      "Contract Deployment": [
-        "contract-deployment/index",
-        "contract-deployment/classes",
-        "contract-deployment/instances",
-      ],
-      Calls: [
-        "calls/index",
+    },
+    {
+      label: "Bytecode",
+      type: "category",
+      link: { type: "doc", id: "bytecode/index" },
+      items: [],
+    },
+    {
+      label: "Contract Deployment",
+      type: "category",
+      link: { type: "doc", id: "contract-deployment/index" },
+      items: ["contract-deployment/classes", "contract-deployment/instances"],
+    },
+    {
+      label: "Calls",
+      type: "category",
+      link: { type: "doc", id: "calls/index" },
+      items: [
         "calls/sync-calls",
         "calls/enqueued-calls",
         "calls/batched-calls",
@@ -58,32 +78,62 @@ const sidebars = {
         "calls/unconstrained-calls",
         "calls/public-private-messaging",
       ],
-      "Cross-chain communication": [
-        "cross-chain-communication/index",
-        "cross-chain-communication/da",
-      ],
-      Logs: ["logs/index"],
-      "Private Message Delivery": [
-        "private-message-delivery/index",
+    },
+    {
+      label: "Cross-chain communication",
+      type: "category",
+      link: { type: "doc", id: "cross-chain-communication/index" },
+      items: ["cross-chain-communication/da"],
+    },
+    {
+      label: "Logs",
+      type: "category",
+      link: { type: "doc", id: "logs/index" },
+      items: [],
+    },
+    {
+      label: "Private Message Delivery",
+      type: "category",
+      link: { type: "doc", id: "private-message-delivery/index" },
+      items: [
         "private-message-delivery/private-msg-delivery", // renamed to avoid routing problems
         "private-message-delivery/note-discovery",
         "private-message-delivery/encryption-and-decryption",
         "private-message-delivery/registry",
         "private-message-delivery/send-note-guidelines",
       ],
-      "Gas & Fees": ["gas-and-fees/gas-and-fees"],
-      Decentralization: [
+    },
+    {
+      label: "Gas & Fees",
+      type: "category",
+      link: { type: "doc", id: "gas-and-fees/gas-and-fees" },
+      items: [],
+    },
+    {
+      label: "Decentralization",
+      type: "category",
+      link: { type: "doc", id: "decentralization/governance" },
+      items: [
         "decentralization/governance",
         "decentralization/block-production",
         "decentralization/p2p-network",
       ],
-      Cryptography: [
+    },
+    {
+      label: "Cryptography",
+      type: "category",
+      link: { type: "doc", id: "cryptography/performance-targets" },
+      items: [
         "cryptography/performance-targets",
         "cryptography/protocol-overview",
       ],
-      // Protocol Statements?
-      Circuits: [
-        "circuits/high-level-topology",
+    },
+    // Protocol Statements?
+    {
+      label: "Circuits",
+      type: "category",
+      link: { type: "doc", id: "circuits/high-level-topology" },
+      items: [
         "circuits/private-function",
         "circuits/private-kernel-initial",
         "circuits/private-kernel-inner",
@@ -93,14 +143,22 @@ const sidebars = {
         "circuits/public-kernel-inner",
         "circuits/public-kernel-tail",
       ],
-      "Rollup Circuits": [
-        "rollup-circuits/index",
+    },
+    {
+      label: "Rollup Circuits",
+      type: "category",
+      link: { type: "doc", id: "rollup-circuits/index" },
+      items: [
         "rollup-circuits/base-rollup",
         "rollup-circuits/merge-rollup",
         "rollup-circuits/root-rollup",
       ],
-      "Public VM": [
-        "public-vm/avm",
+    },
+    {
+      label: "Public VM",
+      type: "category",
+      link: { type: "doc", id: "public-vm/avm" },
+      items: [
         "public-vm/alu",
         "public-vm/bytecode-validation-circuit",
         "public-vm/control-flow",
-Original file line number
+Diff line change
@@ Expand Up @@
     - **Liveness**: Eventually something good will happen.
     - **Safety**: Nothing bad will happen.
-      :::
+    :::
     In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node. For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)):
@@ Expand Down @@