Migrate to docusaurus

.github/workflows/deploy-production.yml

@@ -3,12 +3,7 @@ name: CD - production
 on:
   push:
     branches: [ main ]
-env:
-  NEXT_PUBLIC_BASE_PATH: ''
-  NEXT_PUBLIC_DOCSEARCH_APP_ID: ${{ secrets.NEXT_PUBLIC_DOCSEARCH_APP_ID }}
-  NEXT_PUBLIC_DOCSEARCH_API_KEY: ${{ secrets.NEXT_PUBLIC_DOCSEARCH_API_KEY }}
-  NEXT_PUBLIC_DOCSEARCH_INDEX_NAME: ${{ secrets.NEXT_PUBLIC_DOCSEARCH_INDEX_NAME }}
-
+
 jobs:
   build:
     runs-on: ubuntu-latest
@@ -24,5 +19,5 @@ jobs:
           aws-access-key-id: ${{ secrets.AWS_S3_PRODUCTION_KEY_ID }}
           aws-secret-access-key: ${{ secrets.AWS_S3_PRODUCTION_SECRET }}
           aws-region: eu-west-1
-      - run: aws s3 sync ./out ${{ secrets.AWS_S3_PRODUCTION_PATH }}
+      - run: aws s3 sync ./build ${{ secrets.AWS_S3_PRODUCTION_PATH }}
       - run: aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_DISTRIBUTION_PRODUCTION }} --paths '/*'

.github/workflows/deploy-staging.yml

@@ -3,11 +3,6 @@ name: CD
 on:
   push:
     branches: [ staging ]
-env:
-  NEXT_PUBLIC_BASE_PATH: ''
-  NEXT_PUBLIC_DOCSEARCH_APP_ID: ${{ secrets.NEXT_PUBLIC_DOCSEARCH_APP_ID }}
-  NEXT_PUBLIC_DOCSEARCH_API_KEY: ${{ secrets.NEXT_PUBLIC_DOCSEARCH_API_KEY }}
-  NEXT_PUBLIC_DOCSEARCH_INDEX_NAME: ${{ secrets.NEXT_PUBLIC_DOCSEARCH_INDEX_NAME }}
 
 jobs:
   build:
@@ -24,5 +19,5 @@ jobs:
           aws-access-key-id: ${{ secrets.AWS_S3_STAGE_KEY_ID }}
           aws-secret-access-key: ${{ secrets.AWS_S3_STAGE_SECRET }}
           aws-region: eu-west-1
-      - run: aws s3 sync ./out ${{ secrets.AWS_S3_STAGE_PATH }}
+      - run: aws s3 sync ./build ${{ secrets.AWS_S3_STAGE_PATH }}
       - run: aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_DISTRIBUTION_STAGE }} --paths '/*'

.gitignore

@@ -2,4 +2,7 @@ node_modules
 .next
 .env.local
 .DS_Store
-out
+.docusaurus/*
+out
+build
+

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023 Trilitech
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -32,7 +32,7 @@ cp .env.example .env.local
 Next, run the development server:
 
 ```bash
-npm run dev
+npm run start
 ```
 
 Finally, open [http://localhost:3000](http://localhost:3000) in your browser to view the website.

babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docs/architecture.md

@@ -0,0 +1,24 @@
+# Architecture
+
+- Who created it and who is in charge of it
+- What entities participate in it
+- How it is built (architecture, with diagrams)
+
+## Decentralization
+## p2p network (introducting nodes, baking)
+## smart contracts and dapps
+## governance and roadmap for scaling
+
+## goals/inspiration, tiny bit of history
+need for decentralization, smart contracts, then for Tezos, need for blockchains to evolve, be environmental friendly, secure
+## p2p network, DOS protection, etc.
+Idea: to make it more active, create an interactive experience where people simulate playing different roles, through the path of a transaction
+## accounts, cryptocurrency, transactions
+Here the animation would let people play with transactions ana d simulated wallet
+## chain of blocks
+idea that for people to agree on a sequence of transactions, they need to be grouped in block, and we create an append-only structure
+## baking, consensus mechanism
+"someone needs to propose a new block, so we have a system involving bakers, then a mechanism to pick the baker, confirm the block through attestations, and finality
+you could have a small interface where you try to create the best block"
+## recap: path of a transaction
+wallet, simulation, propagation through the nodes, mempool, accepted by a baker, block is propagated and validated, then becomes final, shown as validated on the wallet, and visible by everyone

docs/architecture/accounts.md

@@ -0,0 +1,15 @@
+---
+title: Accounts
+authors: "Tim McMackin"
+lastUpdated: 18th October 2023
+---
+
+Tezos uses two types of accounts:
+
+- Classic accounts (also known as _implicit accounts_) with an address, storing tez (ꜩ).
+These accounts have addresses that start with "tz1", "tz2", "tz3" or "tz4."
+Any wallet application or the Octez command-line tool can create implicit accounts.
+
+- Smart contract accounts (also known as _originated accounts_) with an address, storing code and tez (ꜩ).
+Originated accounts have addresses that start with "KT1."
+Creating an originated account is part of the process of deploying a smart contract; see [Smart contracts](../smart-contracts).

docs/architecture/baking.md

@@ -0,0 +1,9 @@
+# Baking
+
+- What is baking?
+- Why would I want to do it?
+- What's involved in baking
+
+Should this link to tezos.gitlab.io instead of being here? There are no topics on Baking there, but octez is how you bake.
+
+We write an overview, based on what is on opentezos, to give a good understanding of what running nodes involve, without diving into details

docs/architecture/baking/running-nodes.md

@@ -0,0 +1,3 @@
+# Hosting a baking node
+
+We write an overview, based on what is on opentezos, to give a good understanding of what running nodes involve, without diving into details

src/pages/tezos-basics/governance/index.md → docs/architecture/governance.md

@@ -1,12 +1,13 @@
 ---
-title: Tezos Governance
+title: Governance
 lastUpdated: 3rd July 2023
 ---
+
 ## What is Self Amendment?
 
 Tezos is a self-amending blockchain network that incorporates an on-chain mechanism for proposing, selecting, testing, and activating protocol upgrades without the need to hard fork.
 
-## How Does It Work? 
+## How Does It Work?
 
 The self-amendment process is split into 5 periods: Proposal Period, Exploration Vote Period, Cooldown Period, Promotion Vote Period, and Adoption Period. Each of these periods lasts five baking cycles (i.e. 40,960 blocks at 30-second intervals or roughly 14 days, 5 hours), comprising roughly 2 months and 10 days.
 

src/pages/tezos-basics/governance/history-of-amendments/index.md → docs/architecture/governance/amendment-history.md

@@ -1,11 +1,10 @@
 ---
-id: history-of-amendments
 title: History of amendments
 authors: 'Thomas Zoughebi, Aymeric Bethencourt, and Maxime Fernandez'
 lastUpdated: 30th June 2023
 ---
 
-As presented in the [Governance on-chain chapter](/tezos-basics/governance-on-chain), the Tezos blockchain is constantly evolving, through new amendments. In this chapter, we will present an overview of past proposals and the reasons for their approval or disapproval.
+As presented in [Governance](../governance), the Tezos blockchain is constantly evolving, through new amendments. In this chapter, we will present an overview of past proposals and the reasons for their approval or disapproval.
 
 ## [Athens](https://tezos.gitlab.io/protocols/004_Pt24m4xi.html) (Pt24m4xiP)
 
@@ -82,7 +81,7 @@ Florence's notable bug fixes and improvements are the:
 * Changing inter-contract calls to a [depth-first search](https://en.wikipedia.org/wiki/Depth-first_search) ordering, as opposed to [breadth-first search](https://en.wikipedia.org/wiki/Breadth-first_search) ordering
 
 * The elimination of the test chain activation
-  
+
 [*Bakings Accounts*](https://midl-dev.medium.com/tezos-in-favor-of-baking-accounts-3886effa370c) was also included in the feature set. However, ongoing testing uncovered some important and previously undocumented breaking changes in the proposal with *Baking Accounts*. Hence, the feature was postponed until a thorough audit of the functionality was completed or an alternative implementation was produced. The version of *Florence* without *Baking Accounts* was considered a [safer choice](https://research-development.nomadic-labs.com/baking-accounts-proposal-contains-unexpected-breaking-changes.html).
 
 For more information, see the blog post from [Nomadic Labs](https://research-development.nomadic-labs.com/florence-our-next-protocol-upgrade-proposal.html) and [Tarides](https://tarides.com/blog/2021-03-04-florence-and-beyond-the-future-of-tezos-storage), as well as the [reference documentation](https://tezos.gitlab.io/protocols/009_florence.html).

src/pages/tezos-basics/governance/improvement-process-tzip/index.md → docs/architecture/governance/improvement-process.md

@@ -2,14 +2,14 @@
 title: Tezos Improvement Process (TZIP)
 lastUpdated: 10th July 2023
 ---
-As Tezos is a large decentralized project that is constantly evolving, its members need to have a mechanism for proposing improvements to the ecosystem. 
+As Tezos is a large decentralized project that is constantly evolving, its members need to have a mechanism for proposing improvements to the ecosystem.
 
 A Tezos Improvement Proposal (or TZIP, pronounced "tee-zip") is a document that offers ways to improve Tezos via new features, tools, or standards (e.g. smart contract specifications).
 
 Specifically, a TZIP is a design document providing information to the Tezos community, describing a feature for Tezos or its processes or environment, and supporting the formal protocol governance process. The TZIP process complements (but is subsidiary to) Tezos' formal on-chain governance process.
 
-The TZIP document should contain a concise technical specification and rationale that clearly articulates what the proposal is, how it may be implemented, and why the proposal is an improvement. It should also include an FAQ that documents, compares, and answers alternative options, opinions, and objections.  
-  
+The TZIP document should contain a concise technical specification and rationale that clearly articulates what the proposal is, how it may be implemented, and why the proposal is an improvement. It should also include an FAQ that documents, compares, and answers alternative options, opinions, and objections.
+
 An explorer for all of the TZIPs, both past and present, can be found [here](https://tzip.tezosagora.org/).
 
 ## Key TZIP Standards
@@ -18,7 +18,7 @@ An explorer for all of the TZIPs, both past and present, can be found [here](htt
 
 TZIP-7, more commonly referred to as FA1.2, introduced an [ERC20](https://eips.ethereum.org/EIPS/eip-20)-like fungible token standard for Tezos. At its core, FA1.2 contains a ledger that maps identities to token balances, provides a standard API for token transfer operations, as well as providing approval to external contracts (e.g. an auction) or accounts to transfer a user's tokens.
 
-For those coming from [ERC20](https://eips.ethereum.org/EIPS/eip-20), the FA1.2 interface differs from ERC-20 in that it does not contain `transferfrom`, which has instead been merged into a single transfer entrypoint.   
+For those coming from [ERC20](https://eips.ethereum.org/EIPS/eip-20), the FA1.2 interface differs from ERC-20 in that it does not contain `transferfrom`, which has instead been merged into a single transfer entrypoint.
 The FA1.2 specification is described in detail in [TZIP-7](https://gitlab.com/tzip/tzip/blob/master/proposals/tzip-7/tzip-7.md), and several implementations of FA1.2 can be found [here](https://packages.ligolang.org/package/ligo-fa1.2).
 
 
@@ -47,8 +47,8 @@ TZIP-16 defines:
 
 * A basic structure to find some metadata in a contract's storage.
 * A URI scheme to find data: on-chain (contract storage) or off-chain (web services or IPFS).
-* An extensible JSON format (JSON-Schema) to describe the metadata 
-* Optional entrypoints to validate metadata information 
+* An extensible JSON format (JSON-Schema) to describe the metadata
+* Optional entrypoints to validate metadata information
 
 ### [**TZIP-17**](https://tzip.tezosagora.org/proposal/tzip-17/): Permit & Meta-transactions
 
@@ -60,7 +60,7 @@ For instance, a “relayer” can submit a user’s pre-signed (meta) transactio
 
 TZIP-17 enables developers to provide more native experiences for user onboarding and allows users to pay fees using the token (e.g. a stablecoin) used in the transaction. The relayer still pays transaction fees in tez at the protocol level and, because Tezos is Proof-of-Stake, these [transaction fees accrue to stakeholders](http://ex.rs/protocol-level-fees/) rather than just a small group of miners.
 
-Ultimately, this brings the experience of using digital assets on Tezos more in line with that of traditional financial transactions and supports the use of Tezos as a settlement layer.  
+Ultimately, this brings the experience of using digital assets on Tezos more in line with that of traditional financial transactions and supports the use of Tezos as a settlement layer.
 ****
 
 ### [**TZIP-20**](https://tzip.tezosagora.org/proposal/tzip-20/): Off-chain Events
@@ -69,7 +69,7 @@ Off-chain events can be used for various purposes, but one of the most obvious u
 
 However, the indexer can't determine which particular balances have changed if the invoked method is not standardized (e.g. FA2/FA1.2 transfer), or if there was an initial token distribution at the origination.
 
-The current approach is using custom handlers for known contracts. 
+The current approach is using custom handlers for known contracts.
 
 This approach is tied to a specific indexer implementation and is not scalable. Therefore we need a better alternative that is flexible enough to cover the majority of cases, simple enough to implement/integrate with the existing codebase, and not tied to any specific entity or implementation.
 

src/pages/tezos-basics/tezos-protocol-and-shell/index.md → docs/architecture/protocol.md

@@ -1,5 +1,4 @@
 ---
-id: tezos-protocol-and-shell
 title: Tezos Protocol and Shell
 lastUpdated: 29th June 2023
 ---
@@ -18,7 +17,7 @@ The rest of the shell includes the peer-to-peer layer, the disk storage of block
 
 Protocols are compiled using a tweaked OCaml compiler that does two things. First, it checks that the protocol’s main module has the right type. A good analogy is to see protocol as plug-ins, and in this case, it means that it respects the common plugin interface. Then, it restricts the typing environment of the protocol’s code so that it only calls authorized modules and functions. Seeing protocols as plug-ins, it means that the code only called primitives from the plug-in API. It is a form of statically enforced sandboxing.
 
-Note that the economic protocol on the chain is subject to an amendment procedure. On-chain operations can be used to switch from one protocol to another. 
+Note that the economic protocol on the chain is subject to an amendment procedure. On-chain operations can be used to switch from one protocol to another.
 
 Finally, the RPC layer is an important part of the node. It is how the client, third-party applications, and daemons can interact with the node and introspect its state. This component uses the mainstream JSON format and HTTP protocol. It uses the library resto. It is fully interoperable, and auto-descriptive, using JSON schema.
 
@@ -45,29 +44,28 @@ As previously stated, Tezos is a self-amending blockchain. In large part of Tezo
 
 The economic protocol provides the rules for checking the validity of the blocks and operations, and for updating the blockchain state accordingly, by applying new valid blocks and operations on the current blockchain state. It defines under which conditions a block is a valid extension of the current blockchain, and defines an ordering on blocks to arbitrate between concurrent extensions.
 
-The rules it uses for recognizing and applying valid blocks can be changed through voting. Thus, the economic protocol represents the amendable part of Tezos. To learn about the voting and amendment process see [Tezos Agora's overview](https://www.tezosagora.org/learn) of Tezos Governance. 
+The rules it uses for recognizing and applying valid blocks can be changed through voting. Thus, the economic protocol represents the amendable part of Tezos. To learn about the voting and amendment process see [Tezos Agora's overview](https://www.tezosagora.org/learn) of Tezos Governance.
 
-Each Tezos protocol is named after a (usually ancient) city, with the first one named Athens. Each successive name follows the previous alphabetically, continuing to Babylon, Carthage, Delphi, and so on. At the time of writing this article, the network is on the Mumbai protocol, with Nairobi planned for June 2023. There is a protocol upgrade roughly every 3 months. 
+Each Tezos protocol is named after a (usually ancient) city, with the first one named Athens. Each successive name follows the previous alphabetically, continuing to Babylon, Carthage, Delphi, and so on. At the time of writing this article, the network is on the Mumbai protocol, with Nairobi planned for June 2023. There is a protocol upgrade roughly every 3 months.
 
-## Shell-protocol interaction 
+## Shell-protocol interaction
 
-The economic protocol and the shell interact in order to ensure that the blocks being appended to the blockchain are valid. The shell does not accept a branch whose fork point is some number of cycles in the past--anything before is deemed immutable. Also, when receiving a new block the shell determines if the block is valid and its fitness is higher than the current head. 
+The economic protocol and the shell interact in order to ensure that the blocks being appended to the blockchain are valid. The shell does not accept a branch whose fork point is some number of cycles in the past--anything before is deemed immutable. Also, when receiving a new block the shell determines if the block is valid and its fitness is higher than the current head.
 
 The protocol provides support for validating blocks which can be modulated by different "validation modes".
 
 
-## The Shell 
+## The Shell
 
-The shell contains everything that is not part of the economic protocol. It includes: 
+The shell contains everything that is not part of the economic protocol. It includes:
 
 - The Validator: the component responsible for checking that blocks coming from the network or a baker are valid, w.r.t. the rules defined by the economic protocol.
 - The Prevalidator: responsible for determining which operations to propagate for this chain over the peer-to-peer network.
 - The Storage Layer: responsible for aggregating blocks (along with their respective ledger state) and operations within blocks (along with their associated metadata).
-- Synchronization heuristic: Process to bootstrap a node when first joining the network, and knowing when it's synced with the network. 
+- Synchronization heuristic: Process to bootstrap a node when first joining the network, and knowing when it's synced with the network.
 - The peer-to-peer layer: this part is in charge of establishing and maintaining network connections with other nodes (via a gossip protocol).
 - Protocol Environment: a restricted API that may be used by the Octez code to interact with the protocol, and vice versa.
 
 
-{% callout type="note" %}
-In-depth documentation on the [shell](https://tezos.gitlab.io/shell/the_big_picture.html) and [protocol](https://tezos.gitlab.io/active/protocol.html) and the semantics of [operations and blocks](https://tezos.gitlab.io/active/blocks_ops.html) can be found in Tezos' [technical documentation](https://tezos.gitlab.io/index.html). 
-{% /callout %}
+:::note
+In-depth documentation on the [shell](https://tezos.gitlab.io/shell/the_big_picture.html) and [protocol](https://tezos.gitlab.io/active/protocol.html) and the semantics of [operations and blocks](https://tezos.gitlab.io/active/blocks_ops.html) can be found in Tezos' [technical documentation](https://tezos.gitlab.io/index.html).