ceramicnetwork · omahs · Sep 22, 2023 · Sep 22, 2023 · Sep 22, 2023 · Sep 22, 2023
diff --git a/docs/learn/advanced/consensus.md b/docs/learn/advanced/consensus.md
@@ -26,11 +26,11 @@ Whatever the reason for the diverging logs for a single Stream, it is important
 
 #### Earliest Anchor Wins
 
-Updates to Ceramic Streams are periodically [anchored](../glossary.md#anchor-commit) onto a blockchain (currently Ethereum). This immutable proof-of-publication is used to get a trustless timestamp for when the update occurred. This allows us to safely compare the timestamps associated with different branches of a Stream's log to determine which update happened first. When there are conflicting histories for a Stream log and one branch was anchored earlier than the other, the branch that was anchored earlier wins. If one branch was anchored and the other not, then the branch that was anchored is prefered.
+Updates to Ceramic Streams are periodically [anchored](../glossary.md#anchor-commit) onto a blockchain (currently Ethereum). This immutable proof-of-publication is used to get a trustless timestamp for when the update occurred. This allows us to safely compare the timestamps associated with different branches of a Stream's log to determine which update happened first. When there are conflicting histories for a Stream log and one branch was anchored earlier than the other, the branch that was anchored earlier wins. If one branch was anchored and the other not, then the branch that was anchored is preferred.
 
 #### Longest update chain
 
-The Earliest Anchor Wins rule can solve many problems related to coming to consensus on a Stream's state, but still has issues if multiple updates are created quickly. Since anchors only happen periodically (depends on the anchor service being used, but currently twice a day for the anchor service that 3Box Labs operates for Ceramic mainnet), multiple updates can be created and published before any of them get anchored. In that case, we still need to come to consensus on the current state. When there are conflicting logs for a stream neither of which have been anchored, we prefer whichever log is longer. This ensures that the most active history with the most updates is preserved. If there are conflicting unanchored branches that have the same length, then the system picks the winning log arbtrarily, but deterministically, to ensure that all nodes come to agreement on the same log, even if there is no good information available to use to decide which to prefer. This can result writes being lost in certain rare instances where there are conflicting updates published within a few seconds of each other.
+The Earliest Anchor Wins rule can solve many problems related to coming to consensus on a Stream's state, but still has issues if multiple updates are created quickly. Since anchors only happen periodically (depends on the anchor service being used, but currently twice a day for the anchor service that 3Box Labs operates for Ceramic mainnet), multiple updates can be created and published before any of them get anchored. In that case, we still need to come to consensus on the current state. When there are conflicting logs for a stream neither of which have been anchored, we prefer whichever log is longer. This ensures that the most active history with the most updates is preserved. If there are conflicting unanchored branches that have the same length, then the system picks the winning log arbitrarily, but deterministically, to ensure that all nodes come to agreement on the same log, even if there is no good information available to use to decide which to prefer. This can result in writes being lost in certain rare instances where there are conflicting updates published within a few seconds of each other.
 
 #### Simultaneous updates
 

diff --git a/docs/learn/advanced/data-availability.md b/docs/learn/advanced/data-availability.md
@@ -20,7 +20,7 @@ If the node happens to shut down or restart, the cache will be cleared. Without
 
 Pinning provides a more long-lived mechanism of data persistence for commits. Pinning is a process for instructing a Ceramic node to explicitly host (i.e. "pin") the commits for a specific stream. Since commits are stored in IPLD, Ceramic nodes already contain a bundled [IPFS](../glossary.md#ipfs) node which is where this pinning occurs. IPFS nodes can pin all commits for any stream which is accessible over the Ceramic network to which it is connected. Ceramic pinning can also work using an external IPFS node instead of the bundled internal version.
 
-If developers want the easiest way to make their streams persistent beyond a single session and more resilient against data loss, then pinning is the right option. Ceramic nodes can pin an unlimited number of streams. However, note that if only one IPFS node is pinning a given stream and it disappears forever or gets corrupted, then that stream will be lost. Also, if only one node is pinning a stream (and no other Ceramic nodes have it in cache) and that node goes offline, then that stream will be unavailable to others. Therefore, for improved resilience and data availability it is best to have multiple IPFS nodes running in different envitonments pinning the same streams.
+If developers want the easiest way to make their streams persistent beyond a single session and more resilient against data loss, then pinning is the right option. Ceramic nodes can pin an unlimited number of streams. However, note that if only one IPFS node is pinning a given stream and it disappears forever or gets corrupted, then that stream will be lost. Also, if only one node is pinning a stream (and no other Ceramic nodes have it in cache) and that node goes offline, then that stream will be unavailable to others. Therefore, for improved resilience and data availability it is best to have multiple IPFS nodes running in different environments pinning the same streams.
 
 > See the [Pinning](../../build/javascript/pinning.md) guide for instructions on how to pin streams on a Ceramic node.
 

diff --git a/docs/learn/advanced/overview.md b/docs/learn/advanced/overview.md
@@ -53,7 +53,7 @@ DIDs provide a way to go from a globally-unique, platform-agnostic string identi
 - **[PKH DID Method](../../docs/advanced/standards/accounts/pkh-did.md)**: A DID method that natively supports blockchain accounts. DID documents are statically generated from a blockchain account, allowing blockchain accounts to sign, authorize and authenticate in DID based environments. 
 - **[3ID DID Method](../../docs/advanced/standards/accounts/3id-did.md)**: A DID method that uses Ceramic's Tile Document StreamType to represent a mutable DID document. 3IDs are typically used for end-user accounts. When 3IDs are used in conjunction with [the Identity Index protocol](../../docs/advanced/standards/application-protocols/identity-index.md) and the [3ID Keychain](https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-20/CIP-20.md){:target="\_blank"} (as is implemented in [3ID Connect](../../docs/advanced/standards/accounts/3id-did.md#3id-connect)), a 3ID can easily be controlled with any number of blockchain accounts from any L1 or L2 network. This provides a way to unify a user's identity across all other platforms.
 - **[Key DID Method](../../docs/advanced/standards/accounts/key-did.md)**: A DID method statically generated from any Ed25519 key pair. Key DIDs are typically used for developer accounts. Key DID is lightweight, but the drawback is that its DID document is immutable and has no ability to rotate keys if it is compromised.
-- **[NFT DID Method](../../docs/advanced/standards/accounts/nft-did.md) (coming soon)**: A DID method for any NFT on any blockchain. The DID document is statically generated from on-chain data. The DID associated to the blockchain account of the asset's current owner (using CAIP-10 Links) is the only entity authorized to act on behalf of the NFT DID, authenticate in DID-based systems, and make updates to streams or other data owned by the NFT DID. When owenership of the NFT changes, so does the controller permissions.
+- **[NFT DID Method](../../docs/advanced/standards/accounts/nft-did.md) (coming soon)**: A DID method for any NFT on any blockchain. The DID document is statically generated from on-chain data. The DID associated to the blockchain account of the asset's current owner (using CAIP-10 Links) is the only entity authorized to act on behalf of the NFT DID, authenticate in DID-based systems, and make updates to streams or other data owned by the NFT DID. When ownership of the NFT changes, so does the controller permissions.
 - **[Safe DID Method](../../docs/advanced/standards/accounts/safe-did.md) (coming soon)**: A DID method for a Gnosis Safe smart contract on any blockchain. Typically used for organizations, DAOs, and other multi-sig entities.
 
 ## **Ceramic Network**
@@ -108,9 +108,9 @@ Getting started with Ceramic is simple. Visit the [**Quick Start**](../../build/
 
 ### Tools and services
 
-In addition to various standards referenced throughout this document, the Ceramic community has already begun delevoping many different open source protocols, tools, and services that simplify the experience of developing on Ceramic. Here are a few notable examples:
+In addition to various standards referenced throughout this document, the Ceramic community has already begun developing many different open source protocols, tools, and services that simplify the experience of developing on Ceramic. Here are a few notable examples:
 
-- [**3ID Connect:**](../../docs/advanced/standards/accounts/3id-did.md#3id-connect) A authentication SDK for browser-based applications that allows your users to transact with Ceramic using their blockchain wallet.
+- [**3ID Connect:**](../../docs/advanced/standards/accounts/3id-did.md#3id-connect) An authentication SDK for browser-based applications that allows your users to transact with Ceramic using their blockchain wallet.
 - [**Identity Index (IDX):**](../../docs/advanced/standards/application-protocols/identity-index.md) A protocol for decentralized identity that allows a DID to aggregate an index of all their data from across all apps in one place. IDX enables user-centric data storage, discovery, and interoperability. It is effectively a decentralized, cross-platform user table. IDX can reference all data source types, including Ceramic streams and other peer-to-peer databases and files.
 - [**IdentityLink:**](../../tools/identitylink/overview.md) A service that issues verifiable claims which prove a DID owns various other Web2 social accounts such as Twitter, Github, Discord, Discourse, Telegram, Instagram, etc. Once issued, claims are stored in the DID's Identity Index.
 - [**Documint:**](http://documint.net/){:target="\_blank"} A browser-based IDE for creating and editing streams.

diff --git a/docs/learn/blog.md b/docs/learn/blog.md
@@ -16,7 +16,7 @@ The [**Ceramic Blog**](https://blog.ceramic.network){:target="\_blank"} contains
 
 ## Featured videos
 
-[**Learn how to manage user data in a Web3 app with IDX**](https://blog.ceramic.network/learn-how-to-manage-user-data-in-a-web3-app-with-idx/){:target="\_blank"}: Learn how to manage user data for your Web3 application with IDX. This talk is a workshop from tthe ETHDenver 2021 hackathon.
+[**Learn how to manage user data in a Web3 app with IDX**](https://blog.ceramic.network/learn-how-to-manage-user-data-in-a-web3-app-with-idx/){:target="\_blank"}: Learn how to manage user data for your Web3 application with IDX. This talk is a workshop from the ETHDenver 2021 hackathon.
 
 [**Standards for encrypted and mutable data on IPFS**](https://blog.ceramic.network/standards-for-encrypted-and-mutable-data-on-ipfs/){:target="\_blank"}: Joel talks about new standards for signed, encrypted, mutable data on IPFS. This is a talk from the ETHDenver 2021 hackathon.
 

diff --git a/docs/learn/glossary.md b/docs/learn/glossary.md
@@ -14,7 +14,7 @@ A StreamID is an immutable identifier for a [stream](#stream). StreamIDs enable
 
 ### StreamTypes
 
-StreamTypes are functions used for processing updates to [streams](#streams). StreamTypes handle everything from defining the data structure of the stream, to what can be stored in its [commits](#commits), its state transitition function, [authentication](#authentication) requirements, and [conflict resolution strategy](#conflict-resolution-strategy). Every stream must specify a StreamType; and StreamTypes run on Ceramic [nodes](#nodes). Ceramic comes [pre-installed with various StreamTypes](../docs/advanced/standards/stream-programs/index.md), or you can code your own.
+StreamTypes are functions used for processing updates to [streams](#streams). StreamTypes handle everything from defining the data structure of the stream, to what can be stored in its [commits](#commits), its state transition function, [authentication](#authentication) requirements, and [conflict resolution strategy](#conflict-resolution-strategy). Every stream must specify a StreamType; and StreamTypes run on Ceramic [nodes](#nodes). Ceramic comes [pre-installed with various StreamTypes](../docs/advanced/standards/stream-programs/index.md), or you can code your own.
 
 ### Commits
 

diff --git a/docs/learn/highlighted-projects.md b/docs/learn/highlighted-projects.md
@@ -33,7 +33,7 @@ Decentralized universal profiles available for use throughout the web3 metaverse
 |[Titter](https://twitter.com/dabit3/status/1515698468949573634)|Titter is a prototype of a web3-native social application, using Ceramic for editable, self-sovereign user profiles.|[Demo](https://twitter.com/dabit3/status/1515698468949573634)|[Github](https://github.com/dabit3/titter)|
 
 ### Reputation
-This includes any publicly veriable attestations for skills, credentials, and contribution scores.
+This includes any publicly verifiable attestations for skills, credentials, and contribution scores.
 
 |Project    |Description    |Demo   |Code Repo|
 |-|----|-----|--|

diff --git a/docs/learn/network/clients.md b/docs/learn/network/clients.md
@@ -69,7 +69,7 @@ Should this be its own category, or should this live elsewhere?
 The primary responsibility of an anchor service is to generate anchor records by committing signed records into a blockchain. All of the responsibilities below are in service of this primary responsibility.
 
 #### Merkle tree construction
-Constructs a merkle tree of all signed records that eill be simultaneously committed to a blockchain in a single hash, called a merkle root.
+Constructs a merkle tree of all signed records that will be simultaneously committed to a blockchain in a single hash, called a merkle root.
 
 #### Anchor metadata
 Bloom filter, helps with indexing services.

diff --git a/docs/learn/roadmap.md b/docs/learn/roadmap.md
@@ -5,7 +5,7 @@ to both ComposeDB and the underlying Ceramic protocol. Concurrently, we seek to
 community in shaping Ceramic's future. We value your active participation in helping us prioritize the features 
 and improvements that matter most to our developer base.
 
-**All curent and future projects are outlined in the [Ceramic roadmap](https://github.com/orgs/ceramicstudio/projects/2).**
+**All current and future projects are outlined in the [Ceramic roadmap](https://github.com/orgs/ceramicstudio/projects/2).**
 
 We welcome your feedback and insights on our roadmap priorities. You can show your support or express your concerns
 about projects on the roadmap by upvoting or downvoting them. Additionally, we encourage you to leave more detailed 

diff --git a/docs/pages/3box-migration.md b/docs/pages/3box-migration.md
@@ -8,7 +8,7 @@ Any additional data in 3Box may or may not be migrated by the applications thems
 
 ## **Migration Difficulties**
 
-Most users will be able to migrate without difficulty, but there is a number of known instances where we can not easily migrate your 3ID. In theses cases we will create a new 3ID for you and partially migrate any data that we can. You will be able to re-add any profile data and social links that fail to migrate in the future.
+Most users will be able to migrate without difficulty, but there is a number of known instances where we can not easily migrate your 3ID. In these cases we will create a new 3ID for you and partially migrate any data that we can. You will be able to re-add any profile data and social links that fail to migrate in the future.
 
 **Very Early 3Box Users**
 

diff --git a/docs/protocol/accounts/authorizations.md b/docs/protocol/accounts/authorizations.md
@@ -22,7 +22,7 @@ For example, to authorize an account to write to only two specific streams, you
 
 ### **Models**
 
-The mostly commonly used pattern is to specify authorizations by model streamIds. `model` is a property that can be defined in a streams init event. When specified and used with CACAO it allows a DID and key the ability to write to all streams with this specific model value for that user. 
+The most commonly used pattern is to specify authorizations by model streamIds. `model` is a property that can be defined in a streams init event. When specified and used with CACAO it allows a DID and key the ability to write to all streams with this specific model value for that user. 
 
 !!! note
     Ceramic will likely support other keys and values in streams beyond `model` for authorizations in the future.

diff --git a/docs/protocol/accounts/object-capabilities.md b/docs/protocol/accounts/object-capabilities.md
@@ -21,7 +21,7 @@ CACAO enables the ability for one account to authorize another account to constr
 
 When combined with ["Sign-in with X"](https://chainagnostic.org/CAIPs/caip-122), CACAO unlocks the ability for blockchain accounts to authorize Ceramic accounts (DIDs) to sign data on their behalf. 
 
-This frequently used pattern in Ceramic greatly increases the the usability of user-owned data and public-key cryptography. Thanks to the adoption of blockchain based systems, many users now have the ability to easily sign data in web-based environments using their wallet and blockchain account. 
+This frequently used pattern in Ceramic greatly increases the usability of user-owned data and public-key cryptography. Thanks to the adoption of blockchain based systems, many users now have the ability to easily sign data in web-based environments using their wallet and blockchain account. 
 
 ### **Authorizing sessions**
 

diff --git a/docs/protocol/nodes.md b/docs/protocol/nodes.md
@@ -16,7 +16,7 @@ The following services are typically provided to a Ceramic node by a connected I
 | --- | --- |
 | Gossipsub | Several layers of the libp2p stack are used including GossipSub to query streams and broadcast stream updates in the network. |
 | Kademlia DHT | A distributed hash table for content and peer lookup and discovery. The same DHT table is used as the primary IPFS network.  |
-| Bitswap | Exchange and sync blocks with peers. Allows an event stream to be sycned from one node to another. |
+| Bitswap | Exchange and sync blocks with peers. Allows an event stream to be synced from one node to another. |
 
 ### **Ceramic Services**
 

diff --git a/docs/run/nodes/nodes.md b/docs/run/nodes/nodes.md
@@ -272,7 +272,7 @@ Ceramic nodes rely on IPFS for networking. IPFS nodes connect to each other usin
 
 Additionally, when running IPFS the IPFS API port must be accessible by the Ceramic node. The default API port is `5001`. The IPFS node address will then be passed to Ceramic with the `ipfs.host` option in the Ceramic daemon config file.
 
-### **Connect to the mainnnet anchor service**
+### **Connect to the mainnet anchor service**
 
 For nodes that wish to connect to Ceramic mainnet, the node's IP address will have to be added to the allowlist for the Ceramic Anchor Service node operated by 3BoxLabs. Once you have fully configured your Ceramic node with this guide and have a way to persist its configuration and state, open an issue in the [Ceramic Anchor Allowlist Repo](https://github.com/3box/ceramic-anchor-allowlist) with the public, static *egress* IP address for your Ceramic node, and a brief description of the data persistence setup for the multiaddress, Ceramic State Store, and IPFS Repo. Once your issue is closed, you will be connected to the Ceramic network and the [Ceramic Anchor Service](https://github.com/ceramicnetwork/ceramic-anchor-service).