Skip to content

Commit

Permalink
docs(overview): minor edits (#83)
Browse files Browse the repository at this point in the history
  • Loading branch information
varunsrin authored Apr 20, 2023
1 parent 69bafd9 commit b620d18
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions docs/OVERVIEW.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@

## 1. Introduction

Social networks have always been centralized affairs. A single company controls the network, its users, and their data. While common, this model leads to several inevitable problems over time. Users and developers have restricted freedoms and become subject to unwelcome moderation and privacy violations.
Social networks are usually run by a company that controls its users, their data, and their relationships. This model has created many successful products but inevitably tends to the same problems over time. Users and developers have restricted freedoms and become subject to unwelcome moderation and privacy violations.

A [sufficiently decentralized](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) protocol might offer an alternative. Developers can invest in building apps without worrying about getting kicked off the network. Users can invest in their identities knowing that they own their data and can switch apps. While harder to build in the short term, aligning incentives will lead to better long-term outcomes.
A [sufficiently decentralized](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) protocol might offer a better alternative. Developers can invest in building apps without worrying about getting kicked off the network. Users can invest in their identities knowing that they own their data and can switch apps. While harder to build in the short term, aligning incentives will lead to better long-term outcomes.

Prior attempts at decentralization have taken different paths with some limited success. ActivityPub chose federation, SecureScuttlebutt went the peer-to-peer route, and peepeth was blockchain-based. Farcaster borrows from these ideas and proposes a new design that uses blockchains and [conflict-free replicated data types](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) to achieve the following:

Expand Down Expand Up @@ -125,7 +125,7 @@ graph LR

An astute reader will note that Farcaster lacks features common in social networks. Timestamps are unreliable, data isn't permanent and there are no mechanisms for private messaging. The eventually consistent nature of the network also means that developers are exposed to more complexity when building applications.

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, public social networks and can evolve more capabilities over time to unlock more use cases.
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

Expand Down

0 comments on commit b620d18

Please sign in to comment.