Docs cleanup (#2522)

* minor doc cleanup

* docs/tools: link fixes and readme

* docs/networks: networks/local/README.md

* docs: update vuepress config

* docs: fixes from review

docs/.vuepress/config.js

@@ -11,12 +11,12 @@ module.exports = {
     nav: [{ text: "Back to Tendermint", link: "https://tendermint.com" }],
     sidebar: [
       {
-        title: "Getting Started",
+        title: "Introduction",
         collapsable: false,
         children: [
           "/introduction/quick-start",
           "/introduction/install",
-          "/introduction/introduction"
+          "/introduction/what-is-tendermint"
         ]
       },
       {
@@ -48,7 +48,7 @@ module.exports = {
         title: "Networks",
         collapsable: false,
         children: [
-          "/networks/deploy-testnets",
+          "/networks/docker-compose",
           "/networks/terraform-and-ansible",
         ]
       },

docs/README.md

@@ -1,43 +1,27 @@
 # Tendermint
 
-Welcome to the Tendermint Core documentation! Below you'll find an
-overview of the documentation.
+Welcome to the Tendermint Core documentation!
 
-Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state
-transition machine - written in any programming language - and securely
-replicates it on many machines. In other words, a blockchain.
+Tendermint Core is a blockchain application platform; it provides the equivalent
+of a web-server, database, and supporting libraries for blockchain applications
+written in any programming language. Like a web-server serving web applications,
+Tendermint serves blockchain applications.
 
-Tendermint requires an application running over the Application Blockchain
-Interface (ABCI) - and comes packaged with an example application to do so.
+More formally, Tendermint Core performs Byzantine Fault Tolerant (BFT)
+State Machine Replication (SMR) for arbitrary deterministic, finite state machines.
+For more background, see [What is
+Tendermint?](introduction/what-is-tendermint.md).
 
-## Getting Started
+To get started quickly with an example application, see the [quick start guide](introduction/quick-start.md).
 
-Here you'll find quick start guides and links to more advanced "get up and running"
-documentation.
+To learn about application development on Tendermint, see the [Application Blockchain Interface](spec/abci).
 
-## Core
+For more details on using Tendermint, see the respective documentation for
+[Tendermint Core](tendermint-core), [benchmarking and monitoring](tools), and [network deployments](networks).
 
-Details about the core functionality and configuration of Tendermint.
+## Contribute
 
-## Tools
-
-Benchmarking and monitoring tools.
-
-## Networks
-
-Setting up testnets manually or automated, local or in the cloud.
-
-## Apps
-
-Building appplications with the ABCI.
-
-## Specification
-
-Dive deep into the spec. There's one for each Tendermint and the ABCI
-
-## Edit the Documentation
-
-See [this file](./DOCS_README.md) for details of the build process and
+To contribute to the documentation, see [this file](./DOCS_README.md) for details of the build process and
 considerations when making changes.
 
 ## Version

docs/introduction/README.md

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

docs/introduction/introduction.md

@@ -1,5 +1,7 @@
 # What is Tendermint?
 
+DEPRECATED! See [What is Tendermint?](what-is-tendermint.md).
+
 Tendermint is software for securely and consistently replicating an
 application on many machines. By securely, we mean that Tendermint works
 even if up to 1/3 of machines fail in arbitrary ways. By consistently,

docs/introduction/quick-start.md

@@ -1,4 +1,4 @@
-# Tendermint
+# Quick Start
 
 ## Overview
 
@@ -9,45 +9,21 @@ works and want to get started right away, continue.
 
 ### Quick Install
 
-On a fresh Ubuntu 16.04 machine can be done with [this script](https://git.io/fFfOR), like so:
+To quickly get Tendermint installed on a fresh
+Ubuntu 16.04 machine, use [this script](https://git.io/fFfOR).
+
+WARNING: do not run this on your local machine.
 
 ```
 curl -L https://git.io/fFfOR | bash
 source ~/.profile
 ```
 
-WARNING: do not run the above on your local machine.
-
 The script is also used to facilitate cluster deployment below.
 
 ### Manual Install
 
-Requires:
-
-- `go` minimum version 1.10
-- `$GOPATH` environment variable must be set
-- `$GOPATH/bin` must be on your `$PATH` (see [here](https://github.com/tendermint/tendermint/wiki/Setting-GOPATH))
-
-To install Tendermint, run:
-
-```
-go get github.com/tendermint/tendermint
-cd $GOPATH/src/github.com/tendermint/tendermint
-make get_tools && make get_vendor_deps
-make install
-```
-
-Note that `go get` may return an error but it can be ignored.
-
-Confirm installation:
-
-```
-$ tendermint version
-0.23.0
-```
-
-Note: see the [releases page](https://github.com/tendermint/tendermint/releases) and the latest version
-should match what you see above.
+For manual installation, see the [install instructions](install.md)
 
 ## Initialization
 

docs/introduction/what-is-tendermint.md

@@ -0,0 +1,332 @@
+# What is Tendermint?
+
+Tendermint is software for securely and consistently replicating an
+application on many machines. By securely, we mean that Tendermint works
+even if up to 1/3 of machines fail in arbitrary ways. By consistently,
+we mean that every non-faulty machine sees the same transaction log and
+computes the same state. Secure and consistent replication is a
+fundamental problem in distributed systems; it plays a critical role in
+the fault tolerance of a broad range of applications, from currencies,
+to elections, to infrastructure orchestration, and beyond.
+
+The ability to tolerate machines failing in arbitrary ways, including
+becoming malicious, is known as Byzantine fault tolerance (BFT). The
+theory of BFT is decades old, but software implementations have only
+became popular recently, due largely to the success of "blockchain
+technology" like Bitcoin and Ethereum. Blockchain technology is just a
+reformalization of BFT in a more modern setting, with emphasis on
+peer-to-peer networking and cryptographic authentication. The name
+derives from the way transactions are batched in blocks, where each
+block contains a cryptographic hash of the previous one, forming a
+chain. In practice, the blockchain data structure actually optimizes BFT
+design.
+
+Tendermint consists of two chief technical components: a blockchain
+consensus engine and a generic application interface. The consensus
+engine, called Tendermint Core, ensures that the same transactions are
+recorded on every machine in the same order. The application interface,
+called the Application BlockChain Interface (ABCI), enables the
+transactions to be processed in any programming language. Unlike other
+blockchain and consensus solutions, which come pre-packaged with built
+in state machines (like a fancy key-value store, or a quirky scripting
+language), developers can use Tendermint for BFT state machine
+replication of applications written in whatever programming language and
+development environment is right for them.
+
+Tendermint is designed to be easy-to-use, simple-to-understand, highly
+performant, and useful for a wide variety of distributed applications.
+
+## Tendermint vs. X
+
+Tendermint is broadly similar to two classes of software. The first
+class consists of distributed key-value stores, like Zookeeper, etcd,
+and consul, which use non-BFT consensus. The second class is known as
+"blockchain technology", and consists of both cryptocurrencies like
+Bitcoin and Ethereum, and alternative distributed ledger designs like
+Hyperledger's Burrow.
+
+### Zookeeper, etcd, consul
+
+Zookeeper, etcd, and consul are all implementations of a key-value store
+atop a classical, non-BFT consensus algorithm. Zookeeper uses a version
+of Paxos called Zookeeper Atomic Broadcast, while etcd and consul use
+the Raft consensus algorithm, which is much younger and simpler. A
+typical cluster contains 3-5 machines, and can tolerate crash failures
+in up to 1/2 of the machines, but even a single Byzantine fault can
+destroy the system.
+
+Each offering provides a slightly different implementation of a
+featureful key-value store, but all are generally focused around
+providing basic services to distributed systems, such as dynamic
+configuration, service discovery, locking, leader-election, and so on.
+
+Tendermint is in essence similar software, but with two key differences:
+
+- It is Byzantine Fault Tolerant, meaning it can only tolerate up to a
+  1/3 of failures, but those failures can include arbitrary behaviour -
+  including hacking and malicious attacks. - It does not specify a
+  particular application, like a fancy key-value store. Instead, it
+  focuses on arbitrary state machine replication, so developers can build
+  the application logic that's right for them, from key-value store to
+  cryptocurrency to e-voting platform and beyond.
+
+The layout of this Tendermint website content is also ripped directly
+and without shame from [consul.io](https://www.consul.io/) and the other
+[Hashicorp sites](https://www.hashicorp.com/#tools).
+
+### Bitcoin, Ethereum, etc.
+
+Tendermint emerged in the tradition of cryptocurrencies like Bitcoin,
+Ethereum, etc. with the goal of providing a more efficient and secure
+consensus algorithm than Bitcoin's Proof of Work. In the early days,
+Tendermint had a simple currency built in, and to participate in
+consensus, users had to "bond" units of the currency into a security
+deposit which could be revoked if they misbehaved -this is what made
+Tendermint a Proof-of-Stake algorithm.
+
+Since then, Tendermint has evolved to be a general purpose blockchain
+consensus engine that can host arbitrary application states. That means
+it can be used as a plug-and-play replacement for the consensus engines
+of other blockchain software. So one can take the current Ethereum code
+base, whether in Rust, or Go, or Haskell, and run it as a ABCI
+application using Tendermint consensus. Indeed, [we did that with
+Ethereum](https://github.com/cosmos/ethermint). And we plan to do
+the same for Bitcoin, ZCash, and various other deterministic
+applications as well.
+
+Another example of a cryptocurrency application built on Tendermint is
+[the Cosmos network](http://cosmos.network).
+
+### Other Blockchain Projects
+
+[Fabric](https://github.com/hyperledger/fabric) takes a similar approach
+to Tendermint, but is more opinionated about how the state is managed,
+and requires that all application behaviour runs in potentially many
+docker containers, modules it calls "chaincode". It uses an
+implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf).
+from a team at IBM that is [augmented to handle potentially
+non-deterministic
+chaincode](https://www.zurich.ibm.com/~cca/papers/sieve.pdf) It is
+possible to implement this docker-based behaviour as a ABCI app in
+Tendermint, though extending Tendermint to handle non-determinism
+remains for future work.
+
+[Burrow](https://github.com/hyperledger/burrow) is an implementation of
+the Ethereum Virtual Machine and Ethereum transaction mechanics, with
+additional features for a name-registry, permissions, and native
+contracts, and an alternative blockchain API. It uses Tendermint as its
+consensus engine, and provides a particular application state.
+
+## ABCI Overview
+
+The [Application BlockChain Interface
+(ABCI)](https://github.com/tendermint/tendermint/tree/develop/abci)
+allows for Byzantine Fault Tolerant replication of applications
+written in any programming language.
+
+### Motivation
+
+Thus far, all blockchains "stacks" (such as
+[Bitcoin](https://github.com/bitcoin/bitcoin)) have had a monolithic
+design. That is, each blockchain stack is a single program that handles
+all the concerns of a decentralized ledger; this includes P2P
+connectivity, the "mempool" broadcasting of transactions, consensus on
+the most recent block, account balances, Turing-complete contracts,
+user-level permissions, etc.
+
+Using a monolithic architecture is typically bad practice in computer
+science. It makes it difficult to reuse components of the code, and
+attempts to do so result in complex maintenance procedures for forks of
+the codebase. This is especially true when the codebase is not modular
+in design and suffers from "spaghetti code".
+
+Another problem with monolithic design is that it limits you to the
+language of the blockchain stack (or vice versa). In the case of
+Ethereum which supports a Turing-complete bytecode virtual-machine, it
+limits you to languages that compile down to that bytecode; today, those
+are Serpent and Solidity.
+
+In contrast, our approach is to decouple the consensus engine and P2P
+layers from the details of the application state of the particular
+blockchain application. We do this by abstracting away the details of
+the application to an interface, which is implemented as a socket
+protocol.
+
+Thus we have an interface, the Application BlockChain Interface (ABCI),
+and its primary implementation, the Tendermint Socket Protocol (TSP, or
+Teaspoon).
+
+### Intro to ABCI
+
+[Tendermint Core](https://github.com/tendermint/tendermint) (the
+"consensus engine") communicates with the application via a socket
+protocol that satisfies the ABCI.
+
+To draw an analogy, lets talk about a well-known cryptocurrency,
+Bitcoin. Bitcoin is a cryptocurrency blockchain where each node
+maintains a fully audited Unspent Transaction Output (UTXO) database. If
+one wanted to create a Bitcoin-like system on top of ABCI, Tendermint
+Core would be responsible for
+
+- Sharing blocks and transactions between nodes
+- Establishing a canonical/immutable order of transactions
+  (the blockchain)
+
+The application will be responsible for
+
+- Maintaining the UTXO database
+- Validating cryptographic signatures of transactions
+- Preventing transactions from spending non-existent transactions
+- Allowing clients to query the UTXO database.
+
+Tendermint is able to decompose the blockchain design by offering a very
+simple API (ie. the ABCI) between the application process and consensus
+process.
+
+The ABCI consists of 3 primary message types that get delivered from the
+core to the application. The application replies with corresponding
+response messages.
+
+The messages are specified here: [ABCI Message
+Types](https://github.com/tendermint/tendermint/blob/develop/abci/README.md#message-types).
+
+The **DeliverTx** message is the work horse of the application. Each
+transaction in the blockchain is delivered with this message. The
+application needs to validate each transaction received with the
+**DeliverTx** message against the current state, application protocol,
+and the cryptographic credentials of the transaction. A validated
+transaction then needs to update the application state — by binding a
+value into a key values store, or by updating the UTXO database, for
+instance.
+
+The **CheckTx** message is similar to **DeliverTx**, but it's only for
+validating transactions. Tendermint Core's mempool first checks the
+validity of a transaction with **CheckTx**, and only relays valid
+transactions to its peers. For instance, an application may check an
+incrementing sequence number in the transaction and return an error upon
+**CheckTx** if the sequence number is old. Alternatively, they might use
+a capabilities based system that requires capabilities to be renewed
+with every transaction.
+
+The **Commit** message is used to compute a cryptographic commitment to
+the current application state, to be placed into the next block header.
+This has some handy properties. Inconsistencies in updating that state
+will now appear as blockchain forks which catches a whole class of
+programming errors. This also simplifies the development of secure
+lightweight clients, as Merkle-hash proofs can be verified by checking
+against the block hash, and that the block hash is signed by a quorum.
+
+There can be multiple ABCI socket connections to an application.
+Tendermint Core creates three ABCI connections to the application; one
+for the validation of transactions when broadcasting in the mempool, one
+for the consensus engine to run block proposals, and one more for
+querying the application state.
+
+It's probably evident that applications designers need to very carefully
+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)
+
+## A Note on Determinism
+
+The logic for blockchain transaction processing must be deterministic.
+If the application logic weren't deterministic, consensus would not be
+reached among the Tendermint Core replica nodes.
+
+Solidity on Ethereum is a great language of choice for blockchain
+applications because, among other reasons, it is a completely
+deterministic programming language. However, it's also possible to
+create deterministic applications using existing popular languages like
+Java, C++, Python, or Go. Game programmers and blockchain developers are
+already familiar with creating deterministic programs by avoiding
+sources of non-determinism such as:
+
+- random number generators (without deterministic seeding)
+- race conditions on threads (or avoiding threads altogether)
+- the system clock
+- uninitialized memory (in unsafe programming languages like C
+  or C++)
+- [floating point
+  arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/)
+- language features that are random (e.g. map iteration in Go)
+
+While programmers can avoid non-determinism by being careful, it is also
+possible to create a special linter or static analyzer for each language
+to check for determinism. In the future we may work with partners to
+create such tools.
+
+## Consensus Overview
+
+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)
+
+Participants in the protocol are called **validators**; they take turns
+proposing blocks of transactions and voting on them. Blocks are
+committed in a chain, with one block at each **height**. A block may
+fail to be committed, in which case the protocol moves to the next
+**round**, and a new validator gets to propose a block for that height.
+Two stages of voting are required to successfully commit a block; we
+call them **pre-vote** and **pre-commit**. A block is committed when
+more than 2/3 of validators pre-commit for the same block in the same
+round.
+
+There is a picture of a couple doing the polka because validators are
+doing something like a polka dance. When more than two-thirds of the
+validators pre-vote for the same block, we call that a **polka**. Every
+pre-commit must be justified by a polka in the same round.
+
+Validators may fail to commit a block for a number of reasons; the
+current proposer may be offline, or the network may be slow. Tendermint
+allows them to establish that a validator should be skipped. Validators
+wait a small amount of time to receive a complete proposal block from
+the proposer before voting to move to the next round. This reliance on a
+timeout is what makes Tendermint a weakly synchronous protocol, rather
+than an asynchronous one. However, the rest of the protocol is
+asynchronous, and validators only make progress after hearing from more
+than two-thirds of the validator set. A simplifying element of
+Tendermint is that it uses the same mechanism to commit a block as it
+does to skip to the next round.
+
+Assuming less than one-third of the validators are Byzantine, Tendermint
+guarantees that safety will never be violated - that is, validators will
+never commit conflicting blocks at the same height. To do this it
+introduces a few **locking** rules which modulate which paths can be
+followed in the flow diagram. Once a validator precommits a block, it is
+locked on that block. Then,
+
+1.  it must prevote for the block it is locked on
+2.  it can only unlock, and precommit for a new block, if there is a
+    polka for that block in a later round
+
+## Stake
+
+In many systems, not all validators will have the same "weight" in the
+consensus protocol. Thus, we are not so much interested in one-third or
+two-thirds of the validators, but in those proportions of the total
+voting power, which may not be uniformly distributed across individual
+validators.
+
+Since Tendermint can replicate arbitrary applications, it is possible to
+define a currency, and denominate the voting power in that currency.
+When voting power is denominated in a native currency, the system is
+often referred to as Proof-of-Stake. Validators can be forced, by logic
+in the application, to "bond" their currency holdings in a security
+deposit that can be destroyed if they're found to misbehave in the
+consensus protocol. This adds an economic element to the security of the
+protocol, allowing one to quantify the cost of violating the assumption
+that less than one-third of voting power is Byzantine.
+
+The [Cosmos Network](https://cosmos.network) is designed to use this
+Proof-of-Stake mechanism across an array of cryptocurrencies implemented
+as ABCI applications.
+
+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)

docs/networks/README.md

@@ -0,0 +1,9 @@
+# Networks
+
+Use [Docker Compose](docker-compose.md) to spin up Tendermint testnets on your
+local machine.
+
+Use [Terraform and Ansible](terraform-and-ansible.md) to deploy Tendermint
+testnets to the cloud.
+
+See the `tendermint testnet --help` command for more help initializing testnets.

docs/networks/deploy-testnets.md

@@ -1,8 +1,8 @@
 # Deploy a Testnet
 
-Now that we've seen how ABCI works, and even played with a few
-applications on a single validator node, it's time to deploy a test
-network to four validator nodes.
+DEPRECATED DOCS!
+
+See [Networks](../networks).
 
 ## Manual Deployments
 
@@ -21,17 +21,16 @@ Here are the steps to setting up a testnet manually:
 3.  Generate a private key and a node key for each validator using
     `tendermint init`
 4.  Compile a list of public keys for each validator into a
-    `genesis.json` file and replace the existing file with it.
-5.  Run
-    `tendermint node --proxy_app=kvstore --p2p.persistent_peers=< peer addresses >` on each node, where `< peer addresses >` is a comma separated
-    list of the ID@IP:PORT combination for each node. The default port for
-    Tendermint is `26656`. The ID of a node can be obtained by running
-    `tendermint show_node_id` command. Thus, if the IP addresses of your nodes
-    were `192.168.0.1, 192.168.0.2, 192.168.0.3, 192.168.0.4`, the command
-    would look like:
+    new `genesis.json` file and replace the existing file with it.
+5.  Get the node IDs of any peers you want other peers to connect to by
+    running `tendermint show_node_id` on the relevant machine
+6.  Set the `p2p.persistent_peers` in the config for all nodes to the comma
+    separated list of `ID@IP:PORT` for all nodes. Default port is 26656.
+
+Then start the node
 
 ```
-tendermint node --proxy_app=kvstore --p2p.persistent_peers=96663a3dd0d7b9d17d4c8211b191af259621c693@192.168.0.1:26656, 429fcf25974313b95673f58d77eacdd434402665@192.168.0.2:26656, 0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@192.168.0.3:26656, f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@192.168.0.4:26656
+tendermint node --proxy_app=kvstore
 ```
 
 After a few seconds, all the nodes should connect to each other and

docs/networks/docker-compose.md

@@ -0,0 +1,85 @@
+# Docker Compose
+
+With Docker Compose, we can spin up local testnets in a single command:
+
+```
+make localnet-start
+```
+
+## Requirements
+
+- [Install tendermint](/docs/install.md)
+- [Install docker](https://docs.docker.com/engine/installation/)
+- [Install docker-compose](https://docs.docker.com/compose/install/)
+
+## Build
+
+Build the `tendermint` binary and the `tendermint/localnode` docker image.
+
+Note the binary will be mounted into the container so it can be updated without
+rebuilding the image.
+
+```
+cd $GOPATH/src/github.com/tendermint/tendermint
+
+# Build the linux binary in ./build
+make build-linux
+
+# Build tendermint/localnode image
+make build-docker-localnode
+```
+
+
+## Run a testnet
+
+To start a 4 node testnet run:
+
+```
+make localnet-start
+```
+
+The nodes bind their RPC servers to ports 26657, 26660, 26662, and 26664 on the host.
+This file creates a 4-node network using the localnode image.
+The nodes of the network expose their P2P and RPC endpoints to the host machine on ports 26656-26657, 26659-26660, 26661-26662, and 26663-26664 respectively.
+
+To update the binary, just rebuild it and restart the nodes:
+
+```
+make build-linux
+make localnet-stop
+make localnet-start
+```
+
+## Configuration
+
+The `make localnet-start` creates files for a 4-node testnet in `./build` by calling the `tendermint testnet` command.
+
+The `./build` directory is mounted to the `/tendermint` mount point to attach the binary and config files to the container.
+
+For instance, to create a single node testnet:
+
+```
+cd $GOPATH/src/github.com/tendermint/tendermint
+
+# Clear the build folder
+rm -rf ./build
+
+# Build binary
+make build-linux
+
+# Create configuration
+docker run -e LOG="stdout" -v `pwd`/build:/tendermint tendermint/localnode testnet --o . --v 1
+
+#Run the node
+docker run -v `pwd`/build:/tendermint tendermint/localnode
+
+```
+
+## Logging
+
+Log is saved under the attached volume, in the `tendermint.log` file. If the `LOG` environment variable is set to `stdout` at start, the log is not saved, but printed on the screen.
+
+## Special binaries
+
+If you have multiple binaries with different names, you can specify which one to run with the BINARY environment variable. The path of the binary is relative to the attached volume.
+

docs/networks/terraform-and-ansible.md

@@ -29,7 +29,7 @@ export SSH_KEY_FILE="$HOME/.ssh/id_rsa.pub"
 
 These will be used by both `terraform` and `ansible`.
 
-### Terraform
+## Terraform
 
 This step will create four Digital Ocean droplets. First, go to the
 correct directory:
@@ -49,7 +49,7 @@ and you will get a list of IP addresses that belong to your droplets.
 
 With the droplets created and running, let's setup Ansible.
 
-### Ansible
+## Ansible
 
 The playbooks in [the ansible
 directory](https://github.com/tendermint/tendermint/tree/master/networks/remote/ansible)
@@ -144,7 +144,7 @@ Peek at the logs with the status role:
 ansible-playbook -i inventory/digital_ocean.py -l sentrynet status.yml
 ```
 
-### Logging
+## Logging
 
 The crudest way is the status role described above. You can also ship
 logs to Logz.io, an Elastic stack (Elastic search, Logstash and Kibana)
@@ -160,7 +160,7 @@ go get github.com/mheese/journalbeat
 ansible-playbook -i inventory/digital_ocean.py -l sentrynet logzio.yml -e LOGZIO_TOKEN=ABCDEFGHIJKLMNOPQRSTUVWXYZ012345
 ```
 
-### Cleanup
+## Cleanup
 
 To remove your droplets, run:
 

docs/spec/abci/README.md

@@ -1,7 +1,7 @@
 # ABCI
 
 ABCI is the interface between Tendermint (a state-machine replication engine)
-and an application (the actual state machine). It consists of a set of
+and your application (the actual state machine). It consists of a set of
 *methods*, where each method has a corresponding `Request` and `Response`
 message type. Tendermint calls the ABCI methods on the ABCI application by sending the `Request*`
 messages and receiving the `Response*` messages in return.

docs/spec/abci/abci.md

@@ -7,9 +7,9 @@ file](https://github.com/tendermint/tendermint/blob/develop/abci/types/types.pro
 
 ABCI methods are split across 3 separate ABCI *connections*:
 
-- `Consensus Connection: InitChain, BeginBlock, DeliverTx, EndBlock, Commit`
-- `Mempool Connection: CheckTx`
-- `Info Connection: Info, SetOption, Query`
+- `Consensus Connection`: `InitChain, BeginBlock, DeliverTx, EndBlock, Commit`
+- `Mempool Connection`: `CheckTx`
+- `Info Connection`: `Info, SetOption, Query`
 
 The `Consensus Connection` is driven by a consensus protocol and is responsible
 for block execution.

docs/tendermint-core/README.md

@@ -0,0 +1,4 @@
+# Tendermint Core
+
+See the side-bar for details on the various features of Tendermint Core.
+

docs/tools/README.md

@@ -0,0 +1,4 @@
+# Tools
+
+Tendermint comes with some tools for [benchmarking](benchmarking.md)
+and [monitoring](monitoring.md).

docs/tools/benchmarking.md

@@ -20,7 +20,7 @@ Blocks/sec     0.818     0.386      1        9
 
 ## Quick Start
 
-[Install Tendermint](../introduction/install)
+[Install Tendermint](../introduction/install.md)
 This currently is setup to work on tendermint's develop branch. Please ensure
 you are on that. (If not, update `tendermint` and `tmlibs` in gopkg.toml to use
 the master branch.)

docs/tools/monitoring.md

@@ -33,21 +33,21 @@ docker run -it --rm -p "26670:26670" --link=tm tendermint/monitor tm:26657
 
 ### Using Binaries
 
-[Install Tendermint](https://github.com/tendermint/tendermint#install)
+[Install Tendermint](../introduction/install.md).
 
-then run:
+Start a Tendermint node:
 
 ```
 tendermint init
 tendermint node --proxy_app=kvstore
 ```
 
+In another window, run the monitor:
+
 ```
 tm-monitor localhost:26657
 ```
 
-with the last command being in a seperate window.
-
 ## Usage
 
 ```

networks/local/README.md

@@ -1,5 +1,9 @@
 # Local Cluster with Docker Compose
 
+DEPRECATED!
+
+See the [docs](https://tendermint.com/docs/networks/docker-compose.html).
+
 ## Requirements
 
 - [Install tendermint](/docs/install.md)

networks/remote/README.md

@@ -1,3 +1,3 @@
 # Remote Cluster with Terraform and Ansible
 
-See the [docs](/docs/terraform-and-ansible.md)
+See the [docs](https://tendermint.com/docs/networks/terraform-and-ansible.html).