Merge pull request #395 from OpenMined/docs2

updates sync docs

docs/syncing.md

@@ -10,10 +10,10 @@ From a high level the clients implements a producer and a consumer. The producer
 2. The current hash of the local file
 3. The curent hash of the remote file
 
-Based on this information, the client determines the location of the change (local vs remote), and what type of modification (create/delete/modify). Based on that, the consumer will take action to sync the file. Syncing the file may entail a download, an upload, a request to apply a diff, a local remove or a request to remove on the server. The logic on the server is very lightweight. It just checked whether this user can make a change based on the permissions, and applies it.
+Based on this information, the client determines the location of the change (local vs remote), and what type of modification (create/delete/modify). Based on that, the consumer will take action to sync the file. Syncing the file may entail a download, an upload, a request to apply a diff, a local remove or a request to remove on the server. The logic on the server is very lightweight, it just checkes whether this user is allowed to make a change based on the permissions, and applies it.
 
-When you start a new syftbox, there are a lot of files to sync. Therefore we are batching the initial set of files to download with a single call.
+When you start a new syftbox, there are a lot of files to sync. Therefore, the initial set of files is downloaded as a batch with a single api call.
 
 ## Datastructures
 
-For performance reasons, we store the file metadata (hashes and more), in a database, such that we can quickly retrieve them when needed.
+For performance reasons, file metadata (hashes, path, etc.) is stored in a database, such that it can be retrieved quickly when needed.