Fix typos

README.md

@@ -4,7 +4,7 @@
 
 ## Getting Started
 
-Farcaster is a protocol for building decentralized social apps. This repository contains the technical specification for implementing Farcaster.
+Farcaster is a protocol for building decentralized social apps. This repository contains the technical specifications for implementing Farcaster.
 
 If you are instead looking for:
 

docs/OVERVIEW.md

@@ -80,7 +80,7 @@ Hubs need to synchronize message-graphs across thousands of instances to achieve
 
 Using CRDTs to encode these rules allows message-graphs to achieve consensus without coordination. Users can send updates to many hubs via different apps, and their state will eventually converge. Each message type has a CRDT, which compares incoming messages by resource id to catch conflicts. Last-write-wins rules combined with the timestamp-hash ordering allow for deterministic conflict resolution.
 
-Message-graph CRDTs ensure that operations are commutative, associative, and idempotent while never moving causally backward. Each CRDT has a state $S$ and a merge function $merge(m, S)$ which accepts a message returns a new state $S' >= S$. Such CRDTs are called anonymous delta-state CRDTs[^delta-state] and can sync by comparing missing messages.
+Message-graph CRDTs ensure that operations are commutative, associative, and idempotent while never moving causally backward. Each CRDT has a state $S$ and a merge function $merge(m, S)$ which accepts a message and returns a new state $S' >= S$. Such CRDTs are called anonymous delta-state CRDTs[^delta-state] and can sync by comparing missing messages.
 
 Users must only be able to add a limited amount of data to CRDTs. Otherwise, a Hub becomes impractical to operate affecting the network's decentralization. CRDT's solve this by imposing per-user size limits and evicting messages with the lowest order. Time limits can also be imposed to reduce network size by evicting messages with timestamps older than the cutoff.
 
@@ -127,7 +127,7 @@ An astute reader will note that Farcaster lacks features common in social networ
 
 Farcaster makes these tradeoffs to achieve a level of decentralization that puts users and developers in control. It is far easier to add features to a decentralized network than it is to try and decentralize a feature-rich network. The protocol is robust enough to build simple, practical and public social networks that people will use.
 
-# 7. Acknowledgements
+# 7. Acknowledgments
 
 The Farcaster protocol would not have been possible without significant contributions from [Varun Srinivasan](https://github.com/varunsrin), [Dan Romero](https://github.com/danromero), [Shane da Silva](https://github.com/sds), [Sean Yu](https://github.com/seansu4you87), [Gavi Galloway](https://github.com/gsgalloway), [Paul Fletcher-Hill](https://github.com/pfletcherhill), [Sanjay Prabhu](https://github.com/sanjayprabhu), Sagar Dhawan, [Cassandra Heart](https://github.com/CassOnMars), [Aditya Kulkarni](https://github.com/adityapk00) and [horsefacts](https://github.com/horsefacts).
 

docs/SPECIFICATION.md

@@ -15,7 +15,7 @@ Version: `2023.11.15`
 
 # 1. Smart Contracts
 
-There are a set of 3 contracts that keep track of account ids (fids), keys for the fids and the storage allocated to the fids.
+There is a set of 3 contracts that keep track of account ids (fids), keys for the fids and the storage allocated to the fids.
 
 ## 1.1 Id Registry
 
@@ -35,7 +35,7 @@ The Storage registry contract keeps track of the storage allocated to each fid.
 
 The [canonical Storage registry contract](https://optimistic.etherscan.io/address/0x00000000fcCe7f938e7aE6D3c335bD6a1a7c593D) is deployed at `0x00000000fcCe7f938e7aE6D3c335bD6a1a7c593D` on Optimism.
 
-For a message to be accepted, the fid must be registered in the Id registry, and signed with a valid signer present the Key registry, and the fid must have enough storage allocated in the Storage registry.
+For a message to be accepted, the fid must be registered in the Id registry, and signed with a valid signer present in the Key registry, and the fid must have enough storage allocated in the Storage registry.
 
 # 2. Message Specifications
 
@@ -483,7 +483,7 @@ A UsernameProof message `m` of type `USERNAME_TYPE_ENS_L1` must also pass these
 
 # 3. Message-Graph Specifications
 
-A message-graph is a data structure that allows state to be updated concurrently without requiring a central authority to resolve conflicts. It consists of a series of anonymous Δ-state CRDT's, each of which govern a data type and how it can be updated. The message-graph is idempotent but because of its dependency on state, it is not commutative or associative.
+A message-graph is a data structure that allows state to be updated concurrently without requiring a central authority to resolve conflicts. It consists of a series of anonymous Δ-state CRDT's, each of which governs a data type and how it can be updated. The message-graph is idempotent but because of its dependency on state, it is not commutative or associative.
 
 ## 3.1 CRDTs