Changed 'federation' to 'cluster' or 'consortium' in docs and some code

docs/server/source/cloud-deployment-templates/index.rst

@@ -5,7 +5,7 @@ We have some "templates" to deploy a basic, working, but bare-bones BigchainDB n
 
 You don't have to use the tools we use in the templates. You can use whatever tools you prefer.
 
-If you find the cloud deployment templates for nodes helpful, then you may also be interested in our scripts for :doc:`deploying a testing cluster on AWS <../clusters-feds/aws-testing-cluster>` (documented in the Clusters & Federations section).
+If you find the cloud deployment templates for nodes helpful, then you may also be interested in our scripts for :doc:`deploying a testing cluster on AWS <../clusters-feds/aws-testing-cluster>` (documented in the Clusters section).
 
 .. toctree::
    :maxdepth: 1

docs/server/source/clusters-feds/backup.md

@@ -64,7 +64,7 @@ In the future, it will be possible for clients to query for the blocks containin
 
 **How could we be sure blocks and votes from a client are valid?**
 
-All blocks and votes are signed by federation nodes. Only federation nodes can produce valid signatures because only federation nodes have the necessary private keys. A client can't produce a valid signature for a block or vote.
+All blocks and votes are signed by cluster nodes (owned and operated by consortium members). Only cluster nodes can produce valid signatures because only cluster nodes have the necessary private keys. A client can't produce a valid signature for a block or vote.
 
 **Could we restore an entire BigchainDB database using client-saved blocks and votes?**
 
@@ -109,7 +109,7 @@ Considerations for BigchainDB:
 Although it's not advertised as such, RethinkDB's built-in replication feature is similar to continous backup, except the "backup" (i.e. the set of replica shards) is spread across all the nodes. One could take that idea a bit farther by creating a set of backup-only servers with one full backup:
 
 * Give all the original BigchainDB nodes (RethinkDB nodes) the server tag `original`. This is the default if you used the RethinkDB config file suggested in the section titled [Configure RethinkDB Server](../dev-and-test/setup-run-node.html#configure-rethinkdb-server).
-* Set up a group of servers running RethinkDB only, and give them the server tag `backup`. The `backup` servers could be geographically separated from all the `original` nodes (or not; it's up to the federation).
+* Set up a group of servers running RethinkDB only, and give them the server tag `backup`. The `backup` servers could be geographically separated from all the `original` nodes (or not; it's up to the consortium to decide).
 * Clients shouldn't be able to read from or write to servers in the `backup` set.
 * Send a RethinkDB reconfigure command to the RethinkDB cluster to make it so that the `original` set has the same number of replicas as before (or maybe one less), and the `backup` set has one replica. Also, make sure the `primary_replica_tag='original'` so that all primary shards live on the `original` nodes.
 

docs/server/source/clusters-feds/index.rst

@@ -1,10 +1,10 @@
-Clusters & Federations
-======================
+Clusters
+========
 
 .. toctree::
    :maxdepth: 1
 
-   set-up-a-federation
+   set-up-a-cluster
    backup
    aws-testing-cluster
    

docs/server/source/clusters-feds/set-up-a-cluster.md

@@ -1,11 +1,11 @@
-# Set Up a Federation
+# Set Up a Cluster
 
-This section is about how to set up a BigchainDB _federation_, where each node is operated by a different operator. If you want to set up and run a testing cluster on AWS (where all nodes are operated by you), then see [the section about that](aws-testing-cluster.html).
+This section is about how to set up a BigchainDB cluster where each node is operated by a different operator. If you want to set up and run a testing cluster on AWS (where all nodes are operated by you), then see [the section about that](aws-testing-cluster.html).
 
 
 ## Initial Checklist
 
-* Do you have a governance process for making federation-level decisions, such as how to admit new members?
+* Do you have a governance process for making consortium-level decisions, such as how to admit new members?
 * What will you store in creation transactions (data payload)? Is there a data schema?
 * Will you use transfer transactions? Will they include a non-empty data payload?
 * Who will be allowed to submit transactions? Who will be allowed to read or query transactions? How will you enforce the access rules?
@@ -13,7 +13,7 @@ This section is about how to set up a BigchainDB _federation_, where each node i
 
 ## Set Up the Initial Cluster
 
-The federation must decide some things before setting up the initial cluster (initial set of BigchainDB nodes):
+The consortium must decide some things before setting up the initial cluster (initial set of BigchainDB nodes):
 
 1. Who will operate a node in the initial cluster?
 2. What will the replication factor be? (It must be 3 or more for [RethinkDB failover](https://rethinkdb.com/docs/failover/) to work.)
@@ -21,7 +21,7 @@ The federation must decide some things before setting up the initial cluster (in
 
 Once those things have been decided, each node operator can begin setting up their BigchainDB (production) node.
 
-Each node operator will eventually need two pieces of information from all other nodes in the federation:
+Each node operator will eventually need two pieces of information from all other nodes:
 
 1. Their RethinkDB hostname, e.g. `rdb.farm2.organization.org`
 2. Their BigchainDB public key, e.g. `Eky3nkbxDTMgkmiJC8i5hKyVFiAQNmPP4a2G4JdDxJCK`

docs/server/source/data-models/block-model.rst

@@ -11,7 +11,7 @@ A block has the following structure:
         "timestamp": "<block-creation timestamp>",
         "transactions": ["<list of transactions>"],
         "node_pubkey": "<public key of the node creating the block>",
-        "voters": ["<list of federation nodes public keys>"]
+        "voters": ["<list of public keys of all nodes in the cluster>"]
       },
       "signature": "<signature of block>"
     }
@@ -23,9 +23,9 @@ A block has the following structure:
     - ``timestamp``: The Unix time when the block was created. It's provided by the node that created the block.
     - ``transactions``: A list of the transactions included in the block.
     - ``node_pubkey``: The public key of the node that created the block.
-    - ``voters``: A list of the public keys of federation nodes at the time the block was created.
-      It's the list of federation nodes which can cast a vote on this block.
-      This list can change from block to block, as nodes join and leave the federation.
+    - ``voters``: A list of the public keys of all cluster nodes at the time the block was created.
+      It's the list of nodes which can cast a vote on this block.
+      This list can change from block to block, as nodes join and leave the cluster.
 
 - ``signature``: :ref:`Cryptographic signature <Signature Algorithm and Keys>` of the block by the node that created the block (i.e. the node with public key ``node_pubkey``). To generate the signature, the node signs the serialized inner ``block`` (the same thing that was hashed to determine the ``id``) using the private key corresponding to ``node_pubkey``.
 

docs/server/source/introduction.md

@@ -10,7 +10,7 @@ Note that there are a few kinds of nodes:
 
 - A **bare-bones node** is a node deployed in the cloud, either as part of a testing cluster or as a starting point before upgrading the node to be production-ready. Our cloud deployment templates deploy a bare-bones node, as do our scripts for deploying a testing cluster on AWS.
 
-- A **production node** is a node that is part of a federation's BigchainDB cluster. A production node has the most components and requirements.
+- A **production node** is a node that is part of a consortium's BigchainDB cluster. A production node has the most components and requirements.
 
 
 ## Setup Instructions for Various Cases
@@ -19,7 +19,7 @@ Note that there are a few kinds of nodes:
 * [Set up and run a bare-bones node in the cloud](cloud-deployment-templates/index.html)
 * [Set up and run a local dev/test node for developing and testing BigchainDB Server](dev-and-test/setup-run-node.html)
 * [Deploy a testing cluster on AWS](clusters-feds/aws-testing-cluster.html)
-* [Set up and run a federation (including production nodes)](clusters-feds/set-up-a-federation.html)
+* [Set up and run a cluster (including production nodes)](clusters-feds/set-up-a-cluster.html)
 
 Instructions for setting up a client will be provided once there's a public test net.
 

docs/server/source/nodes/node-assumptions.md

@@ -1,12 +1,12 @@
 # Production Node Assumptions
 
-If you're not sure what we mean by a BigchainDB *node*, *cluster*, *federation*, or *production node*, then see [the section in the Introduction where we defined those terms](../introduction.html#some-basic-vocabulary).
+If you're not sure what we mean by a BigchainDB *node*, *cluster*, *consortium*, or *production node*, then see [the section in the Introduction where we defined those terms](../introduction.html#some-basic-vocabulary).
 
 We make some assumptions about production nodes:
 
 1. **Each production node is set up and managed by an experienced professional system administrator (or a team of them).**
 
-2. Each production node in a federation's cluster is managed by a different person or team.
+2. Each production node in a cluster is managed by a different person or team.
 
 Because of the first assumption, we don't provide a detailed cookbook explaining how to secure a server, or other things that a sysadmin should know. (We do provide some [templates](../cloud-deployment-templates/index.html), but those are just a starting point.)
 

docs/server/source/nodes/setup-run-node.md

@@ -19,7 +19,7 @@ There are some [notes on BigchainDB-specific firewall setup](../appendices/firew
 
 A BigchainDB node uses its system clock to generate timestamps for blocks and votes, so that clock should be kept in sync with some standard clock(s). The standard way to do that is to run an NTP daemon (Network Time Protocol daemon) on the node. (You could also use tlsdate, which uses TLS timestamps rather than NTP, but don't: it's not very accurate and it will break with TLS 1.3, which removes the timestamp.)
 
-NTP is a standard protocol. There are many NTP daemons implementing it. We don't recommend a particular one. On the contrary, we recommend that different nodes in a federation run different NTP daemons, so that a problem with one daemon won't affect all nodes.
+NTP is a standard protocol. There are many NTP daemons implementing it. We don't recommend a particular one. On the contrary, we recommend that different nodes in a cluster run different NTP daemons, so that a problem with one daemon won't affect all nodes.
 
 Please see the [notes on NTP daemon setup](../appendices/ntp-notes.html) in the Appendices.
 
@@ -72,7 +72,7 @@ direct-io
 join=node0_hostname:29015
 join=node1_hostname:29015
 join=node2_hostname:29015
-# continue until there's a join= line for each node in the federation
+# continue until there's a join= line for each node in the cluster
 ```
 
 * `directory=/data` tells the RethinkDB node to store its share of the database data in `/data`.
@@ -153,7 +153,7 @@ Edit the created config file:
 
 * Open `$HOME/.bigchaindb` (the created config file) in your text editor.
 * Change `"server": {"bind": "localhost:9984", ... }` to `"server": {"bind": "0.0.0.0:9984", ... }`. This makes it so traffic can come from any IP address to port 9984 (the HTTP Client-Server API port).
-* Change `"keyring": []` to `"keyring": ["public_key_of_other_node_A", "public_key_of_other_node_B", "..."]` i.e. a list of the public keys of all the other nodes in the federation. The keyring should _not_ include your node's public key.
+* Change `"keyring": []` to `"keyring": ["public_key_of_other_node_A", "public_key_of_other_node_B", "..."]` i.e. a list of the public keys of all the other nodes in the cluster. The keyring should _not_ include your node's public key.
 
 For more information about the BigchainDB config file, see [Configuring a BigchainDB Node](configuration.html).
 
@@ -185,7 +185,7 @@ where:
 
 * `bigchaindb init` creates the database within RethinkDB, the tables, the indexes, and the genesis block.
 * `numshards` should be set to the number of nodes in the initial cluster.
-* `numreplicas` should be set to the database replication factor decided by the federation. It must be 3 or more for [RethinkDB failover](https://rethinkdb.com/docs/failover/) to work.
+* `numreplicas` should be set to the database replication factor decided by the consortium. It must be 3 or more for [RethinkDB failover](https://rethinkdb.com/docs/failover/) to work.
 
 Once the RethinkDB database is configured, every node operator can start BigchainDB using:
 ```text