Fix typos

Author: hsanjuan

content/documentation/collaborative/setup.md

@@ -27,7 +27,7 @@ A summarized version of the instructions for a single peer with default configur
 $ ipfs-cluster-service init --consensus crdt
 $ ipfs-cluster-service daemon
 # Write down:
-# - The generated cluster secret (will need to be re-used in other peers)
+# - The generated cluster secret (will need to be reused in other peers)
 # - The peer ID (this will be a "trusted peer")
 # - The multiaddress on which it will be reachable by other peers (usually /ip4/public_ip/tcp/9096/p2p/peer_id
 ```

content/documentation/guides/metrics.md

@@ -15,7 +15,7 @@ Cluster peers regularly broadcast (using gossipsub) metrics between each others.
 
 The metrics are produced by ["informer" components](../../reference/configuration/#the-informer-section). There are currently several types of metrics:
 
-* `ping`: the lack of pings from a given cluster peer signifies that the peer is down and is used to trigger re-pinnings when enabled. The ping metric includes information about each peer, like its peer name, IPFS daemon ID and addresses etc. which are then re-used to fill-in fields in the pin status objects when requested.
+* `ping`: the lack of pings from a given cluster peer signifies that the peer is down and is used to trigger re-pinnings when enabled. The ping metric includes information about each peer, like its peer name, IPFS daemon ID and addresses etc. which are then reused to fill-in fields in the pin status objects when requested.
 * `freespace`: this metric informs how much free space IPFS has in its repository and is used to decide whether to allocate new pins to this peer or others.
 * `tag:*`: "tag" metric provide values coming from the tag informer. For example, peer may broadcast a metric `tag:group` with value `server`. The values are used by the balanced allocator to distribute pins across different values of a single tag.
 * `pinqueue`: this metric carries the number of items queued to pin and can also be used to avoid pinning on peers with long pinning queues.

content/documentation/guides/security.md

@@ -61,11 +61,11 @@ As explained above, the *shared secret* controls authorization by locking this e
 
 ### HTTP API and IPFS Pinning Service API endpoints
 
-IPFS Cluster peers provide by default an **HTTP API endpoint** and an **IPFS Pinning Service API endpoint** which can be configured with SSL. It also provides a **libp2p API endpoint** for each, which re-uses either the Cluster libp2p host or a specifically configured libp2p host.
+IPFS Cluster peers provide by default an **HTTP API endpoint** and an **IPFS Pinning Service API endpoint** which can be configured with SSL. It also provides a **libp2p API endpoint** for each, which reuses either the Cluster libp2p host or a specifically configured libp2p host.
 
 These endpoints are controlled by the `*.http_listen_multiaddress` (default `/ip4/127.0.0.1/tcp/9094`) and the `*.libp2p_listen_multiaddress` (if a specific `private_key` and `id` are configured in the `restapi/pinsvcapi` sections).
 
-Note that when no additional libp2p host is configured and running in Raft mode, the Cluster's peer libp2p host (which listens on `0.0.0.0`) is re-used to provide the libp2p API endpoint. As explained, this endpoint is only protected by the *cluster secret*. When running in CRDT mode, the libp2p endpoint is disabled, as the cluster secret may be shared and would otherwise expose an open endpoint to the world. In order to run a lib2p API endpoint when using CRDT mode, configure an additional, separate libp2p host in the `restapi` configuration.
+Note that when no additional libp2p host is configured and running in Raft mode, the Cluster's peer libp2p host (which listens on `0.0.0.0`) is reused to provide the libp2p API endpoint. As explained, this endpoint is only protected by the *cluster secret*. When running in CRDT mode, the libp2p endpoint is disabled, as the cluster secret may be shared and would otherwise expose an open endpoint to the world. In order to run a lib2p API endpoint when using CRDT mode, configure an additional, separate libp2p host in the `restapi` configuration.
 
 Both endpoints support **Basic Authentication** but are unauthenticated by default.
 

content/documentation/reference/ctl.md

@@ -52,7 +52,7 @@ Note that unless `--force-http` is passed, using `basic-auth` is only supported
 
 ### Using the libp2p API endpoint
 
-Since `0.3.5`, IPFS Cluster provides a libp2p endpoint for the HTTP API which provides channel security without the need to configure SSL certificates, by either re-using the peer's libp2p host or by setting up a new one with the given parameters in the API configuration.
+Since `0.3.5`, IPFS Cluster provides a libp2p endpoint for the HTTP API which provides channel security without the need to configure SSL certificates, by either reusing the peer's libp2p host or by setting up a new one with the given parameters in the API configuration.
 
 In order to have `ipfs-cluster-ctl` use a libp2p endpoint, provide the `--host` flag as follows:
 

content/news/0.8.0_release.md

@@ -18,7 +18,7 @@ IPFS Cluster 0.8.0 comes out today and includes a revamp of the IPFS Proxy
 endpoint. We have promoted it to be its own API-type component, extracting it
 from the IPFS Connector (which is just the client to IPFS). We have
 additionally made improvements so that it truly mimics IPFS, by dynamically
-extracting headers from the real daemon that can be re-used in the responses
+extracting headers from the real daemon that can be reused in the responses
 handled by Cluster. Thus, there will be no CORS-related breakage when swapping
 out IPFS for Cluster, and custom IPFS headers (i.e. `X-Ipfs-Gateway`) can be
 configured and forwarded by the proxy.