resolves #2443; fix injections + temp fix for node pg (#2478)

docs/general/faq.md

@@ -40,21 +40,21 @@ For more information on the Polkadot roadmap please visit the
 
 ### How do I apply to be a validator?
 
-There is no central authority that decides on validators, so there is not per se an _application_
+There is no central authority that decides on validators, so there is not per se an *application*
 that you can fill out. Registering as a validator is permissionless; in order to become one you must
 only set up a validator node and mark your intention to validate on chain. For detailed instruction
 on how to do this you can consult the
 [Kusama validator guide](../maintain/kusama/maintain-guides-how-to-validate-kusama.md) on validating for Kusama or the
 [Polkadot validator guide](../maintain/maintain-guides-how-to-validate-polkadot.md) for validating on Polkadot.
 
 However, once you've set up a validator and have registered your intention it does not mean that you
-will be included in the _active set_ right away. The validators are elected to the active set based
+will be included in the *active set* right away. The validators are elected to the active set based
 on the results of an election algorithm known as [Phragmén's method](../learn/learn-phragmen.md). Phragmén's
 method tries to accomplish two goals: 1) select `n` members from a larger set based on
 stake-weighted votes and 2) equalize the stake backing each validator as much as possible.
 
 You will likely want to campaign your validator to the community in order to get more backing. You
-are looking for _nominators_ that will put up their tokens to increase the stake for your validator.
+are looking for *nominators* that will put up their tokens to increase the stake for your validator.
 For validators who cannot acquire the minimum stake from the community, Parity and Web3 Foundation
 also run a joint program called [Thousand Validators](thousand-validators.md) that will nominate
 validators if they apply and fit the requirements.
@@ -104,7 +104,7 @@ similar PoS chains with comparable levels of economic security as Polkadot. The
 are operating with around 150 validators, while Polkadot is already securely running with
 {{ num_validators }}.
 
-Additionally, other projects sometimes have a different definition of _validator_ that approximates
+Additionally, other projects sometimes have a different definition of *validator* that approximates
 more closely to remote signing keys without the full operation of a validating node. On Polkadot,
 each validator is running their own validating node and performing full verification of the Relay
 Chain, voting on finality, producing blocks in their decided slots, and verifying parachain state
@@ -131,13 +131,13 @@ No - and yes. The Polkadot Relay Chain does not implement smart contracts native
 not having smart contracts on the Relay Chain is part of the design philosophy for Polkadot that
 dictates that the Relay Chain should be the minimal logic required to accomplish its job.
 
-However, Polkadot will be a platform for other chains that _do_ implement smart contracts. It's
+However, Polkadot will be a platform for other chains that *do* implement smart contracts. It's
 possible for parachains to enable smart contract functionality and then benefit from the security
 and interoperability features of Polkadot. Additionally, existing smart contract chains can connect
 to Polkadot as a parachain, or via a bridge.
 
 While the Polkadot Relay Chain does not implement smart contracts directly, undoubtedly there will
-be parachains that do. So it's better to say that the Polkadot _ecosystem_ has smart contracts
+be parachains that do. So it's better to say that the Polkadot *ecosystem* has smart contracts
 versus "Polkadot has smart contracts."
 
 ### How will the Polkadot Relay Chain connect to external chains in the ecosystem?
@@ -189,13 +189,13 @@ conviction to sway the progression of the protocol.
 A savvy reader might have noticed that the answer to the previous question endowed the token holder
 with the ultimate responsibility to ensure that Polkadot's governance does not fail. By following
 the train of this assertion, one might assume that Polkadot's governance is susceptible to becoming
-ruled by a few large token holders (called _whales_ in trading parlance) and therefore become a mere
+ruled by a few large token holders (called *whales* in trading parlance) and therefore become a mere
 plutocracy (rule of the rich).
 
 There are several other mechanisms that are built-in to the governance system to resist this
 plutocratic tendency. One of these mechanisms is called conviction voting, and imbues greater voting
 power to token holders who are willing to lock their tokens on the protocol for longer lengths of
-time. Longer lock-ups display _conviction_ in a vote. Conviction voting could allow a highly
+time. Longer lock-ups display *conviction* in a vote. Conviction voting could allow a highly
 determined minority to overrule the vote of an apathetic majority in certain situations. Another
 mechanism is known as Adaptive Quorum Biasing. This makes proposals have a varying threshold for
 approval or rejection based on what part of the governance protocol the proposal originated in. For

docs/learn/learn-identity.md

@@ -17,7 +17,7 @@ like attestations (see [Judgements](#judgements)).
 
 Users must reserve funds in a bond to store their information on chain:
 {{ identity_reserve_funds }}, and {{ identity_field_funds }} per each field beyond the legal name.
-These funds are _locked_, not spent - they are returned when the identity is cleared.
+These funds are *locked*, not spent - they are returned when the identity is cleared.
 
 These amounts can also be extracted by querying constants through the
 [Chain state constants](https://polkadot.js.org/apps/#/chainstate/constants) tab on

docs/learn/learn-proxies.md

@@ -55,7 +55,7 @@ Controller account. Within the Staking pallet, some transactions must come from
 others must come from the Controller. The Stash account is meant to stay in cold storage, while the
 Controller account makes day-to-day transactions like setting session keys or deciding which
 validators to nominate. The Stash account still needs to make some transactions, though, like
-bonding extra funds or designating a new Controller. A proxy doesn't change the _roles_ of Stash and
+bonding extra funds or designating a new Controller. A proxy doesn't change the *roles* of Stash and
 Controller accounts, but does allow the Stash to be accessed even less frequently.
 
 ### Identity Judgement Proxies

docs/maintain/maintain-sync.md

@@ -15,11 +15,11 @@ decentralized world.
 
 This guide will show you how to connect to [Polkadot network](https://polkadot.network/), but the
 same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First,
-let's clarify the term _full node_.
+let's clarify the term *full node*.
 
 ### Types of Nodes
 
-A blockchain's growth comes from a _genesis block_, _extrinsics_, and _events_.
+A blockchain's growth comes from a *genesis block*, *extrinsics*, and *events*.
 
 When a validator seals block 1, it takes the blockchain's state at block 0. It then applies all
 pending changes on top of it, and emits the events that are the result of these changes. Later, the
@@ -36,7 +36,7 @@ Archive nodes are used by utilities that need past information - like block expl
 scanners, discussion platforms like [Polkassembly](https://polkassembly.io), and others. They need
 to be able to look at past on-chain data.
 
-A **full node** is _pruned_: it discards all finalized blocks older than a configurable number
+A **full node** is *pruned*: it discards all finalized blocks older than a configurable number
 except the genesis block: This is 256 blocks from the last finalized one, by default. A node that is
 pruned this way requires much less space than an archive node.
 
@@ -68,6 +68,16 @@ https://github.com/paritytech/smoldot#wasm-light-node
 This is not recommended if you're a validator. Please see the
 [secure validator setup](maintain-guides-secure-validator.md) if you are running validator.
 
+> NOTE: The bash commands that are provided to run against **your node** use 
+> `Polkadot` as the default chain. 
+
+> Use the `--chain` flag if you are 
+> following the setup instructions to setup a `Kusama` node. 
+> For example: 
+> ```bash
+> ./target/release/polkadot --name "Your Node's Name" --chain kusama
+> ```
+
 <Tabs
 groupId="operating-systems"
 values={[
@@ -99,21 +109,11 @@ values={[
   cargo build --release
   ```
 - Start your node:
-  {{ polkadot:
-
+  
   ```bash
   ./target/release/polkadot --name "Your Node's Name"
   ```
 
-  :polkadot }}
-  {{ kusama:
-
-  ```bash
-  ./target/release/polkadot --name "Your Node's Name" --chain kusama
-  ```
-
-  :kusama }}
-
 - Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot)
 
 </TabItem>
@@ -135,21 +135,11 @@ values={[
   sudo chmod +x polkadot
   ```
 - Start your node:
-  {{ polkadot:
 
   ```bash
   ./target/release/polkadot --name "Your Node's Name"
   ```
 
-  :polkadot }}
-  {{ kusama:
-
-  ```bash
-  ./target/release/polkadot --name "Your Node's Name" --chain kusama
-  ```
-
-  :kusama }}
-
 - Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot)
 
 </TabItem>
@@ -170,21 +160,11 @@ values={[
 
 - Run the following: `sudo chmod +x polkadot`
 - Run the following:
-  {{ polkadot:
-
+  
   ```bash
   ./target/release/polkadot --name "Your Node's Name"
   ```
 
-  :polkadot }}
-  {{ kusama:
-
-  ```bash
-  ./target/release/polkadot --name "Your Node's Name" --chain kusama
-  ```
-
-  :kusama }}
-
 - Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot)
 
 </TabItem>
@@ -230,21 +210,11 @@ cargo build --release
 
 The built binary will be in the `target/release` folder, called `polkadot`.
 
-{{ polkadot:
-
+**Polkadot**:
 ```bash
 ./target/release/polkadot --name "Your Node's Name"
 ```
 
-:polkadot }}
-{{ kusama:
-
-```bash
-./target/release/polkadot --name "Your Node's Name" --chain kusama
-```
-
-:kusama }}
-
 Use the `--help` flag to find out which flags you can use when running the node. For example, if
 [connecting to your node remotely](maintain-wss.md), you'll probably want to use `--ws-external` and
 `--rpc-cors all`.
@@ -261,21 +231,12 @@ When running as a simple sync node (above), only the state of the past 256 block
 validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the
 `--pruning` flag:
 
-{{ polkadot:
+**Polkadot**:
 
 ```bash
 ./target/release/polkadot --name "My node's name" --pruning archive
 ```
 
-:polkadot }}
-{{ kusama:
-
-```bash
-./target/release/polkadot --name "My node's name" --pruning archive --chain kusama
-```
-
-:kusama }}
-
 It is possible to almost quadruple synchronization speed by using an additional flag:
 `--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off
 after the node is in sync.