feat(docs): algolia->typesense

docs/HOW_WE_WRITE_DOCS.md

@@ -1,12 +1,12 @@
 # How we write docs
 
-This doc covers the structure and tone of Aztec developer documentation. For the contribution guidelines, go [here](./CONTRIBUTING.md). Please keep in mind that this is constantly changing. 
+This doc covers the structure and tone of Aztec developer documentation. For the contribution guidelines, go [here](./CONTRIBUTING.md). Please keep in mind that this is constantly changing.
 
 ## Structure
 
 ### High level
 
-Aztec docs are divided into two main sections - `Learn` and `Build`. 
+Aztec docs are divided into two main sections - `Learn` and `Build`.
 
 Anyone technical can read the `Learn` section, whereas only developers who are actively building or starting to build on Aztec will read the `Build` section.
 
@@ -16,7 +16,7 @@ The `Build` section contains information that only developers need to know - thi
 
 ### Types of pages
 
-The Aztec docs roughly follow the [Diataxis](https://diataxis.fr/) framework. It is recommended to read this website before contributing to the docs. 
+The Aztec docs roughly follow the [Diataxis](https://diataxis.fr/) framework. It is recommended to read this website before contributing to the docs.
 
 Every page will fall into **one type of doc**. If your contribution covers multiple types, you will need to split it into multiple pages.
 
@@ -39,8 +39,8 @@ These are docs that developers can consult to know exact and succinct informatio
 ## Tone
 
 * Concise and informative - for example, rather than repeating information, write "to learn more, read ..."
-* Friendly and empathetic - for example, "you do not have to worry about this yet" 
-* Simple and jardon-avoidant when possible 
+* Friendly and empathetic - for example, "you do not have to worry about this yet"
+* Simple and jardon-avoidant when possible
 * Short sentences
 * Unopinionated language - we know things are exciting sometimes, but try not to tell the developer what they should be excited about
 
@@ -85,4 +85,4 @@ The Aztec docs use a sidebar - https://docusaurus.io/docs/sidebar/items
 
 ## Indexing and Search
 
-Algolia docs search - https://docusaurus.io/docs/search#algolia-index-configuration
+Typesense docs search - https://typesense.org/

docs/docs/_protocol-specs/calls/public-private-messaging.md

@@ -19,33 +19,45 @@ Since private functions execute first, they cannot 'wait' on the results of thei
 
 By way of example, suppose a function makes a call to a public function, and then to a private function. The public function will not be executed immediately, but will instead be enqueued for the sequencer to execute later.
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 graph LR
     A[Private Function 1] --> |1st call| B(Public Function 1)
     A --> |2nd call| C[Private Function 2]
     C --> |return values| A
     A --> |3rd call| D(Public Function 2)
     A --> |4th call| E[Private Function 3]
     E --> |return values| A
+</Mermaid>
 ```
 
 The order of execution will actually be:
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 graph LR
     A[Private Function 1] --> C[Private Function 2]
     C --> |return values| A
     A[Private Function 1] --> E[Private Function 3]
     E --> |return values| A
     A -----> |Enqueued| B(Public Function 1)
     A -----> |Enqueued| D(Public Function 2)
+</Mermaid>
 ```
 
 And the order of proving will actually be:
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 flowchart LR
     A[Private Function 1] --> C[Private Function 2] --> E[Private Function 3] ----> B(Public Function 1) --> D(Public Function 2)
+</Mermaid>
 ```
 
 ## Private to Public Messaging

docs/docs/_protocol-specs/circuits/high-level-topology.md

@@ -15,7 +15,10 @@ A note for Aztec protocol developers: In this protocol spec, the order in which
 <!-- Mike review: perhaps a more comprehensive example would be if f2 makes the calls to f4 and f5, to cover a case which isn't covered in the current example: If f2 calls f4 & f5, then which is processed by the kernel first out of f3, f4, or f5?
 -->
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 flowchart LR
     f0([f0]) --> f1([f1])
     f0 --> f2([f2])
@@ -27,11 +30,15 @@ flowchart LR
     f3 --> f4([f4])
     f3 -.-> F4
     f3 --> f5([f5])
+</Mermaid>
 ```
 
 This transaction contains 6 private functions (f0 to f5) and 5 public functions (F0 to F4), with `f0` being the entrypoint. The entire transaction is processed as follows:
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 flowchart TB
     subgraph Transaction A
         subgraph Private Functions
@@ -126,6 +133,7 @@ flowchart TB
     MR1 --> MR2
     MR2 --> ROOT
     MR3 --> ROOT
+</Mermaid>
 ```
 
 A few things to note:

docs/docs/_protocol-specs/circuits/private-kernel-initial.mdx

@@ -296,7 +296,10 @@ Key:
 
 <div style={{width: '40%'}}>
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 classDiagram
 direction LR
 class ParentClass {
@@ -320,6 +323,7 @@ class D {
 ParentClass *-- ChildClass: Composition.
 A .. B: Perform a consistency check on values in these classes.
 C ..> D: Copy the data from the inputs A to the outputs B\n(possibly with some modification along the way).
+</Mermaid>
 ```
 
 </div>
@@ -335,7 +339,10 @@ The diagram:
 <div style={{overflowX: 'auto'}}>
 <div style={{width: '200%'}}>
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 classDiagram
 direction TB
 
@@ -694,7 +701,7 @@ class PublicInputs {
 }
 ConstantData --* PublicInputs : constant_data
 TransientAccumulatedData --* PublicInputs: transient_accumulated_data
-
+</Mermaid>
 ```
 
 </div>

docs/docs/_protocol-specs/circuits/private-kernel-inner.mdx

@@ -130,7 +130,10 @@ NOTE TO ANYONE EDITING THIS DIAGRAM:
 To save repeating yourself, you only need to edit the END of this diagram (demarcated clearly, further down the page - you'll see it). COPY-PASTE the beginning of this diagram (up to the demarcation) from ../private-kernel-initial.
 -->
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 classDiagram
 direction TB
 
@@ -549,7 +552,6 @@ PrivateKernelPublicInputs ..> KERNEL_PROOF_VERIFICATION
 KernelVerificationKey ..> KERNEL_VK_EXISTENCE_CHECK
 KernelVKMembershipWitness ..> KERNEL_VK_EXISTENCE_CHECK
 
-
 ```
 
 </div>

docs/docs/_protocol-specs/decentralization/block-production.md

@@ -90,7 +90,10 @@ Currently, Provers don't need to register but must commit a bond during the `pro
 
 Future updates may introduce a registration process for Provers, possibly leading to a smaller, more consistent group, but this is currently not suggested to be required.
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Anyone
@@ -100,6 +103,7 @@ participant Network as Aztec Network
 Anyone ->> Contract: register as a sequencer
 Anyone --> Anyone: Wait 7 days
 Anyone ->> Network: eligible as a sequencer
+</Mermaid>
 ```
 
 ## Block production
@@ -126,7 +130,10 @@ Every staked sequencers participate in the following phases, comprising an Aztec
    - For data layers that is not on the host, the host must have learned of the publication from the **Reveal** before the **Finalization** can begin.
 6. **Backup:** Should no prover commitment be put down, or should the block not get finalized, then an additional phase is opened where anyone can submit a block with its proof, in a based-rollup mode. In the backup phase, the first rollup verified will become canonical.
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Contract as Aztec L1 Contract
@@ -149,6 +156,7 @@ loop Happy Path Block Production
     Contract --> Contract: validates proofs and state transition
     Note right of Contract: "block confirmed!"
 end
+</Mermaid>
 ```
 
 ### Constraining Randao
@@ -177,7 +185,10 @@ When a sequencer move to `exiting`, they might have to await for an additional d
 **Lasse Comment**: I'm unsure what you mean by "active" here. Is active that you are able to produce blocks? Is so, active seems fine. Also, not clear to me if `exiting` means that they be unable to propose blocks? If they are voting in them, sure put a delay in there, but otherwise I don't see why they should be unable to leave (when we don't have consensus for block production).
 :::
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Anyone as Sequencer
@@ -188,6 +199,8 @@ Anyone ->> Contract: exit() from being a sequencer
 Note left of Contract: Sequencer no longer eligible for Fernet elections
 Anyone --> Anyone: Wait 7-21 days
 Anyone ->> Network: exit successful, stake unlocked
+</Mermaid>
+
 ```
 
 ## Confirmation rules
@@ -207,7 +220,10 @@ Below, we outline the stages of confirmation.
 6. In a proven block that has been verified / validated by the L1 rollup contracts
 7. In a proven block that has been finalized on the L1
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Anyone as User
@@ -227,11 +243,15 @@ Contract --> Contract: waits N more blocks
 Contract --> Contract: finalizes block
 Network --> Contract: updates state to reflect finality
 Anyone ->> Network: confirms on their own node or block explorer
+</Mermaid>
 ```
 
 <!--![image](./images/Aztec-Block-Production-2.png)-->
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 journey
     title Wallet use case, basic transfer (tx confirmation happy path)
     section User Device
@@ -244,6 +264,7 @@ journey
     section L1
       Tx in block verified on L1: 6: Sequencer
       Tx in block finalized on L1: 7: Sequencer
+</Mermaid>
 ```
 
 ## Economics
@@ -285,7 +306,10 @@ Initially it's expected that the negotiations and commitment could be facilitate
 I'm not fully understanding the different groups, is the aztec network just the node software or 👀? Maybe coloring is nice to mark what is contracts and entities or groups of entities. Otherwise seems quite nice.
 :::
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Anyone
@@ -314,13 +338,17 @@ loop Happy Path Block Production
 end
 Sequencers ->> Contract: exit()
 Sequencers --> Sequencers: wait 7 days
+</Mermaid>
 ```
 
 ### Voting on upgrades
 
 In the initial implementation of Aztec, sequencers may vote on upgrades alongside block proposals. If they wish to vote alongside an upgrade, they signal by updating their client software or an environment configuration variable. If they wish to vote no or abstain, they do nothing. Because the "election" is randomized, the voting acts as a random sampling throughout the current sequencer set. This implies that the specific duration of the vote must be sufficiently long and RANDAO sufficiently randomized to ensure that the sampling is reasonably distributed.
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Contract as Aztec L1 Contract
@@ -343,13 +371,17 @@ loop Happy Path Block Production
     Contract --> Contract: validates proofs and state transition
     Note right of Contract: "block confirmed! votes counted for upgrade!"
 end
+</Mermaid>
 ```
 
 ### Backup mode
 
 In the event that no one submits a valid block proposal, we introduce a "backup" mode which enables a first come first serve race to submit the first proof to the L1 smart contracts.
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Anyone
@@ -366,6 +398,7 @@ loop Happy Path Block Production
     Contract --> Contract: validates proofs and state transition
     Note right of Contract: "block confirmed!"
 end
+</Mermaid>
 ```
 
 :::danger
@@ -374,7 +407,10 @@ There is an outstanding concern that this may result in L1 censorship. L1 builde
 
 We also introduce a similar backup mode in the event that there is a valid proposal, but no valid prover commitment (deposit) by the end of the prover commitment phase.
 
-```mermaid
+```mdx
+import { Mermaid } from '@docusaurus/theme-mermaid';
+
+<Mermaid>
 sequenceDiagram
 
 participant Anyone
@@ -395,6 +431,7 @@ loop Happy Path Block Production
     Contract --> Contract: validates proofs and state transition
     Note right of Contract: "block confirmed!"
 end
+</Mermaid>
 ```
 
 ## Glossary