chore(docs): adding analytics to the refactored documentation

.github/workflows/ci.yml

@@ -390,7 +390,7 @@ jobs:
           concurrency_key: docs-preview-${{ inputs.username || github.actor }}-x86
       - name: "Docs Preview"
         timeout-minutes: 30
-        run: earthly --no-output ./docs/+deploy-preview --PR=${{ github.event.number }} --AZTEC_BOT_COMMENTER_GITHUB_TOKEN=${{ secrets.AZTEC_BOT_GITHUB_TOKEN }} --NETLIFY_AUTH_TOKEN=${{ secrets.NETLIFY_AUTH_TOKEN }} --NETLIFY_SITE_ID=${{ secrets.NETLIFY_SITE_ID }}
+        run: earthly --no-output ./docs/+deploy-preview --ENVIRONMENT=staging --PR=${{ github.event.number }} --AZTEC_BOT_COMMENTER_GITHUB_TOKEN=${{ secrets.AZTEC_BOT_GITHUB_TOKEN }} --NETLIFY_AUTH_TOKEN=${{ secrets.NETLIFY_AUTH_TOKEN }} --NETLIFY_SITE_ID=${{ secrets.NETLIFY_SITE_ID }}
 
   # push benchmarking binaries to dockerhub registry
   bb-bench-binaries:

.vscode/settings.json

@@ -165,5 +165,6 @@
     "**/target/**": true,
     "**/l1-contracts/lib/**": true,
     "**/barretenberg/cpp/build*/**": true
-  }
+  },
+  "graphite.commandPath": "/usr/local/bin/gt"
 }

boxes/README.md

@@ -8,36 +8,27 @@ Aztec Boxes are the one-stop-shop for developing on Aztec. They often include a
 
 Boxes include the sandbox installation script and its start command. By choosing the appropriate box, you can get started working on Aztec in a minimal amount of time.
 
-## Getting started
+## Contributing
 
-If you have [node](https://nodejs.org/en/download) installed, you can open a terminal in any folder and run:
+Because of the CI/CD nature of the monorepo, every box is tested against every merge on master. This drastically reduces their maintenance cost. Thus, some scripting is needed to make sure the user gets a working repository after "unboxing".
 
-`npx create-aztec-app`
+Most of the logic is in the `bin.js` file, where `commander` commands stuff. Here's a brief description on what the script exactly does:
 
-or
+- Prompts the user for options and commands
+- Inits some global variables such as a logger, a getter for the github repositories, the latest stable versions and tags, etc
+- Prompts the user to choose the project and clone it. It then rewrites the `Nargo.toml` and `package.json` files to point to the repos instead of the local dependencies.
+- Queries the local docker daemon for any existing sandbox images, prompting the user to install or update it if needed
+- Asks the user if they want to run the sandbox right away
 
-`npx create-aztec-app`
-
-The script will install the sandbox, run it, and clone the boilerplate you chose. You can pass some options:
-
-| Option | Description |
-| --- | --- |
-| -d, --debug | Displays some more information for debug reasons. |
-| -gh, --github_token | You can pass a github_token in case you hit API rate limit |
-| -v, --version | You can specify a semver version, or "MASTER" |
-| -h, --help | Shows up this help menu |
-
- If at any time you encounter problems, refer to the guides at [docs.aztec.network](https://docs.aztec.network) for more information.
 
 ## Templates
 
-Currently there are two boxes:
+As noted above, every box is tested at every merge to master. Any breaking changes need to happen in every box, so we try to keep the number of templates strategically low. For that reason, we ask contributors to reach directly to the [devrel team](https://github.com/orgs/AztecProtocol/teams/devrel) before adding another template.
+
+Currently there are two "app" boxes and one "contract-only" box:
 
 - React - A React boilerplate with a minimal UI.
 - Vanilla JS and HTML - Some say if you get something working in vanilla JS and HTML, you can make it work on any framework. If you can't find the box you need, this could be a good starting point.
-
-And one contract-only box:
-
 - Token - An example token contract on Aztec
 
 ## Support

boxes/boxes/react/README.md

@@ -2,6 +2,35 @@
 
 This box is a one-stop-shop for Aztec that will deploy a minimal React page. You can use it as a boilerplate to start developing your own Aztec app in seconds!
 
+## Getting Started
+
+The easiest way to start is with a Github Codespaces, which has a generous free tier. Just click on this button:
+
+[![One-Click React Starter](.devcontainer/assets/react_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Freact%2Fdevcontainer.json)
+
+## Using the `npx` command
+
+The above method just uses the `npx` command, AKA "unboxing the box". This is a CLI command to quickly start developing on your own machine.
+
+### Prerequisites
+
+- Node >v18
+- Docker
+
+### Usage
+
+Just open a terminal and write:
+
+```bash
+npx create-aztec-app
+```
+
+It should ask you some questions about your project, install and run the Sandbox (local developer network). You can also start, stop, update, and do other things on the sandbox through this script. Just run:
+
+```bash
+npx create-aztec-app sandbox --help
+```
+
 ## More information
 
 Visit the [Aztec Docs](https://docs.aztec.network) for more information on how Aztec works, and the [Awesome Aztec Repository](https://github.com/AztecProtocol/awesome-aztec) for more cool projects, boilerplates and tooling.

boxes/boxes/vanilla/README.md

@@ -2,6 +2,36 @@
 
 This box is a one-stop-shop for Aztec that will deploy a minimal barebones HTML+JS page. You can use it as a boilerplate to start developing your own Aztec app in seconds!
 
+
+## Getting Started
+
+The easiest way to start is with a Github Codespaces, which has a generous free tier. Just click on this button:
+
+[![One-Click HTML/TS Starter](.devcontainer/assets/vanilla_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Fvanilla%2Fdevcontainer.json)
+
+## Using the `npx` command
+
+The above method just uses the `npx` command, AKA "unboxing the box". This is a CLI command to quickly start developing on your own machine.
+
+### Prerequisites
+
+- Node >v18
+- Docker
+
+### Usage
+
+Just open a terminal and write:
+
+```bash
+npx create-aztec-app
+```
+
+It should ask you some questions about your project, install and run the Sandbox (local developer network). You can also start, stop, update, and do other things on the sandbox through this script. Just run:
+
+```bash
+npx create-aztec-app sandbox --help
+```
+
 ## More information
 
 Visit the [Aztec Docs](https://docs.aztec.network) for more information on how Aztec works, and the [Awesome Aztec Repository](https://github.com/AztecProtocol/awesome-aztec) for more cool projects, boilerplates and tooling.

boxes/contract-only/README.md

@@ -2,7 +2,36 @@
 
 This box is a one-stop-shop for Aztec with the %%contract_name%% example contract. You can use it as a boilerplate to start developing your own Aztec app in seconds!
 
-## How to start
+## Getting Started
+
+The easiest way to start is with a Github Codespaces, which has a generous free tier. Just click on this button:
+
+[![One-Click Token Starter](.devcontainer/assets/token_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Ftoken%2Fdevcontainer.json)
+
+## Using the `npx` command
+
+The above method just uses the `npx` command, AKA "unboxing the box". This is a CLI command to quickly start developing on your own machine.
+
+### Prerequisites
+
+- Node >v18
+- Docker
+
+### Usage
+
+Just open a terminal and write:
+
+```bash
+npx create-aztec-app
+```
+
+It should ask you some questions about your project, install and run the Sandbox (local developer network). You can also start, stop, update, and do other things on the sandbox through this script. Just run:
+
+```bash
+npx create-aztec-app sandbox --help
+```
+
+## What's in the box
 
 The script copied one of the example contracts and put it into a one-size-fits-all "box". With it, you can run commands such as:
 

boxes/package.json

@@ -1,9 +1,8 @@
 {
   "name": "create-aztec-app",
   "packageManager": "yarn@4.0.2",
-  "version": "0.4.2",
+  "version": "0.4.4",
   "type": "module",
-  "private": true,
   "scripts": {
     "compile": "yarn workspaces foreach -A -v run compile",
     "build": "yarn workspaces foreach -A -v run build",

boxes/scripts/steps/sandbox/run.js

@@ -4,8 +4,8 @@ import axios from "axios";
 
 const sandbox = (command) =>
   execSync(
-    `docker-compose -f $HOME/.aztec/docker-compose.yml -p sandbox ${command}`,
-    { stdio: "inherit" },
+    `docker compose -f $HOME/.aztec/docker-compose.yml -p sandbox ${command}`,
+    { stdio: "inherit" }
   );
 
 export const start = () => sandbox("up -d");
@@ -29,7 +29,7 @@ export async function sandboxRunStep() {
           Accept: "*/*",
           "Content-Type": "application/json",
         },
-      },
+      }
     );
     spinner.succeed();
     success("The Sandbox is already running!");

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/Earthfile

@@ -10,19 +10,18 @@ deps:
   RUN yarn install --frozen-lockfile
 
 build:
+  ARG ENVIRONMENT
   BUILD ../yarn-project/+build-dev
   BUILD ../+release-meta
   FROM +deps
-
   COPY --dir ../yarn-project/+build-dev/usr/src /usr
   COPY ../+release-meta/usr/src/.release-please-manifest.json /usr/src
-
   COPY . .
-
   RUN ./scripts/build.sh
   SAVE ARTIFACT build
 
 serve:
+  ARG ENVIRONMENT
   FROM +deps
   COPY +build/build build
   COPY ./static static
@@ -34,8 +33,10 @@ serve:
   SAVE ARTIFACT /usr/src/docs
   SAVE IMAGE aztecprotocol/docs-server
 
+
 deploy-preview:
   BUILD ../yarn-project/+scripts-prod
+  ARG ENVIRONMENT
   ARG NETLIFY_AUTH_TOKEN
   ARG NETLIFY_SITE_ID
   ARG AZTEC_BOT_COMMENTER_GITHUB_TOKEN
@@ -44,7 +45,7 @@ deploy-preview:
   COPY --dir ../yarn-project/+scripts-prod/usr/src/yarn-project /usr/src
   COPY ./netlify.toml .
   COPY ./deploy_preview.sh .
-  RUN NETLIFY_AUTH_TOKEN=$NETLIFY_AUTH_TOKEN NETLIFY_SITE_ID=$NETLIFY_SITE_ID ./deploy_preview.sh $PR $AZTEC_BOT_COMMENTER_GITHUB_TOKEN
+  RUN echo "NETLIFY_AUTH_TOKEN=$NETLIFY_AUTH_TOKEN NETLIFY_SITE_ID=$NETLIFY_SITE_ID ./deploy_preview.sh $PR $AZTEC_BOT_COMMENTER_GITHUB_TOKEN"
 
 deploy-prod:
   BUILD ../yarn-project/+scripts-prod

docs/docs/aztec/_category_.json

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

docs/docs/aztec/aztec/_category_.json

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

docs/docs/learn/concepts/accounts/authwit.md → docs/docs/aztec/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](../hybrid_state/main.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/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](../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/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](./../../../developers/contracts/resources/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/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](./../../../developers/contracts/resources/common_patterns/authwit.md) to see how to implement this in your own contracts.
+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.

docs/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.
@@ -127,7 +128,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`](../../../developers/contracts/references/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/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/learn/concepts/accounts/keys.md → docs/docs/aztec/aztec/concepts/accounts/keys.md

@@ -9,7 +9,7 @@ Typically, each account in Aztec is backed by two separate keys:
 
 Signing keys allow their holder to act as their corresponding account in Aztec, similarly to the keys used for an Ethereum account. If a signing key is leaked, the user can potentially lose all their funds.
 
-Since Aztec implements full [signature abstraction](./main.md), signing keys depend on the account contract implementation for each user. Usually, an account contract will validate a signature of the incoming payload against a known public key.
+Since Aztec implements full [signature abstraction](./index.md), signing keys depend on the account contract implementation for each user. Usually, an account contract will validate a signature of the incoming payload against a known public key.
 
 This is a snippet of our Schnorr Account contract implementation, which uses Schnorr signatures for authentication:
 
@@ -29,7 +29,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](../../../developers/contracts/references/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/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 the privacy master key
 
@@ -61,7 +61,7 @@ This public key corresponds to the privacy master key of the account. In order t
 Contracts that are not meant to represent a user who handles private state, usually non-account contracts such as applications, do not need to provide a valid public key, and can instead just use zero to denote that they are not expected to receive private notes.
 
 :::info
-A side effect of enshrining and encoding privacy keys into the account address is that these keys cannot be rotated if they are leaked. Read more about this in the [account abstraction section](./main.md#encryption-and-nullifying-keys).
+A side effect of enshrining and encoding privacy keys into the account address is that these keys cannot be rotated if they are leaked. Read more about this in the [account abstraction section](./index.md#encryption-and-nullifying-keys).
 :::
 
 ### Encryption keys