Merge pull request #54 from anoma/bengt/improve-callouts

Bengt/improve callouts

packages/docs/pages/experimental/ibc.mdx

@@ -39,7 +39,7 @@ You can find an example of the config file [here](https://hackmd.io/l6HNSqJmQt6Q
 The path to the config file, which is is saved in the variable `$HERMES_CONFIG` will be useful later.
 
 
-<Callout> 
+<Callout type="info" emoji="🧩"> 
 **Interpreting the toml**
 
 Each chain configuration is specified under the `[[chains]]` object.
@@ -69,7 +69,7 @@ Check the binary:
 ./target/release/hermes --version
 ```
 
-<Callout>
+<Callout type="info">
 It is recommended to now add hermes to `$PATH` such that it is callable without any pre-fixes.
 For ubuntu users, this can be achieved by
 ```bash copy
@@ -89,7 +89,7 @@ hermes -c $HERMES_CONFIG \
   --new-client-connection
 ```
 
-<Callout>
+<Callout type="info">
 Note that the above `CHAIN_IDs` will depend on your own setup, so do check this for yourself!
 </Callout>
 

packages/docs/pages/governance/off-chain-governance.mdx

@@ -1,3 +1,5 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Off-chain proposals
 
 If for any reason issuing an on-chain proposal is not adequate to your needs, you still have the option to create an off-chain proposal. An off-chain proposal is intended for proposals that do not require any on-chain code execution. The proposal would be distributed on some third-party channel (e.g. a forum) and the voting would be done off-chain. The result of the voting would be computed off-chain and then submitted to the ledger.
@@ -47,4 +49,6 @@ namada client query-proposal-result \
 which will tell you the proposal result.
 
 ## Submit off-chain proposal
-> The community may decide to post data of their off-chain voting to another censorship resistant blockchain to preserve the decision reached by social consensus.
+<Callout type="info">
+The community may decide to post data of their off-chain voting to another censorship resistant blockchain to preserve the decision reached by social consensus.
+</Callout>

packages/docs/pages/governance/on-chain-governance.mdx

@@ -1,6 +1,5 @@
 import { Callout } from 'nextra-theme-docs'
 
-
 # On-chain proposals
 
 ## Create a proposal
@@ -53,16 +52,19 @@ The `data` field and its structure is dependant on the type of proposal being su
 "data" : "<path/to/wasm.wasm>"
 ```
 
-> The data field for default proposals is optional. This is in line with the nature of default proposals. If the proposals have code attached to them in order to change governance parameters, then this code will be represented as a wasm file and the path to this file will be given in the data field.
-
+<Callout type="info">
+The data field for default proposals is optional. This is in line with the nature of default proposals. 
+If the proposals have code attached to them in order to change governance parameters, then this code 
+will be represented as a wasm file and the path to this file will be given in the data field.
+</Callout>
 
 ### ETH Bridge Proposal
 
 ```json
 "data" : "<hex-encoded-bytes-of-what-will-be-signed-by-validators>"
 ```
 
-<Callout>
+<Callout type="warning">
 **Note**:
 The encoding will be submitted as a string
 </Callout>
@@ -79,7 +81,10 @@ The encoding will be submitted as a string
 ```
 
 <Callout>
-The data field for steward proposals is a list of actions to be taken. The actions can be either `add` or `remove` and the address is the address of the steward to be added or removed. In this way you can add or remove multiple stewards in a single proposal.
+The data field for steward proposals is a **list** of actions to be taken. 
+The actions can be either `add` or `remove` and the address is the address of 
+the steward to be added or removed. In this way you can add or remove multiple 
+stewards in a single proposal.
 </Callout>
 
 ### PGF Proposal
@@ -108,7 +113,14 @@ The data field for steward proposals is a list of actions to be taken. The actio
 ```
 
 <Callout>
-The data field for PGF proposals contains both continuous and retroactive PGF funding actions. Within each action, the user can include multiple payments in the form of a vector. Within each payment, the target field contains the address of the recipient as well as the amount of NAM that they will receive. For continuous PGF funding, the amount specified will be sent at the end of each epoch. There is also the option to remove a recipient from the continuous PGF funding, by specifying an already existing continuous funding payment, and then also including the "remove" action. For retroactive PGF funding, the amount specified will be sent immediately.
+The data field for PGF proposals contains both continuous and retroactive PGF funding actions. 
+Within each action, the user can include multiple payments in the form of a vector. 
+Within each payment, the target field contains the address of the recipient as well 
+as the amount of NAM that they will receive. For continuous PGF funding, the amount 
+specified will be sent at the end of each epoch. There is also the option to remove a 
+recipient from the continuous PGF funding, by specifying an already existing continuous 
+funding payment, and then also including the "remove" action. For retroactive PGF funding, 
+the amount specified will be sent immediately.
 </Callout>
 
 ## Submitting the proposal

packages/docs/pages/introduction/base-directory.mdx

@@ -1,10 +1,15 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Base Directory
 
 The base directory on Namada is the directory where all chain-specific data is stored. It is a directory that is created immediately once the chain is joined (with `namadac utils join-network`, for example).
 
 As of the latest version of Namada, the base directory is located in the following locations:
 
-> Technically, the correct directory will be the one assigned to `$XDG_DATA_HOME`, but if you haven't set that variable, it will default to one of the below.
+<Callout type="info" emoji="🤓">
+Technically, the correct directory will be the one assigned to `$XDG_DATA_HOME`, 
+but if you haven't set that variable, it will default to one of the below.
+</Callout>
 
 ## The quick way
 

packages/docs/pages/introduction/install.mdx

@@ -1,7 +1,10 @@
-# Install Namada
+import { Callout } from 'nextra-theme-docs'
 
+# Install Namada
 
-> At the moment, Namada only supports Linux and MacOS. 
+<Callout type="info" emoji="💻">
+At the moment, Namada only supports Linux and MacOS. 
+</Callout>
 
 ## Installing Namada
 Namada can be installed through the following methods:

packages/docs/pages/introduction/install/binaries/overview-of-binaries.mdx

@@ -18,15 +18,10 @@ The main binary `namada` has sub-commands for all of the other binaries:
 To explore the command-line interface, add `--help` argument at any sub-command level to find out any possible sub-commands and/or arguments.
 
 
-The binaries should be added to `$PATH` from the `make install` command. However, if this for some reason did not work, a solution may be to copy the binaries from `namada/target/release` to `$HOME/.local/bin/` for example: 
-```bash copy 
-sudo cp namada/target/release/namada* $HOME/.local/bin/
-```
-
-{/* TODO: Make collapsible */}
+The binaries should be added to `$PATH` from the `make install` command. 
+However, if this for some reason did not work, a solution may be to copy the binaries 
+from `namada/target/release` to `$HOME/.local/bin/` for example: 
 
-<Callout>
-The binaries should be added to `$PATH` from the `make install` command. However, if this for some reason did not work, a solution may be to copy the binaries from `namada/target/release` to `home/$USER/.local/bin/` for example:
-
-`sudo cp namada/target/release/namada* /home/alice/.local/bin/`
-</Callout>
+```shell copy 
+cp namada/target/release/namada* $HOME/.local/bin/
+```

packages/docs/pages/introduction/install/source.mdx

@@ -1,3 +1,5 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Install from source
 
 ## Pre-requisites
@@ -13,4 +15,7 @@ cd namada
 make install
 ```
 
-> WARNING: During internal and private testnets, checkout the latest testnet branch using `git checkout $NAMADA_TESTNET_BRANCH`.
+<Callout type="warning">
+During internal and private testnets, checkout the latest testnet branch using `git checkout $NAMADA_TESTNET_BRANCH`.
+Where `$NAMADA_TESTNET_BRANCH` is the name of the testnet branch, which will be specified in the [testnet documentation](../testnets/environment-setup.md).
+</Callout>

packages/docs/pages/introduction/testnets/migrating-testnets.mdx

@@ -1,13 +1,15 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Steps for migrating testnets
 
 This guide will help you migrate your validator node from one testnet to another. These steps are optional, and for most testnets, these steps will not be needed.
 
 ## Resetting your validator node (optional)
 
-
-> With the release of `v0.15.3` we have introduced a new base directory. This means that you will need to reset your validator node to use the new base directory. This is a one time operation.
->The base directory has been moved from `.namada` to `.local/share/namada` on Linux and `Library/Application Support/Namada` on MacOS.
-
+<Callout type="info">
+With the release of `v0.15.3` we have introduced a new base directory. This means that you will need to reset your validator node to use the new base directory. This is a one time operation.
+The base directory has been moved from `.namada` to `.local/share/namada` on Linux and `Library/Application Support/Namada` on MacOS.
+</Callout>
 
 ### Locate the namada base directory
 
@@ -29,7 +31,10 @@ export BASE_DIR=$(namadac utils default-base-dir)
 ```
 
 
->Technically, the correct directory will be the one assigned to `$XDG_DATA_HOME`, but if you haven't set that variable, it will default to the above.
+<Callout type="info" emoji="🤓">
+Technically, the correct directory will be the one assigned to `$XDG_DATA_HOME`, 
+but if you haven't set that variable, it will default to the one given above.
+</Callout>
 
 
 ### 1. IMPORTANT! Save your `pre-genesis` folder in the ledger base directory

packages/docs/pages/ledger.mdx

@@ -1,3 +1,5 @@
+import { Callout } from 'nextra-theme-docs'
+
 # The Namada Ledger
 
 To start a local Namada ledger node, run:
@@ -6,31 +8,45 @@ To start a local Namada ledger node, run:
 namada ledger
 ```
 
-> Note: You need to have [joined a network](./introduction/quick-start.md) before you start the ledger. It throws an error if no network has been configured.
+<Callout>
+**Note**: You must have [joined a network](./introduction/quick-start.md) before you start the ledger. It throws an error if no network has been configured.
 
 The node will attempt to connect to the persistent validator nodes and other peers in the network, and synchronize to the latest block.
 
-By default, the ledger will store its configuration and state in either `$HOME/.local/share/namada` or `$HOME/Library/Application\ Support/Namada`. You can use the `--base-dir` CLI global argument or `BASE_DIR` environment variable to change it.
+By default, the ledger will store its configuration and state in your [base directory](./introduction/base-directory.md). 
+You can use the `--base-dir` CLI global argument or `BASE_DIR` environment variable to change it.
+</Callout>
 
-- Linux:
-```bash copy
-export BASE_DIR=$HOME/.local/share/namada
-```
-- MacOS:
-```bash copy
-export BASE_DIR=$HOME/Library/Application\ Support/Namada
+Assuming you do not have a custom base_dir, you can export the BASE_DIR environment variable as follows:
+
+```shell copy
+export BASE_DIR=$(namadac utils default-base-dir)
 ```
 
 The ledger also needs access to the built WASM files that are used in the genesis block. These files are included in release and shouldn't be modified, otherwise your node will fail with a consensus error on the genesis block. By default, these are expected to be in the `wasm` directory inside the chain directory that's in the base directory. This can also be set with the `--wasm-dir` CLI global argument, `NAMADA_WASM_DIR` environment variable or the configuration file.
 
 The ledger configuration is stored in `$BASE_DIR/{chain_id}/config.toml` (with
 default `--base-dir`). It is created when you join the network. You can modify
 that file to change the configuration of your node. All values can also be set
-via environment variables. Names of the recognized environment variables are
+via environment variables. 
+
+Names of the recognized environment variables are
 derived from the configuration keys by: uppercase every letter of the key,
 insert `.` or `__` for each nested value and prepend `NAMADA_`. For example,
 option `p2p_pex` in `[ledger.cometbft]` can be set by
-`NAMADA_LEDGER__COMETBFT__P2P_PEX=true|false` or
-`NAMADA_LEDGER.COMETBFT.P2P_PEX=true|false` in the environment (Note: only the
-double underscore form can be used in Bash, because Bash doesn't allow dots in
-environment variable names).
+```shell copy
+NAMADA_LEDGER__COMETBFT__P2P_PEX=true # or false, depending on your heart's desires
+``` 
+or
+```shell copy
+NAMADA_LEDGER.COMETBFT.P2P_PEX=true # or false, depending on your heart's desires
+``` 
+in the environment 
+
+<Callout>
+**Note**: 
+
+Only the double underscore form can be 
+used in Bash, because Bash doesn't allow dots in
+environment variable names
+</Callout>

packages/docs/pages/public-goods-stewards/electing.mdx

@@ -4,7 +4,10 @@ import { Callout } from 'nextra-theme-docs'
 
 A public goods steward can consist of an arbitrary number of people, and can be a single person. The only requirement is that the steward's multisignature account is elected by the community, through a governance proposal.
 
-For this reason, the first step to becoming a steward is to create a multisignature account. This can be done using the commands found in (TODO: link to multisig docs). Once the multisig account is created, the steward can submit a governance proposal to elect the account as a steward.
+For this reason, the first step to becoming a steward is to create a multisignature account. 
+This can be done using the commands found in the mutltisgnature documentation (coming soon). 
+{/* TODO: link to multisig docs  */}
+Once the multisig account is created, the steward can submit a governance proposal to elect the account as a steward.
 
 ## Governance proposal
 
@@ -41,10 +44,17 @@ The `steward_proposal.json` file contains the information about the proposal. It
 }
 ```
 
-The `"data"` field contains the structure that allows either the addition or removal of a multisignature account from the list of stewards. In this case, the `"action"` is `"add"`, and the `"address"` is the address of the multisignature account that will be elected as a steward. If the `"action"` was `"remove"`, the `"address"` would be the address of the multisignature account that would be removed from the list of stewards.
+The `"data"` field contains the structure that allows either the addition or removal of 
+a multisignature account from the list of stewards. In this case, the `"action"` is `"add"`, 
+and the `"address"` is the address of the multisignature account that will be elected as a steward. 
+If the `"action"` was `"remove"`, the `"address"` would be the address of the multisignature account 
+that would be removed from the list of stewards.
 
 <Callout>
-In the motivation and abstract field, it is important to make clear what type of public goods funding the steward will be focusing on. The *areas of public goods funding* can be found in the [public goods funding specs](https://specs.namada.net/economics/public-goods-funding.html#funding-focuses).
+In the motivation and abstract field, it is important to make clear what type of 
+public goods funding the steward will be focusing on. 
+The *areas of public goods funding* can be found in the 
+[public goods funding specs](https://specs.namada.net/economics/public-goods-funding.html#funding-focuses).
 </Callout>
 
 ### Submitting the proposal to the ledger

packages/docs/pages/users/send-and-receive-nam-tokens.mdx

@@ -44,8 +44,9 @@ To query token balances for a specific token and/or owner:
 namada client balance --token NAM --owner my-new-acc
 ```
 
-<Callout>
-For any client command that submits a transaction (`init-account`, `transfer`, `tx`, `update` and [PoS transactions](../ledger/pos.md)), you can use the `--dry-run` flag to simulate the transaction being applied in the block and see what would be the result.
+<Callout type="info">
+For any client command that submits a transaction (`init-account`, `transfer`, `tx`, `update` and [PoS transactions](../ledger/pos.md)), 
+you can use the `--dry-run` flag to simulate the transaction being applied in the block and see what would be the result.
 </Callout>
 
 ### See every known addresses' balance

packages/docs/pages/users/shielded-transfers.mdx

@@ -46,7 +46,9 @@ namadaw masp gen-addr \
 ```
 
 <Callout>
-This command will generate a different payment address each time you run it. Payment addresses can be reused or discarded as you like, and any relationship between addresses cannot be deciphered by any user without the spending key.
+This command will generate a different payment address each time you run it. 
+Payment addresses can be reused or discarded as you like, and any relationship 
+between addresses cannot be deciphered by any user without the spending key.
 </Callout>
 
 #### Send your shielding transfer

packages/docs/pages/validators/post-genesis-validator-setup.mdx

@@ -1,3 +1,5 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Generating a validator account
 
 ```bash copy
@@ -31,9 +33,11 @@ Then, it submits a transaction to the ledger that generates the new validator ac
 
 The keys and the alias of the address will be saved in your wallet. 
 
-> ***IMPORTANT***
->
-> Our local ledger node will also be setup to run this validator, you just have to shut it down with e.g. `Ctrl + C`, then start it again with the same command as before.
+<Callout type="warning" emoji="🛎️">
+**IMPORTANT**
+
+Our local ledger node will also be setup to run this validator, you just have to shut it down with e.g. `Ctrl + C`, then start it again with the same command as before.
+</Callout>
 
 ```shell copy
 namadan ledger run