lint: add markdown linter (#5254)

docs/introduction/README.md

@@ -15,6 +15,6 @@ Get Tendermint up-and-running quickly with the [quick-start guide](./quick-start
 
 Detailed [installation instructions](./install.md).
 
-## What is Tendermint?
+## What is Tendermint
 
 Dive into [what Tendermint is and why](./what-is-tendermint.md)!

docs/introduction/architecture.md

@@ -1,11 +1,13 @@
 # Tendermint Architectural Overview
-_November 2019_
+
+> **November 2019**
 
 Over the next few weeks, @brapse, @marbar3778 and I (@tessr) are having a series of meetings to go over the architecture of Tendermint Core. These are my notes from these meetings, which will either serve as an artifact for onboarding future engineers; or will provide the basis for such a document.
 
 ## Communication
 
 There are three forms of communication (e.g., requests, responses, connections) that can happen in Tendermint Core: *internode communication*, *intranode communication*, and *client communication*. 
+
 - Internode communication: Happens between a node and other peers. This kind of communication happens over TCP or HTTP. More on this below. 
 - Intranode communication: Happens within the node itself (i.e., between reactors or other components). These are typically function or method calls, or occasionally happen through an event bus. 
 - Client communiation: Happens between a client (like a wallet or a browser) and a node on the network.
@@ -13,6 +15,7 @@ There are three forms of communication (e.g., requests, responses, connections)
 ### Internode Communication
 
 Internode communication can happen in two ways:
+
 1. TCP connections through the p2p package
     - Most common form of internode communication
     - Connections between nodes are persisted and shared across reactors, facilitated by the switch. (More on the switch below.)
@@ -24,10 +27,12 @@ Internode communication can happen in two ways:
 ### P2P Business (the Switch, the PEX, and the Address Book)
 
 When writing a p2p service, there are two primary responsibilities:
+
 1. Routing: Who gets which messages?
 2. Peer management: Who can you talk to? What is their state? And how can you do peer discovery? 
 
 The first responsibility is handled by the Switch:
+
 - Responsible for routing connections between peers
 - Notably _only handles TCP connections_; RPC/HTTP is separate
 - Is a dependency for every reactor; all reactors expose a function `setSwitch`
@@ -42,12 +47,14 @@ The second responsibility is handled by a combination of the PEX and the Address
 	TODO: What is the PEX and the Address Book? 
 	
 #### The Nature of TCP, and Introduction to the `mconnection`
-Here are some relevant facts about TCP:
-1. All TCP connections have a "frame window size" which represents the packet size to the "confidence;" i.e., if you are sending packets along a new connection, you must start out with small packets. As the packets are received successfully, you can start to send larger and larger packets. (This curve is illustrated below.) This means that TCP connections are slow to spin up.
-3. The syn/ack process also means that there's a high overhead for small, frequent messages 
-4. Sockets are represented by file descriptors.
 
-![](../imgs/tcp-window.png)
+Here are some relevant facts about TCP:
+
+1. All TCP connections have a "frame window size" which represents the packet size to the "confidence;" i.e., if you are sending packets along a new connection, you must start out with small packets. As the packets are received successfully, you can start to send larger and larger packets. (This curve is illustrated below.) This means that TCP connections are slow to spin up.
+2. The syn/ack process also means that there's a high overhead for small, frequent messages 
+3. Sockets are represented by file descriptors.
+
+![tcp](../imgs/tcp-window.png)
 
 In order to have performant TCP connections under the conditions  created in Tendermint, we've created the `mconnection`, or the multiplexing connection. It is our own protocol built on top of TCP. It lets us reuse TCP connections to minimize overhead, and it keeps the window size high by sending auxiliary messages when necessary.
 
@@ -57,22 +64,25 @@ The `mconnection` has two methods: `send`, which takes a raw handle to the socke
 
 The `mconnection` is owned by a peer, which is owned (potentially with many other peers) by a (global) transport, which is owned by the (global) switch: 
 
+<!-- markdownlint-disable -->
 ```
 switch
-	transport
-		peer
-			mconnection
-		peer
-			mconnection
-		peer
-			mconnection	
+  transport
+    peer
+      mconnection
+    peer
+      mconnection
+    peer
+      mconnection	
 ```
+<!-- markdownlint-restore -->
 
 ## node.go 
 
 node.go is the entrypoint for running a node. It sets up reactors, sets up the switch, and registers all the RPC endpoints for a node.
 
 ## Types of Nodes
+
 1. Validator Node: 
 2. Full Node:
 3. Seed Node:
@@ -82,6 +92,7 @@ TODO: Flesh out the differences between the types of nodes and how they're confi
 ## Reactors 
 
 Here are some Reactor Facts: 
+
 - Every reactor holds a pointer to the global switch (set through `SetSwitch()`)
 - The switch holds a pointer to every reactor (`addReactor()`)
 - Every reactor gets set up in node.go (and if you are using custom reactors, this is where you specify that)
@@ -90,6 +101,7 @@ Here are some Reactor Facts:
 - Sometimes reactors talk to each other by fetching references to one another via the switch (which maintains a pointer to each reactor). **Question: Can reactors talk to each other in any other way?**
 
 Furthermore, all reactors expose:
+
 1. A TCP channel
 2. A `receive` method 
 3. An `addReactor` call
@@ -99,6 +111,7 @@ The `receive` method can be called many times by the mconnection. It has the sam
 The `addReactor` call does a for loop over all the channels on the reactor and creates a map of channel IDs->reactors. The switch holds onto this map, and passes it to the _transport_, a thin wrapper around TCP connections.
 
 The following is an exhaustive (?) list of reactors:
+
 - Blockchain Reactor
 - Consensus Reactor 
 - Evidence Reactor 
@@ -108,6 +121,8 @@ The following is an exhaustive (?) list of reactors:
 Each of these will be discussed in more detail later.
 
 ### Blockchain Reactor 
+
 The blockchain reactor has two responsibilities: 
+
 1. Serve blocks at the request of peers 
-2. TODO: learn about the second responsibility of the blockchain reactor 
+2. TODO: learn about the second responsibility of the blockchain reactor 

docs/introduction/install.md

@@ -21,7 +21,7 @@ echo export GO111MODULE=on >> ~/.bash_profile
 
 ### Get Source Code
 
-```
+```sh
 mkdir -p $GOPATH/src/github.com/tendermint
 cd $GOPATH/src/github.com/tendermint
 git clone https://github.com/tendermint/tendermint.git
@@ -30,19 +30,19 @@ cd tendermint
 
 ### Get Tools & Dependencies
 
-```
+```sh
 make tools
 ```
 
 ### Compile
 
-```
+```sh
 make install
 ```
 
 to put the binary in `$GOPATH/bin` or use:
 
-```
+```sh
 make build
 ```
 
@@ -56,7 +56,7 @@ file.
 The latest tendermint is now installed. You can verify the installation by
 running:
 
-```
+```sh
 tendermint version
 ```
 
@@ -64,7 +64,7 @@ tendermint version
 
 To start a one-node blockchain with a simple in-process application:
 
-```
+```sh
 tendermint init
 tendermint node --proxy_app=kvstore
 ```
@@ -73,14 +73,14 @@ tendermint node --proxy_app=kvstore
 
 If you already have Tendermint installed, and you make updates, simply
 
-```
+```sh
 cd $GOPATH/src/github.com/tendermint/tendermint
 make install
 ```
 
 To upgrade, run
 
-```
+```sh
 cd $GOPATH/src/github.com/tendermint/tendermint
 git pull origin master
 make install
@@ -92,7 +92,7 @@ Install [LevelDB](https://github.com/google/leveldb) (minimum version is 1.7).
 
 Install LevelDB with snappy (optionally). Below are commands for Ubuntu:
 
-```
+```sh
 sudo apt-get update
 sudo apt install build-essential
 
@@ -111,20 +111,20 @@ wget https://github.com/google/leveldb/archive/v1.20.tar.gz && \
 
 Set a database backend to `cleveldb`:
 
-```
+```toml
 # config/config.toml
 db_backend = "cleveldb"
 ```
 
 To install Tendermint, run:
 
-```
+```sh
 CGO_LDFLAGS="-lsnappy" make install TENDERMINT_BUILD_OPTIONS=cleveldb
 ```
 
 or run:
 
-```
+```sh
 CGO_LDFLAGS="-lsnappy" make build TENDERMINT_BUILD_OPTIONS=cleveldb
 ```
 

docs/introduction/quick-start.md

@@ -6,7 +6,7 @@ order: 2
 
 ## Overview
 
-This is a quick start guide. If you have a vague idea about how <df value="tendermint">Tendermint</df>
+This is a quick start guide. If you have a vague idea about how Tendermint
 works and want to get started right away, continue.
 
 ## Install
@@ -18,7 +18,7 @@ Ubuntu 16.04 machine, use [this script](https://git.io/fFfOR).
 
 WARNING: do not run this on your local machine.
 
-```
+```sh
 curl -L https://git.io/fFfOR | bash
 source ~/.profile
 ```
@@ -33,7 +33,7 @@ For manual installation, see the [install instructions](install.md)
 
 Running:
 
-```
+```sh
 tendermint init
 ```
 
@@ -41,7 +41,7 @@ will create the required files for a single, local node.
 
 These files are found in `$HOME/.tendermint`:
 
-```
+```sh
 $ ls $HOME/.tendermint
 
 config  data
@@ -58,46 +58,46 @@ Configuring a cluster is covered further below.
 
 Start tendermint with a simple in-process application:
 
-```
+```sh
 tendermint node --proxy_app=kvstore
 ```
 
 and blocks will start to stream in:
 
-```
+```sh
 I[01-06|01:45:15.592] Executed block                               module=state height=1 validTxs=0 invalidTxs=0
 I[01-06|01:45:15.624] Committed state                              module=state height=1 txs=0 appHash=
 ```
 
 Check the status with:
 
-```
+```sh
 curl -s localhost:26657/status
 ```
 
 ### Sending Transactions
 
-With the kvstore app running, we can send transactions:
+With the KVstore app running, we can send transactions:
 
-```
+```sh
 curl -s 'localhost:26657/broadcast_tx_commit?tx="abcd"'
 ```
 
 and check that it worked with:
 
-```
+```sh
 curl -s 'localhost:26657/abci_query?data="abcd"'
 ```
 
 We can send transactions with a key and value too:
 
-```
+```sh
 curl -s 'localhost:26657/broadcast_tx_commit?tx="name=satoshi"'
 ```
 
 and query the key:
 
-```
+```sh
 curl -s 'localhost:26657/abci_query?data="name"'
 ```
 
@@ -111,7 +111,7 @@ addresses below as IP1, IP2, IP3, IP4.
 
 Then, `ssh` into each machine, and execute [this script](https://git.io/fFfOR):
 
-```
+```sh
 curl -L https://git.io/fFfOR | bash
 source ~/.profile
 ```
@@ -122,7 +122,7 @@ Next, use the `tendermint testnet` command to create four directories of config
 
 Before you can start the network, you'll need peers identifiers (IPs are not enough and can change). We'll refer to them as ID1, ID2, ID3, ID4.
 
-```
+```sh
 tendermint show_node_id --home ./mytestnet/node0
 tendermint show_node_id --home ./mytestnet/node1
 tendermint show_node_id --home ./mytestnet/node2
@@ -131,7 +131,7 @@ tendermint show_node_id --home ./mytestnet/node3
 
 Finally, from each machine, run:
 
-```
+```sh
 tendermint node --home ./mytestnet/node0 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"
 tendermint node --home ./mytestnet/node1 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"
 tendermint node --home ./mytestnet/node2 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"

docs/introduction/what-is-tendermint.md

@@ -2,7 +2,7 @@
 order: 4
 ---
 
-# What is Tendermint?
+# What is Tendermint
 
 Tendermint is software for securely and consistently replicating an
 application on many machines. By securely, we mean that Tendermint works
@@ -74,7 +74,7 @@ Tendermint is in essence similar software, but with two key differences:
   the application logic that's right for them, from key-value store to
   cryptocurrency to e-voting platform and beyond.
 
-### Bitcoin, Ethereum, etc.
+### Bitcoin, Ethereum, etc
 
 Tendermint emerged in the tradition of cryptocurrencies like Bitcoin,
 Ethereum, etc. with the goal of providing a more efficient and secure
@@ -227,7 +227,7 @@ design their message handlers to create a blockchain that does anything
 useful but this architecture provides a place to start. The diagram
 below illustrates the flow of messages via ABCI.
 
-![](../imgs/abci.png)
+![abci](../imgs/abci.png)
 
 ## A Note on Determinism
 
@@ -263,7 +263,7 @@ Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus
 protocol. The protocol follows a simple state machine that looks like
 this:
 
-![](../imgs/consensus_logic.png)
+![consensus-logic](../imgs/consensus_logic.png)
 
 Participants in the protocol are called **validators**; they take turns
 proposing blocks of transactions and voting on them. Blocks are
@@ -329,4 +329,4 @@ The following diagram is Tendermint in a (technical) nutshell. [See here
 for high resolution
 version](https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf).
 
-![](../imgs/tm-transaction-flow.png)
+![tx-flow](../imgs/tm-transaction-flow.png)