Minor documentation cleanup

This commit fixes some typos and grammar mistakes. It
also fixes some of the long text lines and generally
makes the documentation more readable.

4 files changed, 44 insertions, 35 deletions

diff --git a/docs/Hardening.txt b/docs/Hardening.txt
index d95b2cda..50ccfd53 100644
--- a/docs/Hardening.txt
+++ b/docs/Hardening.txt
@@ -21,7 +21,7 @@ The only people we really trust on the network are the nodes in our friends
 list.
 
 
-The behavior of each Tox node is easily predictable this means that it possible 
+The behavior of each Tox node is easily predictable. This means that it possible 
 for Tox nodes to test the nodes that they are connected to to see if they 
 behave like normal Tox nodes and only send nodes that are confirmed to behave 
 like real Tox nodes as part of send node replies when other nodes query them.
diff --git a/docs/Hardening_docs.txt b/docs/Hardening_docs.txt
index c5de6ade..53a61034 100644
--- a/docs/Hardening_docs.txt
+++ b/docs/Hardening_docs.txt
@@ -1,21 +1,30 @@
 Hardening request packets are sent as crypto request packets (see crypto docs.)
-NOTE: currently only get nodes requests are tested in the code which is why there is only one test (more will be added soon.)
+NOTE: currently only get nodes requests are tested in the code which is why 
+there is only one test (more will be added soon.)
 
-All hardening requests must contain exactly 768 bytes of data. (The data sent must be padded with zeros if it is smaller than that.)
+All hardening requests must contain exactly 768 bytes of data. (The data sent 
+must be padded with zeros if it is smaller than that.)
 
 1. Get the information (IP_port, client_id) of the node we want to test.
 2. Find a couple random nodes that is not that node (one for each test.)
 3. Send crypto request packets to each of these random nodes with the data being:
 
-[byte with value: 02 (get nodes test request)][struct Node_format (the node to test.)][client_id(32 bytes) the id to query the node with.][padding]
+[byte with value: 02 (get nodes test request)][struct Node_format (the node to 
+test.)][client_id(32 bytes) the id to query the node with.][padding]
 
 4. The random node receives a packet.
 -The packet is a get nodes test request:
     send a get_node request to that node with the id to query in the request.
-    when a send_node response is received, send the following response to the person who sent us the get nodes test request packet:
-        [byte with value: 03 (get nodes test response)][client_id(32 bytes): the id of the tested node][The list of nodes it responded with in IPv6 Node format (struct Node_Format)]
-    PROTIP: (get node requests and response contain an encrypted part that you can use to store information so that you don't 
-             have to store in your memory where/if to send back the response from the send node)
+    when a send_node response is received, send the following response to the 
+        person who sent us the get nodes test request packet:
+        [byte with value: 03 (get nodes test response)][client_id(32 bytes): 
+                the id of the tested node][The list of nodes it responded with in IPv6 
+                Node format (struct Node_Format)]
+    PROTIP: (get node requests and response contain an encrypted part that you 
+        can use to store information so that you don't 
+    have to store in your memory where/if to send back the response from the 
+        send node)
 
 5. Receive the test responses.
--If the test(s) pass (the nodes behave in a satisfactory manner), make these nodes have priority over those who don't pass the test(s).
+-If the test(s) pass (the nodes behave in a satisfactory manner), make these 
+nodes have priority over those who don't pass the test(s).
diff --git a/docs/Prevent_Tracking.txt b/docs/Prevent_Tracking.txt
index 07e8ae1e..c5f33e96 100644
--- a/docs/Prevent_Tracking.txt
+++ b/docs/Prevent_Tracking.txt
@@ -21,36 +21,36 @@ So, every node in the DHT now has a temporary keypair not related to their real
 long term one. 
 
 But, how do people find themselves then? We have to add a way for people to 
-tell their friends what their DHT public key is, we also have to somehow make 
-it so people can send/receive friend requests, this has to be done without non 
-friends being able to find out where a node is.
+tell their friends what their DHT public key is. We also have to somehow make 
+it so people can send/receive friend requests. This has to be done without 
+non-friends being able to find out where a node is.
 
 The solution: Onion routing + enable the storage of some small amount of data 
-on 
-DHT nodes.
+on DHT nodes.
 
 
-Alice and bob are friends, before joining the DHT they generate temporary 
+Alice and bob are friends. Before joining the DHT they generate temporary 
 session keypairs to be used for the DHT instead of their long term keys.
 
 Bob finds a bunch of random nodes then picks 3 random working ones (A, B, C).
 
-Bob gets the know working node with an id closest to his real one from his list (D)
+Bob gets the known working node with an id closest to his real one from his list (D)
 
 Bob then creates an onion (the packet will go through A, B, C and will end up at D) 
 announce request packet with his real public key, ping_id as zeros and
 searching for his real public key.
 
-Bob will announce response packets and will recursively send onion announce request packets
-to closer and closer nodes until he finds the ones closest to his real public key.
+Bob will announce response packets and will recursively send onion announce request 
+packets to closer and closer nodes until he finds the ones closest to his real public key.
 
-Once he has done this, he will send some onion announce request packets with the right ping_id previously
-received from the node when he queried it to announce himself to the node.
+Once he has done this, he will send some onion announce request packets with the right 
+ping_id previously received from the node when he queried it to announce himself to the node.
 
-The nodes he announces himself to keep the information to send onion packets to that node in memory.
+The nodes he announces himself to keep the information to send onion packets to that node in 
+memory.
 
-Alice meanwhile searches for the Nodes closest to Bobs real id using a temporary keypair and announce 
-request packets, she does this until she finds nodes that respond with a ping_id of zero.
+Alice meanwhile searches for the nodes closest to Bobs real id using a temporary keypair and 
+announce request packets. She does this until she finds nodes that respond with a ping_id of zero.
 
 She sends data to route request packet with information telling Bob her temporary id in the DHT
 (or a friend request if she is not friends with him).
@@ -58,9 +58,9 @@ She sends data to route request packet with information telling Bob her temporar
 Bob finds her by using her temporary id and they connect to each other.
 
 
-NOTE: crypto_box is used for all the asymmetric encryption and crypto_secretbox is used for all the symmetric.
-Also every DHT node have a random symmetric key which they use to encrypt the stuff in normal get node request that is
-used to encrypt stuff in the following.
+NOTE: crypto_box is used for all the asymmetric encryption and crypto_secretbox is used for all 
+the symmetric. Also every DHT node have a random symmetric key which they use to encrypt the stuff 
+in normal get node request that is used to encrypt stuff in the following.
 
 Onion packet (request):
 
@@ -151,7 +151,7 @@ encrypted with temp symmetric key of Node A: [IP_Port (of us)][data to send back
 
 Data packets:
 
-To tell our friend what our DHT public key is so that he can connect to us we send a data packet with id 156 and 
-the data being:[uint64_t (in network byte order) no_replay, the packet will only be accepted if this number is bigger than the last one recieved]
-[our dht public key][Node_Format * (maximum of 8) nodes closest to us so that the friend can find us faster]
-
+To tell our friend what our DHT public key is so that he can connect to us we send a data packet 
+with id 156 and the data being:[uint64_t (in network byte order) no_replay, the packet will only be 
+accepted if this number is bigger than the last one recieved] [our dht public key][Node_Format * (
+maximum of 8) nodes closest to us so that the friend can find us faster]
diff --git a/docs/TCP_Network.txt b/docs/TCP_Network.txt
index e8608791..b1059892 100644
--- a/docs/TCP_Network.txt
+++ b/docs/TCP_Network.txt
@@ -14,8 +14,8 @@ How it's probably going to work:
 1. Alice, a Tox client on a TCP only network generates a temporary public key 
 and connects to a bootstrap node.
 
-2. Using the bootstrap node she find and connects to a couple (exact number 
-to be determined later) number of random nodes that have TCP relay support.
+2. Using the bootstrap node she finds and connects to a (exact number to be 
+determined later) number of random nodes that have TCP relay support.
 
 3. She uses the onion through the TCP relay connections to send friend requests 
 or tell online friends which TCP nodes she is connected to and her temporary 
@@ -28,8 +28,8 @@ with alice using that temporary public key.
 5. That connection is used by both to transmit encrypted Messenger and A/V 
 packets.
 
-6. If one of the nodes shuts down while it is currently routing traffic, Alice 
-and bob just switch to one of the other nodes they are both connected to.
+6. If one of the nodes shuts down while it is routing traffic, Alice and Bob 
+just switch to one of the other nodes to which they are both connected.
 
 
-Actual detailed implementation details coming soon.
+Actual implementation details coming soon.