docs: Bulk spelling edits (#365)

* IPNS.md | Implementer -> implementor

* REDIRECTS_FILE.md | implementors -> implementers

* PATH_GATEWAY.md | remainer -> parameter

* Bulk edits

Author: ElPaisano

ARCHITECTURE.md

@@ -21,7 +21,7 @@ Note, this document is not meant to be an introduction of the concepts in IPFS a
 - 1. IPFS and the Merkle DAG
 - 2. Nodes and Network Model
 - 3. The Stack
-- 4. Applications and Datastructures -- on top of IPFS
+- 4. Applications and data structures -- on top of IPFS
 - 5. Lifetime of fetching an object
 - 6. IPFS User Interfaces
 
@@ -31,7 +31,7 @@ At the heart of IPFS is the MerkleDAG, a directed acyclic graph whose links are
 
 - authenticated: content can be hashed and verified against the link
 - permanent: once fetched, objects can be cached forever
-- universal: any datastructure can be represented as a merkledag
+- universal: any data structure can be represented as a merkledag
 - decentralized: objects can be created by anyone, without centralized writers
 
 In turn, these yield properties for the system as a whole:
@@ -41,7 +41,7 @@ In turn, these yield properties for the system as a whole:
 - objects can be cached permanently
 - objects can be created and used offline
 - networks can be partitioned and merged
-- any datastructure can be modelled and distributed
+- any data structure can be modelled and distributed
 - (todo: list more)
 
 IPFS is a stack of network protocols that organize agent networks to create, publish, distribute, serve, and download merkledags. It is the authenticated, decentralized, permanent web.
@@ -78,7 +78,7 @@ IPFS has a stack of modular protocols. Each layer may have multiple implementati
 IPFS has five layers:
 
 - **naming** - a self-certifying PKI namespace (IPNS)
-- **merkledag** - datastructure format (thin waist)
+- **merkledag** - data structure format (thin waist)
 - **exchange** - block transport and replication
 - **routing** - locating peers and objects
 - **network** - establishing connections between peers
@@ -103,7 +103,7 @@ The IPFS **Routing** layer serves two important purposes:
 - **peer routing** -- to find other nodes
 - **content routing** -- to find data published to ipfs
 
-The Routing Sytem is an interface that is satisfied by various kinds of implementations. For example:
+The Routing System is an interface that is satisfied by various kinds of implementations. For example:
 
 - **DHTs:** perhaps the most common, DHTs can be used to create a semi-persistent routing record distributed cache in the network.
 - **mdns:** used to find services advertised locally. `mdns` (or `dnssd`) is a local discovery service. We will be using it.
@@ -119,12 +119,12 @@ The IPFS **Block Exchange** takes care of negotiating bulk data transfers. Once
 The Block Exchange is an interface that is satisfied by various kinds of implementations. For example:
 
 - **Bitswap:** our main protocol for exchanging data. It is a generalization
-  of BitTorrent to work with arbitrary (and not known apriori) DAGs.
+  of BitTorrent to work with arbitrary (and not known a priori) DAGs.
 - **HTTP:** a simple exchange can be implemented with HTTP clients and servers.
 
 ## 3.4. Merkledag -- making sense of data
 
-[As discussed above](#IPFS-and-the-Merkle-DAG), the IPFS **merkledag** (also known as IPLD - InterPlanetary Linked Data) is the datastructure at the heart of IPFS. It is an [acyclic directed graph](http://en.wikipedia.org/wiki/Directed_acyclic_graph) whose edges are hashes. Another name for it is the merkleweb.
+[As discussed above](#IPFS-and-the-Merkle-DAG), the IPFS **merkledag** (also known as IPLD - InterPlanetary Linked Data) is the data structure at the heart of IPFS. It is an [acyclic directed graph](http://en.wikipedia.org/wiki/Directed_acyclic_graph) whose edges are hashes. Another name for it is the merkleweb.
 
 The merkledag data structure is:
 
@@ -141,7 +141,7 @@ message MDagNode {
 }
 ```
 
-The merkledag is the "thin waist" of authenticated datastructures. It is a minimal set of information needed to represent + transfer arbitrary authenticated datastructures. More complex datastructures are implemented on top of the merkledag, such as:
+The merkledag is the "thin waist" of authenticated data structures. It is a minimal set of information needed to represent + transfer arbitrary authenticated data structures. More complex data structures are implemented on top of the merkledag, such as:
 
 - **git** and other version control systems
 - **bitcoin** and other blockchains
@@ -177,17 +177,17 @@ IPNS is based on [SFS](http://en.wikipedia.org/wiki/Self-certifying_File_System)
 
 See more in the [IPNS spec](https://github.com/ipfs/specs/blob/master/IPNS.md).
 
-# 4. Applications and Datastructures -- on top of IPFS
+# 4. Applications and Data Structures -- on top of IPFS
 
-The stack described so far is enough to represent arbitrary datastructures and replicate them across the internet. It is also enough to build and deploy decentralized websites.
+The stack described so far is enough to represent arbitrary data structures and replicate them across the internet. It is also enough to build and deploy decentralized websites.
 
-Applications and datastructures on top of IPFS are represented as merkledags. Users can create arbitrary datastructures that extend the merkledag and deploy them to the rest of the world using any of the tools that understand IPFS.
+Applications and data structures on top of IPFS are represented as merkledags. Users can create arbitrary data structures that extend the merkledag and deploy them to the rest of the world using any of the tools that understand IPFS.
 
-See more in the [IPLD datastructures specs](https://github.com/ipld/specs/tree/master/data-structures).
+See more in the [IPLD data structures specs](https://github.com/ipld/specs/tree/master/data-structures).
 
 ## 4.1 unixfs -- representing traditional files
 
-The unix filesystem abstractions -- files and directories -- are the main way people conceive of files in the internet. In IPFS, `unixfs` is a datastructure that represents unix files on top of IPFS. We need a separate datastructure to carry over information like:
+The unix filesystem abstractions -- files and directories -- are the main way people conceive of files in the internet. In IPFS, `unixfs` is a data structure that represents unix files on top of IPFS. We need a separate data structure to carry over information like:
 
 - whether the object represents a file or directory.
 - total sizes, minus indexing overhead

IMPORTERS_EXPORTERS.md

@@ -28,7 +28,7 @@ Lots of discussions around this topic, some of them here:
 
 ## Introduction
 
-Importing data into IPFS can be done in a variety of ways. These are use-case specific, produce different datastructures, produce different graph topologies, and so on. These are not strictly needed in an IPFS implementation, but definitely make it more useful.
+Importing data into IPFS can be done in a variety of ways. These are use-case specific, produce different data structures, produce different graph topologies, and so on. These are not strictly needed in an IPFS implementation, but definitely make it more useful.
 
 These data importing primitives are really just tools on top of IPLD, meaning that these can be generic and separate from IPFS itself.
 
@@ -44,7 +44,7 @@ Essentially, data importing is divided into two parts:
   - fixed size chunking (also known as dumb chunking)
   - rabin fingerprinting
   - dedicated format chunking, these require knowledge of the format and typically only work with certain time of files (e.g. video, audio, images, etc)
-  - special datastructures chunking, formats like, tar, pdf, doc, container and/org vm images fall into this category
+  - special data structures chunking, formats like, tar, pdf, doc, container and/org vm images fall into this category
 
 ### Goals
 
@@ -78,9 +78,9 @@ These are a set of requirements (or guidelines) of the expectations that need to
 ```
 
 - `chunkers or splitters` algorithms that read a stream and produce a series of chunks. for our purposes should be deterministic on the stream. divided into:
-  - `universal chunkers` which work on any streams given to them. (eg size, rabin, etc). should work roughly equally well across inputs.
+  - `universal chunkers` which work on any streams given to them. (e.g. size, rabin, etc). should work roughly equally well across inputs.
   - `specific chunkers` which work on specific types of files (tar splitter, mp4 splitter, etc). special purpose but super useful for big files and special types of data.
-- `layouts or topologies` graph topologies (eg balanced vs trickledag vs ext4, ... etc)
+- `layouts or topologies` graph topologies (e.g. balanced vs trickledag vs ext4, ... etc)
 - `importer` is a process that reads in some data (single file, set of files, archive, db, etc), and outputs a dag. may use many chunkers. may use many layouts.
 
 ## Interfaces

IPIP/0001-lightweight-improvement-proposal-process.md

@@ -103,7 +103,7 @@ Guiding principles:
 - Convention over Byzantine process
   - Proposing a new IPIP should have low cognitive overhead, allowing us to
     focus on specs
-  - Reuse existing Github developer accounts and reputation attached to them
+  - Reuse existing GitHub developer accounts and reputation attached to them
   - One should be able to create a valid IPIP without reading a long explainer
     like this one. Looking at past IPIPs, and then copying a template and
     opening a PR with the proposal should be more than enough.

IPIP_PROCESS.md

@@ -75,7 +75,7 @@ Proposals that were reviewed as useful, but rejected for now, will be moved into
 1. [Specs Stewards] will do an initial triage of newly opened PRs roughly monthly. They'll try to filter out
 noise, so that community consideration is given only to reasonable proposals; others they'll reject.
 2. Specs Stewards will post to the forums linking to the proposal; directing feedback/discussion to
-take place in Github on the PR
+take place in GitHub on the PR
 3. After a month of discussion, Specs Stewards will review again. If there are no substantive disagreements
 with the proposal, including within Spec Stewards, the proposal will be approved.
 4. If discussion or modification is still underway and appears to be leading to a resolution, it can be held
@@ -85,7 +85,7 @@ consideration at a monthly sync, to be announced at least a week ahead of time o
 6. After discussion, Spec Stewards will make call on whether to approve or reject the proposal.
 7. At this point approved proposals get assigned a number (encoded in the filename),
 and merged into the IPIP folder on `main` branch. Potentially useful (but rejected for now)
-proposals should be also merged to `main`, but in a subfolder called `/IPIP/deferred`. Proposals rejected in intial
+proposals should be also merged to `main`, but in a subfolder called `/IPIP/deferred`. Proposals rejected in initial
 triage will simply have the PR declined.
 8. IPIP author and two approving [Specs Stewards] are added to `CODEOWNERS` file to be
 automatically asked to review any future changes to files added or modified by the IPIP.

KEYSTORE.md

@@ -208,7 +208,7 @@ does not linger in memory.
 - DagBuilderHelper needs to be able to encrypt blocks
     - Dag Nodes should be generated like normal, then encrypted, and their parents should
         link to the hash of the encrypted node
-- DagBuilderParams should have extra parameters to acommodate creating a DBH that encrypts the blocks
+- DagBuilderParams should have extra parameters to accommodate creating a DBH that encrypts the blocks
 
 #### New 'Encrypt' package
 

MERKLE_DAG.md

@@ -12,7 +12,7 @@
 
 The _ipfs merkledag_ is a directed acyclic graph whose edges are merkle-links. This means that links to objects can authenticate the objects themselves, and that every object contains a secure representation of its children.
 
-This is a powerful primitive for distributed systems computations. The merkledag simplifies distributed protocols by providing an append-only authenticated datastructure. Parties can communicate and exchange secure references (merkle-links) to objects. The references are enough to verify the correctness of the object at a later time, which allows the objects themselves to be served over untrusted channels. Merkledags also allow the branching of a datastructure and subsequent merging, as in the version control system git. More generally, merkledags simplify the construction of Secure [CRDTs](http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type), which enable distributed, convergent, commutative computation in an authenticated, secure way.
+This is a powerful primitive for distributed systems computations. The merkledag simplifies distributed protocols by providing an append-only authenticated data structure. Parties can communicate and exchange secure references (merkle-links) to objects. The references are enough to verify the correctness of the object at a later time, which allows the objects themselves to be served over untrusted channels. Merkledags also allow the branching of a data structure and subsequent merging, as in the version control system git. More generally, merkledags simplify the construction of Secure [CRDTs](http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type), which enable distributed, convergent, commutative computation in an authenticated, secure way.
 
 ## Table of Contents
 
@@ -23,7 +23,7 @@ TODO
 - `hash` - throughout this document, the word `hash` refers specifically to cryptographic hash functions, such as sha3.
 - `dag` - directed acyclic graph
 - `merkle-link` - a link (graph edge) between two objects, which is (a) represented by the hash of the target object, and (b) embedded in the source object. merkle-links construct graphs (dags) whose links are content-addressed, and authenticated.
-- `merkledag` - the merkledag is a directed acyclic graph whose links are merkle-links (hashes of the content). It is a hash tree, and (under a very loose definition) a merkle tree. Alternative names: the merkle-web, the merkle-forest, the merkle-chain.
+- `merkledag` - the merkledag is a directed acyclic graph whose links are merkle-links (hashes of the content). It is a hash tree, and (under a very loose definition) a Merkle tree. Alternative names: the merkle-web, the merkle-forest, the merkle-chain.
 - `multihash` - the [multihash](https://github.com/jbenet/multihash) format / protocol.
 - `ipfs object` - a node in the ipfs merkledag. It represents a singular entity.
 - `merkledag format` - the format that ipfs objects are expressed with.
@@ -83,7 +83,7 @@ The logical representation is serialized into raw bytes using _protocol buffers_
 ### Real World Examples
 
 Many successful distributed systems employ specialized merkledags at their core:
-- merkle trees -- a special case of the merkle dag -- are a well known cryptographic technique used to authenticate large amounts of data. The original use case involved one-time lamport signatures.
+- Merkle trees -- a special case of the merkledag -- are a well known cryptographic technique used to authenticate large amounts of data. The original use case involved one-time lamport signatures.
 - SFS-RO turns a unix filesystem into a merkledag, constructing a secure, distributed filesystem.
 - git uses a merkledag to enable distributed version control and source code management. Other DVCSes, such as mercurial and monotone, also feature a merkledag.
 - plan9 uses a merkledag to construct its snapshotting filesystems -- Fossil and Venti.
@@ -106,7 +106,7 @@ This kind of modularity enables complicated and powerful applications to be buil
 
 ### Web of Data Structures
 
-In a sense, IPFS is a "web of data-structures", with the merkledag as the common denominator. Agreeing upon a format allows linking different authenticated datastructures to each other, enabling sophisticated distributed applications to easily construct, distribute, and link their data.
+In a sense, IPFS is a "web of data-structures", with the merkledag as the common denominator. Agreeing upon a format allows linking different authenticated data structures to each other, enabling sophisticated distributed applications to easily construct, distribute, and link their data.
 
 ### Linked Data
 
@@ -116,7 +116,7 @@ A powerful result of content (and identity) addressing is that linked data defin
 
 ## Merkledag Notation
 
-To facilitate the definition of other data structures and protocols, we define a notation to express merkledag datastructures. This defines their logical representation, and also a format specification (when using the ipfs merkledag format).
+To facilitate the definition of other data structures and protocols, we define a notation to express merkledag data structures. This defines their logical representation, and also a format specification (when using the ipfs merkledag format).
 
 #### ~~ WIP / TODO ~~
 

REPO_FS.md

@@ -47,7 +47,7 @@ This spec defines `fs-repo` version `1`, its formats, and semantics.
 `./api` is a file that exists to denote an API endpoint to listen to.
 - It MAY exist even if the endpoint is no longer live (i.e. it is a _stale_ or left-over `./api` file).
 
-In the presence of an `./api` file, ipfs tools (eg go-ipfs `ipfs daemon`) MUST attempt to delegate to the endpoint, and MAY remove the file if reasonably certain the file is stale. (e.g. endpoint is local, but no process is live)
+In the presence of an `./api` file, ipfs tools (e.g. go-ipfs `ipfs daemon`) MUST attempt to delegate to the endpoint, and MAY remove the file if reasonably certain the file is stale. (e.g. endpoint is local, but no process is live)
 
 The `./api` file is used in conjunction with the `repo.lock`. Clients may opt to use the api service, or wait until the process holding `repo.lock` exits. The file's content is the api endpoint as a [multiaddr](https://github.com/jbenet/multiaddr)
 

http-gateways/PATH_GATEWAY.md

@@ -94,7 +94,7 @@ specified content path.
 Downloads data at specified **immutable** content path.
 
 - `cid` – a valid content identifier  ([CID](https://docs.ipfs.io/concepts/glossary#cid))
-- `path` – optional path remainer pointing at a file or a directory under the `cid` content root
+- `path` – optional path parameter pointing at a file or a directory under the `cid` content root
 - `params` – optional query parameters that adjust response behavior
 
 ## `HEAD /ipfs/{cid}[/{path}][?{params}]`
@@ -350,7 +350,7 @@ value must be wrapped by double quotes as noted in [RFC7232#Etag](https://httpwg
 
 In many cases it is not enough to base `Etag` value on requested CID.
 
-To ensure `Etag` is unique enough to avoid issues with caching reverse provies
+To ensure `Etag` is unique enough to avoid issues with caching reverse proxies
 and CDNs, implementations should base it on both CID and response type:
 
 - By default, etag should be based on requested CID. Example: `Etag: "bafy…foo"`

http-gateways/REDIRECTS_FILE.md

@@ -34,7 +34,7 @@ This can be used, for example, to enable URL rewriting for hosting a single-page
   - [No Forced Redirects](#no-forced-redirects)
 - [Error Handling](#error-handling)
 - [Security](#security)
-- [Appendix: notes for implementors](#appendix-notes-for-implementors)
+- [Appendix: notes for implementers](#appendix-notes-for-implementors)
   - [Test fixtures](#test-fixtures)
 
 # File Name and Location
@@ -150,7 +150,7 @@ Parsing of the `_redirects` file should be done safely to prevent any sort of in
 
 The [max file size](#max-file-size) helps to prevent an additional [denial of service attack](https://en.wikipedia.org/wiki/Denial-of-service_attack) vector.
 
-# Appendix: notes for implementors
+# Appendix: notes for implementers
 
 ## Test fixtures
 

http-gateways/SUBDOMAIN_GATEWAY.md

@@ -154,7 +154,7 @@ Below MUST be implemented **in addition** to the [HTTP Response section from `PA
 ### `Location` (response header)
 
 Below MUST be implemented **in addition** to
-[`Location` reqirements defined in `PATH_GATEWAY.md`](./PATH_GATEWAY.md#location-response-header).
+[`Location` requirements defined in `PATH_GATEWAY.md`](./PATH_GATEWAY.md#location-response-header).
 
 #### Use in interop with Path Gateway