chore: docs restructure

docs/docs/about_aztec/how_to_contribute.md

@@ -2,19 +2,19 @@
 title: How to Participate?
 ---
 
-- Talk about how we want the Aztec network to be as decentralised as possible, hence we want to actively encourage participation.
+Decentralization is one of our core values, so we want to encourage participation as much as possible and in any way you can.
 
 ## Improve the protocol
 
-- Point to discourse forum.
+- Join us at our [Discourse forum](https://discourse.aztec.network/) to discuss all things related to Aztec and share your feedback
 
 ## Contribute code
 
-- Point to github
-- Point to 'good first issues'
-- Encourage people to open issues
+- Check out the monorepo on GitHub [here](https://github.com/AztecProtocol/aztec-packages)
+- We have some [good first issues](https://github.com/AztecProtocol/aztec-packages/labels/good%20first%20issue) for newcomers
+- Anyone can open an Issue, so please feel free to create one
 
 ## Grants
 
-- Discuss opportunities for grants
-
+- We often run grants programs to support awesome projects and teams, you can read some of our past grantees [here](https://aztecnetwork.notion.site/Aztec-Grants-Wave-3-RFPs-acba57016db048868e5ed07cbf549979?p=5b2bf249f8f44836a10e6210cbaf95c0&pm=s)
+- Keep checking back to see when we're opening up a new wave of grants

docs/docs/about_aztec/roadmap/main.md

@@ -1,5 +1,5 @@
-<!-- # Full Roadmap
+import DocCardList from '@theme/DocCardList';
 
-:::danger
-Placeholder in case we want to include the org roadmap (higher level, non-engineering).
-::: -->
+# Roadmap
+
+<DocCardList/>

docs/docs/concepts/advanced/data_structures/main.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Data Structures
+
+<DocCardList />

docs/docs/concepts/advanced/main.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Advanced Concepts
+
+<DocCardList />

docs/docs/concepts/foundation/main.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Foundational Concepts
+
+<DocCardList />

docs/docs/dev_docs/contracts/compiling.md

@@ -78,7 +78,7 @@ Read more about interacting with contracts using `aztec.js` [here](../dapps/main
 
 ### Aztec.nr interfaces
 
-An Aztec.nr contract can [call a function](./functions.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serialising the arguments, which is not type-safe.
+An Aztec.nr contract can [call a function](./syntax/functions.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serialising the arguments, which is not type-safe.
 
 To make this easier, the compiler can generate contract interface structs that expose a convenience method for each function listed in a given contract ABI. These structs are intended to be used from another contract project that calls into the current one. For each contract, two interface structs are generated: one to be used from private functions with a `PrivateContext`, and one to be used from open functions with a `PublicContext`.
 
@@ -101,7 +101,7 @@ impl PrivateTokenPrivateContextInterface {
   fn at(address: Field) -> Self {
       Self { address }
   }
-  
+
   fn mint(
     self, context: &mut PrivateContext, amount: Field, owner: Field
   ) -> [Field; RETURN_VALUES_LENGTH] {
@@ -112,7 +112,7 @@ impl PrivateTokenPrivateContextInterface {
     // 0x1dc9c3c0 is the function selector for `mint(field,field)`
     context.call_private_function(self.address, 0x1dc9c3c0, serialised_args)
   }
-  
+
 
   fn transfer(
     self, context: &mut PrivateContext, amount: Field, sender: Field, recipient: Field
@@ -128,7 +128,7 @@ impl PrivateTokenPrivateContextInterface {
 }
 ```
 
-Read more about how to use the Aztec.nr interfaces [here](./functions.md#contract-interface).
+Read more about how to use the Aztec.nr interfaces [here](./syntax/functions.md#contract-interface).
 
 :::info
 At the moment, the compiler generates these interfaces from already compiled ABIs, and not from source code. This means that you should not import a generated interface from within the same project as its source contract, or you risk circular references.
@@ -138,11 +138,10 @@ At the moment, the compiler generates these interfaces from already compiled ABI
 
 You can also programmatically access the compiler via the `@aztec/noir-compiler` package. To do this, install the package into your nodejs project:
 
-`
-npm install @aztec/noir-compiler
-`
+`npm install @aztec/noir-compiler`
 
 The compiler exposes the following functions:
+
 - `compileUsingNargo`: Compiles an Aztec.nr project in the target folder using the `nargo` binary available on the shell `PATH` and returns the generated ABIs.
 - `generateTypescriptContractInterface`: Generates a typescript class for the given contract ABI.
 - `generateNoirContractInterface`: Generates a Aztec.nr interface struct for the given contract ABI.
@@ -151,6 +150,5 @@ The compiler exposes the following functions:
 
 Once you have compiled your contracts, you can use the generated artifacts via the `Contract` class in the `aztec.js` package to deploy and interact with them, or rely on the type-safe typescript classes directly. Alternatively, use the CLI [to deploy](../../dev_docs/getting_started/cli.md#deploying-a-token-contract) and [interact](../../dev_docs/getting_started/cli.md#sending-a-transaction) with them.
 
-
 import Disclaimer from "../../misc/common/\_disclaimer.mdx";
-<Disclaimer/>
+<Disclaimer/>

docs/docs/dev_docs/contracts/events.md

@@ -1,12 +1,17 @@
-## Events
+---
+title: Events
+---
+
 Events in Aztec work similarly to Ethereum events in the sense that they are a way for contracts to communicate with the outside world.
 They are emitted by contracts and stored inside each instance of an AztecNode.
+
 > Aztec events are currently represented as raw data and are not ABI encoded.
 > ABI encoded events are a feature that will be added in the future.
 
 Unlike on Ethereum, there are 2 types of events supported by Aztec: encrypted and unencrypted.
 
 ### Encrypted Events
+
 Encrypted events can only be emitted by private functions and are encrypted using a public key of a recipient.
 For this reason it is necessary to register a recipient in the Aztec RPC Server before encrypting the events for them.
 Recipients can be registered using the Aztec CLI or Aztec.js:
@@ -25,11 +30,21 @@ aztec-cli register-recipient --address 0x147392a39e593189902458f4303bc6e0a39128c
 <TabItem value="js" label="Aztec.js">
 
 ```ts
-const aztecAddress = AztecAddress.fromString("0x147392a39e593189902458f4303bc6e0a39128c5a1c1612f76527a162d36d529");
-const publicKey = Point.fromString("0x26e193aef4f83c70651485b5526c6d01a36d763223ab24efd1f9ff91b394ac0c20ad99d0ef669dc0dde8d5f5996c63105de8e15c2c87d8260b9e6f02f72af622");
-const partialAddress = Fr.fromString("0x200e9a6c2d2e8352012e51c6637659713d336405c29386c7c4ac56779ab54fa7");
-
-const completeAddress = CompleteAddress.create(aztecAddress, publicKey, partialKey); 
+const aztecAddress = AztecAddress.fromString(
+  "0x147392a39e593189902458f4303bc6e0a39128c5a1c1612f76527a162d36d529"
+);
+const publicKey = Point.fromString(
+  "0x26e193aef4f83c70651485b5526c6d01a36d763223ab24efd1f9ff91b394ac0c20ad99d0ef669dc0dde8d5f5996c63105de8e15c2c87d8260b9e6f02f72af622"
+);
+const partialAddress = Fr.fromString(
+  "0x200e9a6c2d2e8352012e51c6637659713d336405c29386c7c4ac56779ab54fa7"
+);
+
+const completeAddress = CompleteAddress.create(
+  aztecAddress,
+  publicKey,
+  partialKey
+);
 await aztecRpc.registerRecipient(completeAddress);
 ```
 
@@ -50,8 +65,8 @@ Then you can call the function:
 
 #include_code encrypted /yarn-project/aztec-nr/value-note/src/utils.nr rust
 
-
 ### Unencrypted Events
+
 Unencrypted events are events which can be read by anyone.
 They can be emitted by both public and private functions.
 
@@ -96,12 +111,14 @@ All event data is pushed to Ethereum as calldata by the sequencer and for this r
 > There are plans to adopt EIP-4844 blobs to reduce the cost of data submission further.
 
 ## Processing events
+
 Both the encrypted and unencrypted events are stored in AztecNode.
 Unencrypted logs can be queried by anyone as we described above in the [Unencrypted Events](#unencrypted-events) section.
 
 Encrypted logs need to first be decrypted:
 
 ### Decrypting
+
 One function of Aztec RPC Server is constantly loading encrypted logs from AztecNode and trying to decrypt them.
 When new encrypted logs are obtained, the Aztec RPC Server will try to decrypt them using the private encryption key of all the accounts registered inside Aztec RPC Server.
 If the decryption is successful, the Aztec RPC Server will store the decrypted note inside a database.
@@ -113,4 +130,4 @@ Every time a new note is successfully decrypted, the Aztec RPC Server will expec
 
 This is an example implementation inside the `PrivateTokenContract`:
 
-#include_code compute_note_hash_and_nullifier /yarn-project/noir-contracts/src/contracts/private_token_contract/src/main.nr rust
+#include_code compute_note_hash_and_nullifier /yarn-project/noir-contracts/src/contracts/private_token_contract/src/main.nr rust

docs/docs/dev_docs/contracts/example-contract.md

@@ -0,0 +1,13 @@
+---
+title: Example Aztec.nr Contract
+---
+
+## Example Aztec.nr Contract
+
+In keeping with the origins of blockchain, here's an example of a simple private token contract. Everyone's balances are private.
+
+#include_code easy_private_token_contract /yarn-project/noir-contracts/src/contracts/easy_private_token_contract/src/main.nr rust
+
+:::info Disclaimer
+Please note that any example contract set out herein is provided solely for informational purposes only and does not constitute any inducement to use or deploy. Any implementation of any such contract with an interface or any other infrastructure should be used in accordance with applicable laws and regulations.
+:::

docs/docs/dev_docs/contracts/main.md

@@ -1,3 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
 # Aztec.nr
 
 ## What is Aztec.nr?
@@ -24,19 +26,6 @@ To write an Aztec.nr contract, you need to write Noir, and to write Noir, you ne
 
 There are a number of tools to make writing Aztec.nr contracts more pleasant. See [here](https://github.com/noir-lang/awesome-noir#get-coding).
 
-## Quick start
-
-:::danger TODO
-Starter kit
-:::
-
-
-## Example Aztec.nr Contract
-
-In keeping with the origins of blockchain, here's an example of a simple private token contract. Everyone's balances are private.
-
-#include_code easy_private_token_contract /yarn-project/noir-contracts/src/contracts/easy_private_token_contract/src/main.nr rust
+## Learn more
 
-:::info Disclaimer
-Please note that any example contract set out herein is provided solely for informational purposes only and does not constitute any inducement to use or deploy. Any implementation of any such contract with an interface or any other infrastructure should be used in accordance with applicable laws and regulations.
-:::
+<DocCardList />

docs/docs/dev_docs/contracts/constrain.md → docs/docs/dev_docs/contracts/syntax/constrain.md

@@ -1,2 +1,2 @@
 Not sure what this one's for?
-`assert`?
+`assert`?

docs/docs/dev_docs/contracts/contract.md → docs/docs/dev_docs/contracts/syntax/contract.md

@@ -17,7 +17,6 @@ contract MyContract {
 }
 ```
 
-
 > A note for vanilla Noir devs: There is no [`main()`](https://noir-lang.org/getting_started/breakdown/#mainnr) function within a Noir `contract` scope. This is because more than one function of a contract may be called and proven as external (as opposed to inlined by the compiler).
 
 ## Structure of a contract
@@ -27,4 +26,4 @@ contract MyContract {
 - Private functions
 - Public functions
 - Encrypted events
-- Unencrypted events
+- Unencrypted events

docs/docs/dev_docs/contracts/control_structure.md → docs/docs/dev_docs/contracts/syntax/control_structure.md

@@ -5,7 +5,7 @@ title: Control Structures
 :::danger
 Question: this feels like the wrong title for a section about how to call functions. 'Control structure' in my mind is "if/else", "for", "while".
 
-Can we not put "how to call functions" in the [functions](./functions.md) section?
+Can we not put "how to call functions" in the functions section?
 :::
 
 # Function Calls
@@ -17,4 +17,3 @@ Can we not put "how to call functions" in the [functions](./functions.md) sectio
 ## Private to Public Function Calls
 
 ## Public to Private Function Calls
-

docs/docs/dev_docs/contracts/functions.md → docs/docs/dev_docs/contracts/syntax/functions.md

@@ -1,4 +1,6 @@
-# Functions
+---
+title: Functions
+---
 
 ## `constructor`
 

docs/docs/dev_docs/contracts/syntax/globals.md

@@ -0,0 +1,10 @@
+---
+title: Globals
+---
+
+# Globals
+
+- `timestamp`
+- `block_number`
+- `chain_id`
+- `version`

docs/docs/dev_docs/contracts/syntax.md → docs/docs/dev_docs/contracts/syntax/main.md

@@ -1,3 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
 # Aztec.nr Syntax
 
 [Noir](https://noir-lang.org/) is a language which is agnostic to proof systems and use cases. Rather than baking Aztec-specific keywords and smart contract types directly into Noir (which would break this agnosticism), we have developed a library -- written in Noir -- whose types and methods provide rich smart contract semantics.
@@ -6,9 +8,9 @@ On top of [Noir's stdlib](https://noir-lang.org/standard_library/array_methods),
 
 Aztec.nr contains abstractions which remove the need to understand the low-level Aztec protocol. Notably, it provides:
 
-- Public and private [state variable types](./types.md)
+- Public and private [state variable types](types)
 - Some pre-designed notes.
-- Functions for [emitting](./events.md) encrypted and unencrypted logs
+- Functions for [emitting](../events.md) encrypted and unencrypted logs
 - [Oracle functions](./functions.md#oracle-calls) for accessing:
   - private state
   - secrets
@@ -17,3 +19,4 @@ Aztec.nr contains abstractions which remove the need to understand the low-level
 To import Aztec.nr into your Aztec contract project, simply include it as a dependency.
 
 #include_code importing-aztec /yarn-project/noir-contracts/src/contracts/private_token_contract/Nargo.toml toml
+<DocCardList />

docs/docs/dev_docs/contracts/state_variables.md → docs/docs/dev_docs/contracts/syntax/state_variables.md

@@ -1,4 +1,6 @@
-# State Variables
+---
+title: State Variables
+---
 
 State variables come in two flavours: [**public** state](#publicstatet-t_serialised_len) and [**private** state](#private-state-variables).
 
@@ -122,7 +124,7 @@ A note should conform to the following interface:
 
 The interplay between a private state variable and its notes can be confusing. Here's a summary to aid intuition:
 
-- A private state variable (of type `Singleton`, `ImmutableSingleton` or `Set`) may be declared in [Storage](./storage.md).
+- A private state variable (of type `Singleton`, `ImmutableSingleton` or `Set`) may be declared in [Storage](storage).
 - Every note contains (as a 'header') the contract address and storage slot of the state variable to which it "belongs". A note is said to "belong" to a private state if the storage slot of the private state matches the storage slot contained in the note's header.
   - Management of this 'header' is abstracted-away from developers who use the `ImmutableSingleton`, `Singleton` and `Set` types.
 - A private state variable is colloquially said to "point" to one or many notes (depending on the type), if those note(s) all "belong" to that private state, and those note(s) haven't-yet been nullified.

docs/docs/dev_docs/contracts/types.md → docs/docs/dev_docs/contracts/syntax/types.md

@@ -1,2 +1,6 @@
+---
+title: Types
+---
+
 See Noir docs for Noir types.
-See [state_variables](./state_variables.md) for Aztec.nr state variable types.
+See [state_variables](./state_variables.md) for Aztec.nr state variable types.

docs/docs/dev_docs/contracts/syntax/visibility.md

@@ -0,0 +1,17 @@
+---
+title: Visibility
+---
+
+# Visibility
+
+`internal`
+
+Similar to Solidity, internal functions and vars can be accessed within the contract itself. While technically callable from other contracts, there is a dynamic check that validates the caller to ensure it's the same contract.
+
+`external`
+
+External is not used explicitly as it is in Solidity, but things not marked as `internal` will be external.
+
+`#[aztec(public)]` and `#[aztec(private)]`
+
+These are used to annotate functions so that they are compliant with Aztec ABIs. They inject `PublicContext` and `PrivateContext` for use in contracts.