Update main with docusaurus site

.github/workflows/deploy-production.yml

@@ -3,26 +3,21 @@ 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
     steps:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v1
         with:
-          node-version: 16
+          node-version: 18
       - run: npm ci
       - run: npm run build
       - uses: aws-actions/configure-aws-credentials@v2
         with:
           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:
@@ -16,13 +11,13 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v1
         with:
-          node-version: 16
+          node-version: 18
       - run: npm ci
       - run: npm run build
       - uses: aws-actions/configure-aws-credentials@v2
         with:
           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.