Text corrections

Author: criadoperez

IMPORTERS_EXPORTERS.md

@@ -68,9 +68,9 @@ These are a set of requirements (or guidelines) of the expectations that need to
 
 ```bash
               ┌───────────┐        ┌──────────┐
-┌──────┐      │           │        │          │        ┌───────────────┐
-│ DATA │━━━━━▶│  chunker  │━━━━━━━▶│  layout  │━━━━━━━▶│ DATA formated │
-└──────┘      │           │        │          │        └───────────────┘
+┌──────┐      │           │        │          │        ┌────────────────┐
+│ DATA │━━━━━▶│  chunker  │━━━━━━━▶│  layout  │━━━━━━━▶│ DATA formatted │
+└──────┘      │           │        │          │        └────────────────┘
               └───────────┘        └──────────┘
              ▲                                 ▲
              └─────────────────────────────────┘

img/dex-graphs/arch.txt

@@ -1,7 +1,7 @@
               ┌───────────┐        ┌──────────┐
-┌──────┐      │           │        │          │        ┌───────────────┐
-│ DATA │━━━━━▶│  chunker  │━━━━━━━▶│  layout  │━━━━━━━▶│ DATA formated │
-└──────┘      │           │        │          │        └───────────────┘
+┌──────┐      │           │        │          │        ┌────────────────┐
+│ DATA │━━━━━▶│  chunker  │━━━━━━━▶│  layout  │━━━━━━━▶│ DATA formatted │
+└──────┘      │           │        │          │        └────────────────┘
               └───────────┘        └──────────┘
              ▲                                 ▲
              └─────────────────────────────────┘

src/architecture/principles.md

@@ -119,7 +119,7 @@ principle states that the reliability properties of a protocol have to be
 supported at its endpoints and not in intermediary nodes. For instance, you can best guarantee
 the confidentiality or authenticity of a message by encrypting or signing at one endpoint and
 decrypting or verifying at the other rather than asking relaying nodes to implement local
-protections. IPFS's aproach to robustness, via CIDs, is well aligned with that principle.
+protections. IPFS's approach to robustness, via CIDs, is well aligned with that principle.
 
 ## IPFS Implementation Requirements
 
@@ -247,7 +247,7 @@ authority delegation. This is notably clear in the *URI Ownership* passage of th
 > ultimately resides in the hands of a single social entity. Allowing multiple owners
 > increases the likelihood of URI collisions.
 >
-> URI owners may organize or deploy infrastruture [sic] to ensure that representations of
+> URI owners may organize or deploy infrastructure [sic] to ensure that representations of
 > associated resources are available and, where appropriate, interaction with the resource
 > is possible through the exchange of representations. There are social expectations for
 > responsible representation management (§3.5) by URI owners. Additional social

src/meta/spec-for-specs.md

@@ -151,7 +151,7 @@ available RFC2119 keywords are:
 
 It is probably a bad idea to use the SHALL variants, and generally it is best to stick to MUST, SHOULD, MAY,
 and their negations. In an ideal world, a :ref[spec] would stick to only using MUST and MUST NOT because
-optionality in standards is harmful. In practice, however, some flexibilty can prove necessary.
+optionality in standards is harmful. In practice, however, some flexibility can prove necessary.
 
 :::note
 
@@ -266,7 +266,7 @@ There are two primary types of references: to :ref[definitions] and to full docu
 bibliographic references section.
 
 Once a :ref[definition] has been created, it can be referenced with `:ref[definition]`. This includes the synonyms it
-was givem, for instance :ref[def].
+was given, for instance :ref[def].
 
 It's also possible to reference definitions from other specs by importing those other specs by referencing their :ref[shortnames]
 in the `xref` section of the YAML :ref[frontmatter]: