Merge pull request #1619 from tendermint/zach/cleaner-repo

clean up links & spec docs

consensus/README.md

@@ -1,18 +1 @@
-# The core consensus algorithm.
-
-* state.go - The state machine as detailed in the whitepaper
-* reactor.go - A reactor that connects the state machine to the gossip network
-
-# Go-routine summary
-
-The reactor runs 2 go-routines for each added peer: gossipDataRoutine and gossipVotesRoutine.
-
-The consensus state runs two persistent go-routines: timeoutRoutine and receiveRoutine.
-Go-routines are also started to trigger timeouts and to avoid blocking when the internalMsgQueue is really backed up.
-
-# Replay/WAL
-
-A write-ahead log is used to record all messages processed by the receiveRoutine,
-which amounts to all inputs to the consensus state machine:
-messages from peers, messages from ourselves, and timeouts.
-They can be played back deterministically at startup or using the replay console. 
+See the [consensus spec](https://github.com/tendermint/tendermint/tree/master/docs/spec/consensus) and the [reactor consensus spec](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/consensus) for more information.

docs/spec/README.md

@@ -14,9 +14,9 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
 
 ### Data Structures
 
-- [Encoding and Digests](./blockchain/encoding.md)
-- [Blockchain](./blockchain/blockchain.md)
-- [State](./blockchain/state.md)
+- [Encoding and Digests](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/encoding.md)
+- [Blockchain](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md)
+- [State](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/state.md)
 
 ### Consensus Protocol
 
@@ -24,11 +24,11 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
 
 ### P2P and Network Protocols
 
-- [The Base P2P Layer](p2p): multiplex the protocols ("reactors") on authenticated and encrypted TCP connections
-- [Peer Exchange (PEX)](reactors/pex): gossip known peer addresses so peers can find each other
-- [Block Sync](reactors/block_sync): gossip blocks so peers can catch up quickly
-- [Consensus](reactors/consensus): gossip votes and block parts so new blocks can be committed
-- [Mempool](reactors/mempool): gossip transactions so they get included in blocks
+- [The Base P2P Layer](https://github.com/tendermint/tendermint/tree/master/docs/spec/p2p): multiplex the protocols ("reactors") on authenticated and encrypted TCP connections
+- [Peer Exchange (PEX)](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/pex): gossip known peer addresses so peers can find each other
+- [Block Sync](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/block_sync): gossip blocks so peers can catch up quickly
+- [Consensus](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/consensus): gossip votes and block parts so new blocks can be committed
+- [Mempool](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/mempool): gossip transactions so they get included in blocks
 - Evidence: TODO
 
 ### More

docs/spec/blockchain/blockchain.md

@@ -162,7 +162,7 @@ We refer to certain globally available objects:
 and `state` keeps track of the validator set, the consensus parameters
 and other results from the application.
 Elements of an object are accessed as expected,
-ie. `block.Header`. See [here](state.md) for the definition of `state`.
+ie. `block.Header`. See [here](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/state.md) for the definition of `state`.
 
 ### Header
 

docs/spec/blockchain/encoding.md

@@ -2,7 +2,7 @@
 
 ## Amino
 
-Tendermint uses the Protobuf3 derrivative [Amino]() for all data structures.
+Tendermint uses the Protobuf3 derivative [Amino](https://github.com/tendermint/go-amino) for all data structures.
 Think of Amino as an object-oriented Protobuf3 with native JSON support.
 The goal of the Amino encoding protocol is to bring parity between application
 logic objects and persistence objects.
@@ -51,8 +51,8 @@ Notice that when encoding byte-arrays, the length of the byte-array is appended
 to the PrefixBytes. Thus the encoding of a byte array becomes `<PrefixBytes>
 <Length> <ByteArray>`
 
-(NOTE: the remainder of this section on Public Key Cryptography can be generated
-from [this script](./scripts/crypto.go))
+NOTE: the remainder of this section on Public Key Cryptography can be generated
+from [this script](https://github.com/tendermint/tendermint/blob/master/docs/spec/scripts/crypto.go)
 
 ### PubKeyEd25519
 
@@ -290,6 +290,7 @@ Amino also supports JSON encoding - registered types are simply encoded as:
   "type": "<DisfixBytes>",
   "value": <JSON>
 }
+```
 
 For instance, an ED25519 PubKey would look like:
 

docs/spec/blockchain/state.md

@@ -77,5 +77,4 @@ func TotalVotingPower(vals []Validators) int64{
 
 ### ConsensusParams
 
-TODO:
-
+TODO

docs/spec/consensus/abci.md

@@ -58,7 +58,7 @@ message Validator {
 ```
 
 The `pub_key` is the Amino encoded public key for the validator. For details on
-Amino encoded public keys, see the [section of the encoding spec](./encoding.md#public-key-cryptography).
+Amino encoded public keys, see the [section of the encoding spec](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/encoding.md#public-key-cryptography).
 
 For Ed25519 pubkeys, the Amino prefix is always "1624DE6220". For example, the 32-byte Ed25519 pubkey
 `76852933A4686A721442E931A8415F62F5F1AEDF4910F1F252FB393F74C40C85` would be
@@ -121,7 +121,6 @@ stateBlockHeight = height of the last block for which Tendermint completed all
     block processing and saved all ABCI results to disk
 appBlockHeight = height of the last block for which ABCI app succesfully
     completely Commit
-
 ```
 
 Note we always have `storeBlockHeight >= stateBlockHeight` and `storeBlockHeight >= appBlockHeight`
@@ -165,4 +164,3 @@ If `storeBlockHeight == stateBlockHeight+1`
 	If appBlockHeight == storeBlockHeight {
 		update the state using the saved ABCI responses but dont run the block against the real app.
 	This happens if we crashed after the app finished Commit but before Tendermint saved the state.
-

docs/spec/p2p/node.md

@@ -12,7 +12,7 @@ Seeds should operate full nodes with the PEX reactor in a "crawler" mode
 that continuously explores to validate the availability of peers.
 
 Seeds should only respond with some top percentile of the best peers it knows about.
-See [the peer-exchange docs](../reactors/pex/pex.md)for details on peer quality.
+See [the peer-exchange docs](https://github.com/tendermint/tendermint/blob/master/docs/spec/reactors/pex/pex.md)for details on peer quality.
 
 ## New Full Node
 

docs/spec/p2p/peer.md

@@ -2,7 +2,7 @@
 
 This document explains how Tendermint Peers are identified and how they connect to one another.
 
-For details on peer discovery, see the [peer exchange (PEX) reactor doc](../reactors/pex/pex.md).
+For details on peer discovery, see the [peer exchange (PEX) reactor doc](https://github.com/tendermint/tendermint/blob/master/docs/spec/reactors/pex/pex.md).
 
 ## Peer Identity
 

docs/spec/reactors/consensus/consensus.md

@@ -16,7 +16,7 @@ explained in a forthcoming document.
 For efficiency reasons, validators in Tendermint consensus protocol do not agree directly on the
 block as the block size is big, i.e., they don't embed the block inside `Proposal` and
 `VoteMessage`. Instead, they reach agreement on the `BlockID` (see `BlockID` definition in
-[Blockchain](blockchain.md) section) that uniquely identifies each block. The block itself is
+[Blockchain](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#blockid) section) that uniquely identifies each block. The block itself is
 disseminated to validator processes using peer-to-peer gossiping protocol. It starts by having a
 proposer first splitting a block into a number of block parts, that are then gossiped between
 processes using `BlockPartMessage`.
@@ -69,7 +69,7 @@ BlockID contains PartSetHeader.
 ## VoteMessage
 
 VoteMessage is sent to vote for some block (or to inform others that a process does not vote in the
-current round). Vote is defined in [Blockchain](blockchain.md) section and contains validator's
+current round). Vote is defined in the [Blockchain](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#blockid) section and contains validator's
 information (validator address and index), height and round for which the vote is sent, vote type,
 blockID if process vote for some block (`nil` otherwise) and a timestamp when the vote is sent. The
 message is signed by the validator private key.

docs/spec/reactors/consensus/proposer-selection.md

@@ -44,4 +44,3 @@ p0, p0, p0, p0, p0, p0, p0, p0, p0, p0, p0, p0, p0, p1, p0, p0, p0, p0, p0, etc
 
 This basically means that almost all rounds have the same proposer. But in this case, the process p0 has anyway enough 
 voting power to decide whatever he wants, so the fact that he coordinates almost all rounds seems correct.
-

docs/spec/reactors/mempool/README.md

@@ -1,11 +0,0 @@
-# Mempool Specification
-
-This package contains documents specifying the functionality
-of the mempool module.
-
-Components:
-
-* [Config](./config.md) - how to configure it
-* [External Messages](./messages.md) - The messages we accept over p2p and rpc interfaces
-* [Functionality](./functionality.md) - high-level description of the functionality it provides
-* [Concurrency Model](./concurrency.md) - What guarantees we provide, what locks we require.

docs/spec/reactors/mempool/messages.md

@@ -32,6 +32,7 @@ wait before returning (sync makes sure CheckTx passes, commit
 makes sure it was included in a signed block).
 
 Request (`POST http://gaia.zone:46657/`):
+
 ```json
 {
  "id": "",
@@ -43,8 +44,8 @@ Request (`POST http://gaia.zone:46657/`):
 }
 ```
 
-
 Response:
+
 ```json
 {
  "error": "",

docs/spec/reactors/pex/pex.md

@@ -117,7 +117,7 @@ current, past, and rate-of-change data to inform peer quality.
 While a PID trust metric has been implemented, it remains for future work
 to use it in the PEX.
 
-See the [trustmetric](../../../architecture/adr-006-trust-metric.md )
-and [trustmetric useage](../../../architecture/adr-007-trust-metric-usage.md )
+See the [trustmetric](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-006-trust-metric.md)
+and [trustmetric useage](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-007-trust-metric-usage.md)
 architecture docs for more details.
 

docs/specification/new-spec/README.md

@@ -1 +1 @@
-Spec moved to [docs/spec](/docs/spec).
+Spec moved to [docs/spec](https://github.com/tendermint/tendermint/tree/master/docs/spec).

p2p/README.md

@@ -4,8 +4,8 @@ The p2p package provides an abstraction around peer-to-peer communication.
 
 Docs:
 
-- [Connection](../docs/spec/p2p/connection.md) for details on how connections and multiplexing work
-- [Peer](../docs/spec/p2p/peer.md) for details on peer ID, handshakes, and peer exchange
-- [Node](../docs/spec/p2p/node.md) for details about different types of nodes and how they should work
-- [Pex](../docs/spec/reactors/pex/pex.md) for details on peer discovery and exchange
-- [Config](../docs/spec/p2p/config.md) for details on some config option
+- [Connection](https://github.com/tendermint/tendermint/blob/master/docs/spec/docs/spec/p2p/connection.md) for details on how connections and multiplexing work
+- [Peer](https://github.com/tendermint/tendermint/blob/master/docs/spec/docs/spec/p2p/peer.md) for details on peer ID, handshakes, and peer exchange
+- [Node](https://github.com/tendermint/tendermint/blob/master/docs/spec/docs/spec/p2p/node.md) for details about different types of nodes and how they should work
+- [Pex](https://github.com/tendermint/tendermint/blob/master/docs/spec/docs/spec/reactors/pex/pex.md) for details on peer discovery and exchange
+- [Config](https://github.com/tendermint/tendermint/blob/master/docs/spec/docs/spec/p2p/config.md) for details on some config option