Updated links in docs to reflect new file locations

docs/source/appendices/consensus.md

@@ -23,7 +23,7 @@ To activate your plugin, you can either set the `consensus_plugin` field in your
 
 ## Plugin API
 
-BigchainDB's [current plugin API](../../bigchaindb/consensus.py) exposes five functions in an `AbstractConsensusRules` class:
+BigchainDB's [current plugin API](https://github.com/bigchaindb/bigchaindb/blob/master/bigchaindb/consensus.py) exposes five functions in an `AbstractConsensusRules` class:
 
 ```python
 validate_transaction(bigchain, transaction)

docs/source/appendices/glossary.md

@@ -4,7 +4,7 @@
 
 **BigchainDB cluster.** A collection of servers running BigchainDB Server software and communicating with each other via RethinkDB protocols. a BigchainDB cluster contains one logical RethinkDB datastore.
 
-**Block.** A collection of up to 1000 transactions, plus other things. They get chained together by votes. See [the section on the block model](models.html#the-block-model).
+**Block.** A collection of up to 1000 transactions, plus other things. They get chained together by votes. See [the section on the block model](../topic-guides/models.html#the-block-model).
 
 **Federation.** 1. An organization with members and some kind of governance structure. 2. The BigchainDB cluster owned and operated by a Federation's members.
 
@@ -12,6 +12,6 @@
 
 **Node.** See _Federation node_.
 
-**Transaction.** The basic informational unit. A transaction can represent the creation or transfer of a digital asset. See [the section on the transaction model](models.html#the-transaction-model).
+**Transaction.** The basic informational unit. A transaction can represent the creation or transfer of a digital asset. See [the section on the transaction model](../topic-guides/models.html#the-transaction-model).
 
-**Vote.** Each federation node in a federation is required to vote on the validity of every block (i.e. whether the block valid or not). A node's vote on a block also includes the id of the block it considers to be the previous block. See [the section on the vote model](models.html#the-vote-model).
+**Vote.** Each federation node in a federation is required to vote on the validity of every block (i.e. whether the block valid or not). A node's vote on a block also includes the id of the block it considers to be the previous block. See [the section on the vote model](../topic-guides/models.html#the-vote-model).

docs/source/appendices/local-rethinkdb-cluster.md

@@ -4,7 +4,7 @@ This section explains one way to deploy a multi-node RethinkDB cluster on one ma
 
 ## Launching More RethinkDB Nodes
 
-Assuming you've already [installed RethinkDB](installing-server.html#install-and-run-rethinkdb-server) and have one RethinkDB node running, here's how you can launch two more nodes on the same machine. First, prepare two additional nodes. Note that the user who starts RethinkDB must have write access to the created directories:
+Assuming you've already [installed RethinkDB](../servers/installing-server.html#install-and-run-rethinkdb-server) and have one RethinkDB node running, here's how you can launch two more nodes on the same machine. First, prepare two additional nodes. Note that the user who starts RethinkDB must have write access to the created directories:
 
     mkdir -p /path/to/node2
     mkdir -p /path/to/node3

docs/source/servers/configuration.md

@@ -64,7 +64,7 @@ environment variables available are:
 - `BIGCHAINDB_STATSD_PORT` defines the port of the statsd server for monitoring.
 - `BIGCHAINDB_STATSD_RATE` is a float between `0` and `1` that defines the fraction of transaction operations sampled.
 - `BIGCHAINDB_API_ENDPOINT` defines the API endpoint to use (e.g. `http://localhost:9984/api/v1`).
-- `BIGCHAINDB_CONSENSUS_PLUGIN` defines the name of the [consensus plugin](consensus.html) to use.
+- `BIGCHAINDB_CONSENSUS_PLUGIN` defines the name of the [consensus plugin](../appendices/consensus.html) to use.
 - `BIGCHAINDB_SERVER_BIND` defines where to bind the server socket, the format is `addr:port` (e.g. `localhost:9984`).
 - `BIGCHAINDB_SERVER_WORKERS` defines the [number of workers](http://docs.gunicorn.org/en/stable/settings.html#workers)
   to start for the server API.

docs/source/servers/deploy-on-aws.md

@@ -8,7 +8,7 @@ This section explains a way to deploy a cluster of BigchainDB nodes on Amazon We
 
 You might ask why one would want to deploy a centrally-controlled BigchainDB cluster. Isn't BigchainDB supposed to be decentralized, where each node is controlled by a different person or organization?
 
-That's true, but there are some reasons why one might want a centrally-controlled cluster: 1) for testing, and 2) for initial deployment. Afterwards, the control of each node can be handed over to a different entity.
+That's true, but there are some reasons why one might want a centrally-controlled cluster: 1) for testing, and 2) for initial deployment, after which the control of each node can be handed over to a different entity.
 
 ## Python Setup
 

docs/source/servers/python-server-api-examples.md

@@ -30,9 +30,7 @@ This instantiates an object `b` of class `Bigchain`. When instantiating a `Bigch
 
 In a federation of BigchainDB nodes, each node has its own `Bigchain` instance.
 
-The `Bigchain` class is the main API for all BigchainDB interactions, right now. It does things that BigchainDB nodes do, but it also does things that BigchainDB clients do. In the future, it will be broken apart into a node/server class and a client class.
-
-The `Bigchain` class is documented in the [Developer Interface](developer-interface.html) section.
+The `Bigchain` class is the main API for all BigchainDB interactions, right now. It does things that BigchainDB nodes do, but it also does things that BigchainDB clients do. In the future, it will be refactored into different parts. The `Bigchain` class is documented [elsewhere (link)](../appendices/the-Bigchain-class.html).
 
 ## Create a Digital Asset
 

docs/source/topic-guides/models.md

@@ -5,7 +5,7 @@ BigchainDB stores all its records in JSON documents.
 The three main kinds of records are transactions, blocks and votes. 
 _Transactions_ are used to register, issue, create or transfer things (e.g. assets). Multiple transactions are combined with some other metadata to form _blocks_. Nodes append _votes_ to blocks. This section is a reference on the details of transactions, blocks and votes.
 
-Below we often refer to cryptographic hashes, keys and signatures. The details of those are covered in [the section on cryptography](cryptography.html).
+Below we often refer to cryptographic hashes, keys and signatures. The details of those are covered in [the section on cryptography](../appendices/cryptography.html).
 
 ## Transaction Concepts