# Decentralizing the Social Graph

*Thanks to Dan Romero, Paul Fletcher-Hill, Cassie Heart, Aditya Kulkarni, Goksu Toprak and Shane da Silva for contributing to this proposal.*

A follow is the atomic unit of a social graph on networks like Twitter and Instagram. It is a literal request to add a user’s posts into your feed and an implicit endorsement that a user is worth listening to. Follows are a status symbol because the number and caliber of followers you have is a transitive proof of credibility. If many people choose to see your posts in their feeds, you must be an interesting person.

The portability of the social graph is necessary for a decentralized network since it is an essential input into features like feed construction and recommendation. If moving clients required rebuilding your social graph from scratch, it would make it less likely that people would switch clients.

## Problem

Outcomes follow incentives on decentralized networks, and the incentives to publish the follow graph correctly are weak. Applications may not publish follows, because publishing them is more work and makes it easier for users to leave. Users themselves may seek out such apps, because they may want the ability to see some users' updates privately.

The problems arise when users want to switch apps and realize that their follow graph isn't portable. At this point, it is too late to resolve the issue and users may just stick with the old applications. Apps that behave incorrectly are rewarded by having better retention, which makes it harder for new apps to compete with them.

In a decentralized network, we claim that it is impossible to incentivize the correct publishing of every follow. There are many cases where apps and users will obscure this, and we must accept that this behavior will exist. A new mechanism is needed that aligns the incentives of the user, application and protocol to publicize the social graph.

## Proposed Solution

We propose a new protocol action called **amp**, which lets a user recommend another user. If @bob amps @alice, @bob publicly recommends @alice as someone worth paying attention to. Implicitly, @bob is also indicating that he is interested in following @alice's casts. Every user can amp up to 100 other users at a time, and each amp lasts for three months.

Amps will become a valuable *recommendation signal* because of their scarcity, which makes it likely that users prioritize them, and their short lifespan, which makes current amps more relevant. Follows, which were effectively unlimited and static, are a much weaker recommendation signal. A follow might be a curiosity (I'm just checking out this person), a social obligation (this person is a friend or investor), or simply an outdated opinion (I haven't bothered to clean up my follow list).

Applications can use the social primitive of an amp in different ways to construct feeds, and amps can be a bootstrapping mechanism to generate an algorithmic feed. Some applications may use amps to generate a chronological feed, allowing users to augment this with an unlimited number of "private follows" specific to the application. Apps will also likely develop features to manage and recommend amplifications to be used based on their recent behaviors.

Users will want to ensure that amps are as public as possible. If an application kept a user's amps hidden, the amps would not be useful, and the user would be less likely to use the application. This creates a much stronger incentive alignment between the protocol, applications, and users, ensuring that amps are published correctly. The publishing of amps guarantees that at least a portion of a user's social graph is committed publicly and is portable across applications.

## Rejected Solutions

### Option A: Implement follows as designed

Farcaster implements follows as designed and clients are encouraged (but not required) to publish follow messages. Merkle Manufactory’s client will publish follows and some other clients will do the same, but some will not. Follows remain a useful but imperfect picture of some users’ preferences.

This approach might be worth pursuing if we believe the above concerns are overblown and most clients will adhere to the spec. The downside is that farcaster and merkle must introduce additional complexity at the protocol and client that some cost to implement now and increasing costs to modify later (if it does not end up working correctly). There is also the perceptual downside of shipping a feature that does not work.

### Option B: Remove follows from the protocol (for now)

Farcaster does not ship follows in v2 and removes the Follow Store entirely. Clients can start by implementing follows in a centralized manner. Well-intentioned clients can expose centralized API’s to export follows (which are easier than Option A). Clients can also can infer follows for users migrating from other apps by examining their replies and reactions and making suggestions.

The main benefit to this approach is reduced work and storage requirements for both protocols and clients. We can take time to reconsider other options for implementing follows on a longer term horizon or stick to this if it ends up working out. The downsides appear minimal, unless we are wrong about the incentive structures and Option A would have worked fine.