diff --git a/README.md b/README.md index 1eda47e..83dd71c 100644 --- a/README.md +++ b/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: diff --git a/docs/OVERVIEW.md b/docs/OVERVIEW.md index a93f07a..f78191d 100644 --- a/docs/OVERVIEW.md +++ b/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). diff --git a/docs/SPECIFICATION.md b/docs/SPECIFICATION.md index 5c6da1a..488cabb 100644 --- a/docs/SPECIFICATION.md +++ b/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