chore(docs): restructure improvs (#6502)

In line with the latest restructure, here are some QoL things we pointed
out to be iterated:

- [x]  Added back api docs to their rightful place
- [x]  Removed nested structure to make links smaller
- [x]  Refactored all the links to reflect the above

## To do in a later PR:

- [ ] Rewrite URLs to be relative

docs/.gitignore

@@ -22,6 +22,5 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
-docs/reference/reference/smart_contract_reference/aztec-nr
-
-/src/preprocess/AztecnrReferenceAutogenStructure.json
+docs/reference/aztecjs
+docs/reference/smart_contract_reference/aztec-nr

docs/docs/aztec/aztec/index.md → docs/docs/aztec.md

@@ -3,7 +3,7 @@ title: Aztec
 sidebar_position: 0
 ---
 
-import Disclaimer from "../../../src/components/Disclaimers/\_wip_disclaimer.mdx";
+import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx";
 import ReactPlayer from "react-player/youtube";
 
 Aztec is an L2 that brings programmable privacy to Ethereum.
@@ -52,7 +52,7 @@ Contributors to Aztec uphold many of the values of the Ethereum community -- bui
 
 Noir is a domain specific programming language for writing zero-knowledge circuits. On Aztec a smart contract is a collection of circuits that developers write using Noir.
 
-You can find more information and resources for learning about Noir smart contracts on [this page](/aztec/aztec/concepts/smart_contracts/index.md).
+You can find more information and resources for learning about Noir smart contracts on [this page](/aztec/concepts/smart_contracts/index.md).
 
 ## Cryptography
 

docs/docs/aztec/_category_.json

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

docs/docs/aztec/aztec/concepts/accounts/authwit.md → docs/docs/aztec/concepts/accounts/authwit.md

@@ -54,9 +54,9 @@ All of these issues have been discussed in the community for a while, and there
 
 Adopting ERC20 for Aztec is not as simple as it might seem because of private state.
 
-If you recall from the [Hybrid State model](/aztec/aztec/concepts/state_model/index.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
+If you recall from the [Hybrid State model](/aztec/concepts/state_model/index.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
 
-If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](/aztec/aztec/concepts/accounts/keys.md). 
+If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](/aztec/concepts/accounts/keys.md). 
 
 While this might sound limiting in what we can actually do, the main use of approvals have been for simplifying contract interactions that the user is doing. In the case of private transactions, this is executed on the user device, so it is not a blocker that the user need to tell the executor a secret - the user is the executor!
 ### So what can we do?
@@ -178,7 +178,7 @@ For the transfer, this could be done simply by appending a nonce to the argument
 action = H(defi, token, transfer_selector, H(alice_account, defi, 1000, nonce));
 ```
 
-Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md).
+Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](guides/smart_contracts/writing_contracts/common_patterns/authwit.md).
 
 ### Differences to approval
 
@@ -192,4 +192,4 @@ We don't need to limit ourselves to the `transfer` function, we can use the same
 
 ### Next Steps
 
-Check out the [developer documentation](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md) to see how to implement this in your own contracts.
+Check out the [developer documentation](guides/smart_contracts/writing_contracts/common_patterns/authwit.md) to see how to implement this in your own contracts.

docs/docs/aztec/aztec/concepts/accounts/index.md → docs/docs/aztec/concepts/accounts/index.md

@@ -71,7 +71,7 @@ def entryPoint(payload):
         enqueueCall(to, data, value, gasLimit);
 ```
 
-Read more about how to write an account contract [here](/tutorials/tutorials/write_accounts_contract.md).
+Read more about how to write an account contract [here](/tutorials/write_accounts_contract.md).
 
 ### Account contracts and wallets
 
@@ -134,7 +134,7 @@ These two patterns combined allow an account contract to answer whether an actio
 
 Aztec requires users to define [encryption and nullifying keys](./keys.md) that are needed for receiving and spending private notes. Unlike transaction signing, encryption and nullifying is enshrined at the protocol. This means that there is a single scheme used for encryption and nullifying. These keys are derived from a master public key. This master public key, in turn, is used when deterministically deriving the account's address.
 
-A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of [`SharedMutable`](/reference/reference/smart_contract_reference/storage/shared_state.md#sharedmutable) to enable rotating these keys.
+A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of [`SharedMutable`](/reference/smart_contract_reference/storage/shared_state.md#sharedmutable) to enable rotating these keys.
 
 NOTE: While we entertained the idea of abstracting note encryption, where account contracts would define an `encrypt` method that would use a user-defined scheme, there are two main reasons we decided against this. First is that this entailed that, in order to receive funds, a user had to first deploy their account contract, which is a major UX issue. Second, users could define malicious `encrypt` methods that failed in certain circumstances, breaking application flows that required them to receive a private note. While this issue already exists in Ethereum when transferring ETH (see the [king of the hill](https://coinsbench.com/27-king-ethernaut-da5021cd4aa6)), its impact is made worse in Aztec since any execution failure in a private function makes the entire transaction unprovable (ie it is not possible to catch errors in calls to other private functions), and furthermore because encryption is required for any private state (not just for transferring ETH). Nevertheless, both of these problems are solvable. Initialization can be worked around by embedding a commitment to the bytecode in the address and removing the need for actually deploying contracts before interacting with them, and the king of the hill issue can be mitigated by introducing a full private VM that allows catching reverts. As such, we may be able to abstract encryption in the future as well.
 

docs/docs/aztec/aztec/concepts/accounts/keys.md → docs/docs/aztec/concepts/accounts/keys.md

@@ -20,7 +20,7 @@ Instead it's up to the account contract developer to implement it.
 :::
 
 ## Public keys retrieval
-The keys can either be retrieved from a key registry contract or from the [Private eXecution Environment (PXE)](/aztec/aztec/concepts/pxe/index.md).
+The keys can either be retrieved from a key registry contract or from the [Private eXecution Environment (PXE)](/aztec/concepts/pxe/index.md).
 
 :::note
 The key registry is a canonical contract used to store user public keys.
@@ -40,7 +40,7 @@ Below are some ways how we could instantiate it after getting the information in
 
 #include_code instantiate-complete-address /yarn-project/circuits.js/src/structs/complete_address.test.ts rust
 
-Then to register the recipient's [complete address](#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/aztec/core_components.md#aztecjs):
+Then to register the recipient's [complete address](#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/core_components.md#aztecjs):
 
 #include_code register-recipient /yarn-project/aztec.js/src/wallet/create_recipient.ts rust
 
@@ -116,7 +116,7 @@ This is a snippet of our Schnorr Account contract implementation, which uses Sch
 
 #include_code entrypoint /noir-projects/noir-contracts/contracts/schnorr_account_contract/src/main.nr rust
 
-Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](/tutorials/tutorials/write_accounts_contract.md) for a full example of how to manage authentication.
+Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](/tutorials/write_accounts_contract.md) for a full example of how to manage authentication.
 
 Furthermore, and since signatures are fully abstracted, how the key is stored in the contract is abstracted as well and left to the developer of the account contract.
 In the following section we describe a few ways how an account contract could be architected to store signing keys.
@@ -133,7 +133,7 @@ Similar to using a private note, but using an immutable private note removes the
 
 #### Using shared state
 
-A compromise between the two solutions above is to use [shared state](/reference/reference/smart_contract_reference/storage/shared_state.md). This would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays.
+A compromise between the two solutions above is to use [shared state](/reference/smart_contract_reference/storage/shared_state.md). This would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays.
 
 #### Reusing some of the in-protocol keys
 

docs/docs/aztec/aztec/concepts/circuits/index.md → docs/docs/aztec/concepts/circuits/index.md

@@ -52,7 +52,7 @@ In other words, since neither the EVM nor other rollups have rules for how to pr
 
 What kind of extra rules / checks does a rollup need, to enforce notions of private states and private functions? Stuff like:
 
-- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](/aztec/aztec/concepts/storage/trees/index.md)).
+- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](/aztec/concepts/storage/trees/index.md)).
 - "Hide which function was just executed, by wrapping it in a zk-snark"
 - "Hide all functions which were executed as part of this tx's stack trace, by wrapping the whole tx in a zk-snark"
 
@@ -62,12 +62,12 @@ So what kinds of core protocol circuits does Aztec have?
 
 ### Kernel Circuits
 
-- [Private Kernel Circuit](/aztec/aztec/concepts/circuits/kernels/private_kernel)
-- [Public Kernel Circuit](/aztec/aztec/concepts/circuits/kernels/public_kernel)
+- [Private Kernel Circuit](/aztec/concepts/circuits/kernels/private_kernel)
+- [Public Kernel Circuit](/aztec/concepts/circuits/kernels/public_kernel)
 
 ### Rollup Circuits
 
-- [Rollup Circuits](/aztec/aztec/concepts/circuits/rollup_circuits)
+- [Rollup Circuits](/aztec/concepts/circuits/rollup_circuits)
 
 #### Squisher Circuits
 

docs/docs/aztec/aztec/concepts/circuits/kernels/private_kernel.md → docs/docs/aztec/concepts/circuits/kernels/private_kernel.md

@@ -16,10 +16,10 @@ This circuit is executed by the user, on their own device. This is to ensure pri
   - public call stacks: hashes representing calls to other public functions;
   - events;
   - all data accumulated by all previous private kernel circuit recursions of this tx;
-- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](/aztec/aztec/concepts/storage/trees/index.md#contract-tree).
+- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](/aztec/concepts/storage/trees/index.md#contract-tree).
 - Ensures the entire stack trace of private functions (for a particular tx) adheres to function execution rules.
 - Verifies a previous 'Private Kernel Proof', recursively, when verifying transactions which are composed of many private function calls.
-- Optionally can [deploy](/aztec/aztec/concepts/smart_contracts/contract_creation.md) a new private contract.
+- Optionally can [deploy](/aztec/concepts/smart_contracts/contract_creation.md) a new private contract.
 
 > Note: **This is the only core protocol circuit which actually needs to be "zk" (zero-knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Aztec.nr Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function).
 > This is a really interesting point. Most so-called "zk-Rollups" do not make use of this "zero-knowledge" property. Their snarks are "snarks"; with no need for zero-knowledge, because they don't seek privacy; they only seek the 'succinct' computation-compression properties of snarks. Aztec's "zk-Rollup" actually makes use of "zero-knowledge" snarks. That's why we sometimes call it a "zk-zk-Rollup", or "_actual_ zk-Rollup".

docs/docs/aztec/aztec/concepts/circuits/kernels/public_kernel.md → docs/docs/aztec/concepts/circuits/kernels/public_kernel.md

@@ -2,7 +2,7 @@
 title: Public Kernel Circuit
 ---
 
-This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](/aztec/aztec/concepts/storage/trees/index.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
+This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](/aztec/concepts/storage/trees/index.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
 
 - Exposes (forwards) the following data to the next recursive circuit:
   - all data accumulated by all previous private kernel circuit recursions of this tx;

docs/docs/aztec/aztec/concepts/circuits/rollup_circuits/index.md → docs/docs/aztec/concepts/circuits/rollup_circuits/index.md

@@ -23,7 +23,7 @@ For both transactions, it:
 
 - Performs public state read membership checks.
 - Updates the public data tree in line with the requested state transitions.
-- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees).
+- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees).
 - Batch-inserts new nullifiers into the nullifier tree.
 - Batch-inserts new note hashes into the note hash tree
 - Batch-inserts any new contract deployments into the contract tree.