feat(docs): core refactor done

docs/.gitignore

@@ -22,7 +22,6 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
-docs/developers/contracts/references/aztec-nr
-src/preprocess/developers
+docs/reference/reference/smart_contract_reference/aztec-nr
 
 /src/preprocess/AztecnrReferenceAutogenStructure.json

docs/docs/aztec/_category_.json

@@ -1,6 +1,5 @@
 {
-    "label": "What is Aztec",
-    "position": 1,
+    "position": 0,
     "collapsible": true,
     "collapsed": true
 }

docs/docs/aztec/aztec/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "Aztec",
+    "position": 0,
+    "collapsible": true,
+    "collapsed": false
+}

docs/old_docs/learn/concepts/accounts/main.md → docs/docs/aztec/aztec/concepts/accounts/index.md

@@ -1,5 +1,6 @@
 ---
 title: Accounts
+sidebar_position: 0
 ---
 
 **Every account in Aztec is a smart contract** which defines the rules for whether a transaction is or is not valid. This allows implementing different schemes for transaction signing, nonce management, and fee payments. However, encryption and nullifying keys, which are specific to private blockchains, are still enshrined at the protocol level.

docs/old_docs/learn/concepts/circuits/main.md → docs/docs/aztec/aztec/concepts/circuits/index.md

@@ -1,5 +1,6 @@
 ---
 title: Circuits
+sidebar_position: 7
 ---
 
 Central to Aztec's operations are 'circuits' derived both from the core protocol and the developer-written Aztec.nr contracts.

docs/docs/aztec/aztec/concepts/nodes_clients/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "Nodes and Clients",
+    "position": 8,
+    "collapsible": true,
+    "collapsed": true
+}

docs/old_docs/learn/concepts/pxe/main.md → docs/docs/aztec/aztec/concepts/pxe/index.md

@@ -1,5 +1,6 @@
 ---
 title: Private Execution Environment (PXE)
+sidebar_position: 6
 ---
 
 The Private Execution Environment (or PXE, pronounced 'pixie') is a client-side library for the execution of private operations. It is a TypeScript library and can be run within Node, such as when you run the sandbox, within the browser, or any other environment in which TypeScript can run. For example, in future it could be run inside wallet software.
@@ -67,4 +68,4 @@ Oracles are pieces of data that are injected into a smart contract function from
 ## For developers
 To learn how to develop on top of the PXE, refer to these guides:
 * [Run more than one PXE on your local machine](../../../developers/sandbox/guides/run_more_than_one_pxe_sandbox.md)
-* [Use in-built oracles including oracles for arbitrary data](../../../developers/contracts/writing_contracts/oracles/pop_capsule.md)
+* [Use in-built oracles including oracles for arbitrary data](../../../developers/contracts/writing_contracts/oracles/pop_capsule.md)

docs/old_docs/learn/concepts/communication/cross_chain_calls.md → docs/docs/aztec/aztec/concepts/smart_contracts/communication/cross_chain_calls.md

@@ -4,13 +4,13 @@ title: L1 <--> L2 communication
 
 import Image from "@theme/IdealImage";
 
-import Disclaimer from "../../../misc/common/\_disclaimer.mdx";
+import Disclaimer from "../../../../../../src/components/Disclaimers/\_wip_disclaimer.mdx";
 
 <Disclaimer />
 
 In Aztec, what we call _portals_ are the key element in facilitating communication between L1 and L2. While typical L2 solutions rely on synchronous communication with L1, Aztec's privacy-first nature means this is not possible. You can learn more about why in the previous section.
 
-Traditional L1 <-> L2 communication might involve direct calls between L2 nd L1 contracts. However, in Aztec, due to the privacy components and the way transactions are processed (kernel proofs built on historical data), direct calls between L1 and L2 would not be possible if we want to maintain privacy.
+Traditional L1 \<-\> L2 communication might involve direct calls between L2 nd L1 contracts. However, in Aztec, due to the privacy components and the way transactions are processed (kernel proofs built on historical data), direct calls between L1 and L2 would not be possible if we want to maintain privacy.
 
 Portals are the solution to this problem, acting as bridges for communication between the two layers. These portals can transmit messages from public functions in L1 to private functions in L2 and vice versa, thus enabling messaging while maintaining privacy.
 

docs/old_docs/learn/concepts/communication/main.md → docs/docs/aztec/aztec/concepts/smart_contracts/communication/index.md

@@ -1,9 +1,10 @@
 ---
 title: Contract Communication
+sidebar_position: 5
 ---
 
 This section will walk over communication types that behaves differently than normal function calls.
 
-Namely, if functions are in different domains, private vs. public, their execution behaves a little differently to what you might expect! See [Private <--> Public execution](./public_private_calls.md).
+Namely, if functions are in different domains, private vs. public, their execution behaves a little differently to what you might expect! See [Private \<--\> Public execution](./public_private_calls.md).
 
-Likewise, executing a function on a different domain than its origin needs a bit extra thought. See [L1 <--> L2 communication](./cross_chain_calls.md).
+Likewise, executing a function on a different domain than its origin needs a bit extra thought. See [L1 \<--\> L2 communication](./cross_chain_calls.md).

docs/old_docs/learn/concepts/communication/public_private_calls.md → docs/docs/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md

@@ -4,7 +4,7 @@ title: Private <> Public Communication
 
 import Image from "@theme/IdealImage";
 
-import Disclaimer from "../../../misc/common/\_disclaimer.mdx";
+import Disclaimer from "../../../../../../src/components/Disclaimers/\_wip_disclaimer.mdx";
 
 <Disclaimer/>
 

docs/old_docs/learn/concepts/smart_contracts/contract_creation.md → docs/docs/aztec/aztec/concepts/smart_contracts/contract_creation.md

@@ -2,9 +2,8 @@
 title: Contract Creation
 ---
 
-<!-- TODO: Mike to update -->
 
-import Disclaimer from '../../../misc/common/\_disclaimer.mdx';
+import Disclaimer from '../../../../../src/components/Disclaimers/\_wip_disclaimer.mdx';
 
 <Disclaimer/>
 
@@ -164,7 +163,7 @@ To prevent duplicate contract addresses existing, a 'nullifier' is submitted whe
 
 In order to link a `contractAddress`, with a leafIndex in the `contractTree`, we reserve the storageSlot `0` of each contract's public data tree storage to store that leafIndex.
 
-The `contractAddress` is stored within the contract's leaf of the `contractTree`, so that the private kernel circuit may validate contract address <--> vk relationships.
+The `contractAddress` is stored within the contract's leaf of the `contractTree`, so that the private kernel circuit may validate contract address \<--\> vk relationships.
 
 > Aside: It would have been neat for a contract's address to be the leaf index of its mini Merkle tree (i.e. the root of the `vkTree`) in the`contractTree`. However, the leaf index is only known at the time the rollup provider runs the 'contract deployment kernel snark', whereas we need the contract address to be known earlier, at the time the deployer generates the private constructor proof. Without a contract address, the private constructor would not be able to: call other functions (and pass them a valid callContext); or silo newly-created commitments.
 

docs/old_docs/developers/contracts/writing_contracts/functions/context.md → docs/docs/aztec/aztec/concepts/smart_contracts/functions/context.md

@@ -1,9 +1,7 @@
 ---
-## title: Function Context
+title: Understanding Function Context
 ---
 
-# The Function Context
-
 ## What is the context
 
 The context is an object that is made available within every function in `Aztec.nr`. As mentioned in the [kernel circuit documentation](../../../../learn/concepts/circuits/kernels/private_kernel.md). At the beginning of a function's execution, the context contains all of the kernel information that application needs to execute. During the lifecycle of a transaction, the function will update the context with each of it's side effects (created notes, nullifiers etc.). At the end of a function's execution the mutated context is returned to the kernel to be checked for validity.
@@ -90,7 +88,7 @@ The `args_hash` is the result of pedersen hashing all of a function's inputs.
 
 The return values are a set of values that are returned from an applications execution to be passed to other functions through the kernel. Developers do not need to worry about passing their function return values to the `context` directly as `Aztec.nr` takes care of it for you. See the documentation surrounding `Aztec.nr` [macro expansion](./inner_workings.md#after-expansion) for more details.
 
-    return_values : BoundedVec<Field, RETURN_VALUES_LENGTH>,
+    return_values : BoundedVec\<Field, RETURN_VALUES_LENGTH\>,
 
 ## Max Block Number
 

docs/old_docs/developers/contracts/writing_contracts/functions/main.md → docs/docs/aztec/aztec/concepts/smart_contracts/functions/index.md

@@ -1,5 +1,5 @@
 ---
-title: Functions
+title: Defining Functions
 ---
 
 Functions serve as the building blocks of smart contracts. Functions can be either **public**, ie they are publicly available for anyone to see and can directly interact with public state, or **private**, meaning they are executed completely client-side in the [PXE](../../../../learn/concepts/pxe/main.md). Read more about how private functions work [here](./inner_workings.md#private-functions).

docs/old_docs/learn/concepts/smart_contracts/main.md → docs/docs/aztec/aztec/concepts/smart_contracts/index.md

@@ -1,5 +1,6 @@
 ---
 title: Smart Contracts
+sidebar_position: 3
 ---
 
 Smart contracts in Aztec are privacy-first, and can include both public and private elements. They are written in Noir framework called Aztec.nr, and allow high-level programs to be converted into ZK circuits.

docs/old_docs/developers/contracts/writing_contracts/oracles/main.md → docs/docs/aztec/aztec/concepts/smart_contracts/oracles/index.md

@@ -19,3 +19,15 @@ Oracles introduce **non-determinism** into a circuit, and thus are `unconstraine
 
 `Aztec.nr` has a module dedicated to its oracles. If you are interested, you can view them by following the link below:
 #include_code oracles-module /noir-projects/aztec-nr/aztec/src/oracle.nr rust
+
+## Inbuilt oracles
+
+- [`debug_log`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/debug_log.nr) - Provides a couple of debug functions that can be used to log information to the console. Read more about debugging [here](../../../debugging/main.md#logging-in-aztecnr).
+- [`auth_witness`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/authwit/src/auth_witness.nr) - Provides a way to fetch the authentication witness for a given address. This is useful when building account contracts to support approve-like functionality.
+- [`get_l1_to_l2_message`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/get_l1_to_l2_message.nr) - Useful for application that receive messages from L1 to be consumed on L2, such as token bridges or other cross-chain applications.
+- [`notes`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/notes.nr) - Provides a lot of functions related to notes, such as fetches notes from storage etc, used behind the scenes for value notes and other pre-build note implementations.
+- [`logs`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/logs.nr) - Provides the to log encrypted and unencrypted data.
+
+Find a full list [on GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr/aztec/src/oracle).
+
+Please note that it is **not** possible to write a custom oracle for your dapp. Oracles are implemented in the PXE, so all users of your dapp would have to use a PXE service with your custom oracle included. If you want to inject some arbitrary data that does not have a dedicated oracle, you can use [popCapsule](./pop_capsule.md).

docs/old_docs/learn/concepts/hybrid_state/main.md → docs/docs/aztec/aztec/concepts/state_model/index.md

@@ -1,5 +1,6 @@
 ---
 title: State Model
+sidebar_position: 4
 ---
 
 Aztec has a hybrid public/private state model. Aztec contract developers can specify which data is public and which data is private, as well as the functions that can operate on that data.

docs/old_docs/learn/concepts/hybrid_state/public_vm.md → docs/docs/aztec/aztec/concepts/state_model/public_vm.md

@@ -120,14 +120,6 @@ ACIR opcodes do not directly map to constraints; they map to subroutines compose
 
 The subroutine constraints for a given opcode is described by _microcode_.
 
-<!-- The ACIR opcode specification is fixed for a given version of ACIR.
-
-The VM microcode specification is fixed for a given VM version.
-
-i.e. the same opcode stream can produce different microcode constraint depending on the VM version. This decouples the VM from ACIR and allows for VM optimizations w/o changing the ACIR spec.
-
-TODO: this would be nice but I don't think it's possible?!
--->
 
 A **program instruction** is a tuple of:
 
@@ -175,7 +167,7 @@ VM-specific precomputed lookup tables
 
 | $\vec{T}_{Q}$                             | Lookup Relation                                                                                                             |
 | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
-| Maps instruction value to selector values | $\{ q_1, q_2, q_3, q_4, q_m, q_c, q_{sort}, \\ q_{plookup}, q_{plookup\_index}, q_{arith}, q_{ecc}, q_{aux} \} \\ = T_Q[I]$ |
+| Maps instruction value to selector values | $\{ q_1, q_2, q_3, q_4, q_m, q_c, q_{sort}, \\ q_{plookup}, q_{plookup_index}, q_{arith}, q_{ecc}, q_{aux} \} \\ = T_Q[I]$ |
 
 | $T_{G}$                           | Lookup Relation                |
 | --------------------------------- | ------------------------------ |
@@ -236,7 +228,7 @@ Why this is a public-function-only abstraction.
 
 The following UltraPlonk/Honk selectors are now witness commitments! (The $\vec{Q}$ columns)
 
-$$q_1, q_2, q_3, q_4, q_m, q_c, q_{sort}, q_{plookup}, q_{plookup\_index}, q_{arith}, q_{ecc}, q_{aux}$$
+$$q_1, q_2, q_3, q_4, q_m, q_c, q_{sort}, q_{plookup}, q_{plookup_index}, q_{arith}, q_{ecc}, q_{aux}$$
 
 Additional witness commitments required that are not part of UltraPlonk/Honk:
 

docs/old_docs/learn/concepts/storage/storage_slots.md → docs/docs/aztec/aztec/concepts/storage/index.md

@@ -1,6 +1,7 @@
 ---
-title: Storage Slots
+title: Storage
 description: How are storage slots derived for public and private state
+sidebar_position: 2
 ---
 
 In Aztec, private data and public data are stored in two trees; a public data tree and a note hashes tree. 

docs/old_docs/learn/concepts/storage/trees/main.md → docs/docs/aztec/aztec/concepts/storage/trees/index.md

@@ -49,8 +49,6 @@ If an app needs to edit a private state variable (which will be represented by o
 
 <Image img={require("/img/note-hash-tree.png")} />
 
-<!-- TODO: consider separating Note and Nullifier examples into their own doc, because it's actually a very large topic in itself, and can be expanded upon in much more detail than shown here. -->
-
 ### Example Note
 
 An example blob of data might be defined in an Aztec.nr Contract as:
@@ -144,7 +142,7 @@ A note cannot actually be "deleted" from the Note Hash Tree because it is an app
 
 #### Initializing Notes wrapped by PrivateMutable
 
-Notes wrapped 'PrivateMutable' have the following meaning: "A single Note which contains the whole of a private state's current value, and must be deleted and replaced with another single Note, if one ever wishes to edit that state". It's in contrast to a Note which only contains a small fragment of a private state's current value. A token balance represented by multiple notes is an example of private state that uses many notes. <!-- TODO: write about fragmented private state, somewhere. -->
+Notes wrapped 'PrivateMutable' have the following meaning: "A single Note which contains the whole of a private state's current value, and must be deleted and replaced with another single Note, if one ever wishes to edit that state". It's in contrast to a Note which only contains a small fragment of a private state's current value. A token balance represented by multiple notes is an example of private state that uses many notes.
 
 Such notes require an 'Initialization Nullifier'; a nullifier which, when emitted, signals the initialization of this state variable (i.e. the very first time the state variable has been written to).
 

docs/old_docs/learn/concepts/storage/trees/indexed_merkle_tree.md → docs/docs/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx

@@ -18,7 +18,15 @@ This page will answer:
 
 The content was also covered in a presentation for the [Privacy + Scaling Explorations team at the Ethereum Foundation](https://pse.dev/).
 
-<iframe width="100%" height="720" src="https://www.youtube-nocookie.com/embed/x_0ZhUKtWSs?si=TmguEhgz4Gu07Dac" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+<iframe
+  width="100%"
+  height="720"
+  src="https://www.youtube-nocookie.com/embed/x_0ZhUKtWSs?si=TmguEhgz4Gu07Dac"
+  title="YouTube video player"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
+  allowfullscreen
+></iframe>
 
 ## Primer on Nullifier Trees
 
@@ -376,4 +384,4 @@ Despite offering large performance improvements within the circuits, these come
 
 #### Closing Notes
 
-We have been working with these new trees in order to reduce the proving time for our rollups in Aztec, however we think EVERY protocol leveraging nullifier trees should know about these trees as their performance benefit is considerable.
+We have been working with these new trees in order to reduce the proving time for our rollups in Aztec, however we think EVERY protocol leveraging nullifier trees should know about these trees as their performance benefit is considerable. \*/}

docs/old_docs/learn/concepts/transactions.md → docs/docs/aztec/aztec/concepts/transactions.md

@@ -1,5 +1,6 @@
 ---
 title: Transactions
+sidebar_position: 3
 ---
 
 import Image from '@theme/IdealImage';

docs/docs/aztec/aztec/concepts/wallets/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "Wallets",
+    "position": 1,
+    "collapsible": true,
+    "collapsed": false
+}

docs/old_docs/developers/wallets/architecture.md → docs/docs/aztec/aztec/concepts/wallets/architecture.md

@@ -1,5 +1,5 @@
 ---
-title: Architecture
+title: Wallet Architecture
 ---
 
 This page talks about the architecture of a wallet in Aztec. 

docs/docs/aztec/aztec/what_is_aztec/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "What is Aztec",
+    "position": 0,
+    "collapsible": true,
+    "collapsed": true
+}

docs/old_docs/learn/about_aztec/technical_overview.md → docs/docs/aztec/aztec/what_is_aztec/core_components.md

@@ -1,5 +1,6 @@
 ---
 title: Core Components
+sidebar_position: 2
 ---
 
 Aztec Labs is building a layer 2 rollup on Ethereum focused on 3 things:
@@ -12,8 +13,6 @@ Aztec Labs is building a layer 2 rollup on Ethereum focused on 3 things:
 
 Data privacy refers to the ability of Aztec smart contract to have private (encrypted) state. Aztec abstracts away many of the complexities associated with managing private state, providing developers with an interface that feels familiar, but is much more powerful.
 
-<!-- Discuss UTXOs, Notes, note tree, nullifier tree? -->
-
 ## Confidentiality
 
 Confidentiality is the ability of Aztec smart contracts to execute private functions and transactions. Aztec provides a secure, private environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications.

docs/old_docs/misc/how_to_contribute.md → docs/docs/aztec/aztec/what_is_aztec/how_to_participate.md

@@ -1,5 +1,6 @@
 ---
 title: How to Participate?
+sidebar_position: 4
 ---
 
 Decentralization is one of our core values, so we want to encourage participation as much as possible and in any way you can.

docs/old_docs/learn/about_aztec/what_is_aztec.mdx → docs/docs/aztec/aztec/what_is_aztec/index.md

@@ -1,7 +1,9 @@
 ---
-title: What is Aztec?
+title: Aztec
+sidebar_position: 0
 ---
 
+import Disclaimer from "../../../../src/components/Disclaimers/\_wip_disclaimer.mdx";
 import ReactPlayer from "react-player/youtube";
 
 Aztec is an L2 that brings programmable privacy to Ethereum.
@@ -60,5 +62,4 @@ To support Aztec's rollup, our cryptography team is building [Honk](https://gith
 
 Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network) or [Discord server](https://discord.gg/DgWG2DBMyB).
 
-import Disclaimer from "../../misc/common/_disclaimer.mdx";
 <Disclaimer />;

docs/old_docs/developers/limitations/main.md → docs/docs/aztec/aztec/what_is_aztec/limitations.md

@@ -1,5 +1,6 @@
 ---
 title: Limitations
+sidebar_position: 6
 ---
 
 The Aztec Sandbox and the Aztec Smart Contract Library are **prototypes**, and should be treated as such. They've been released early, to gather feedback on the capabilities of the protocol and user experiences.

docs/old_docs/developers/privacy/main.md → docs/docs/aztec/aztec/what_is_aztec/privacy_considerations.md

@@ -1,4 +1,7 @@
-# Privacy Considerations
+---
+title: Privacy Considerations
+sidebar_position: 5
+---
 
 Privacy is important.
 

docs/docs/aztec/aztec/what_is_aztec/roadmap/_category_.json

@@ -0,0 +1,5 @@
+{
+    "position": 3,
+    "collapsible": true,
+    "collapsed": true
+}

docs/old_docs/misc/roadmap/cryptography_roadmap.md → docs/docs/aztec/aztec/what_is_aztec/roadmap/cryptography_roadmap.md

@@ -1,5 +1,7 @@
 ---
 title: Cryptography Roadmap
+sidebar_position: 2
+---
 ---
 
 The cryptography team is currently working on [Barretenberg here.](https://github.com/AztecProtocol/aztec-packages/tree/master/barretenberg)

docs/old_docs/misc/roadmap/engineering_roadmap.md → docs/docs/aztec/aztec/what_is_aztec/roadmap/engineering_roadmap.md

@@ -1,4 +1,7 @@
-# Engineering Wishlist
+---
+title: Engineering Roadmap
+sidebar_position: 1
+---
 
 The engineering roadmap is long. There are no timings assigned here. In a loose priority order:
 
@@ -26,8 +29,8 @@ The engineering roadmap is long. There are no timings assigned here. In a loose
 - Private NFTs
 - Public tokens
 - Depositing and withdrawing tokens
-  - L1<\>L2
-  - public<\>private
+  - L1\<\>L2
+  - public\<\>private
 - The Aztec Connect bridging pattern
 - Using Keys (the fully-featured version of keys that we want to build)
 - Plume nullifiers

docs/old_docs/misc/roadmap/features_initial_ldt.md → docs/docs/aztec/aztec/what_is_aztec/roadmap/features_initial_ldt.md

@@ -1,5 +1,6 @@
 ---
-title: Sandbox Features
+title: Sandbox
+sidebar_position: 0
 ---
 
 The Aztec Sandbox is intended to provide developers with a lightweight and fast local node, running alongside a PXE.

docs/docs/aztec/vision.mdx → docs/docs/aztec/aztec/what_is_aztec/vision.md

@@ -1,8 +1,9 @@
 ---
 title: Vision
+sidebar_position: 1
 ---
 
-import Disclaimer from "../../src/components/Disclaimers/\_wip_disclaimer.mdx";
+import Disclaimer from "../../../../src/components/Disclaimers/\_wip_disclaimer.mdx";
 
 ## The world's encrypted ledger