FIP-3: Links

[varunsrin]

FIP: Links

Title: Links
Type: Implementation FIP
Author: Varun Srinivasan (gh: @varunsrin , fc: @v), Cassandra Heart (gh: @CassOnMars , fc: @cassie)

Abstract

A proposal to add Links, a new message type that expresses relationships between users.

Problem

Users of social networks have explicit relationships with other users (e.g. following, subscribing) which is used to generate feeds or make recommendations. Such relationships cannot be stored on Hubs today which makes switching applications difficult for users.

Specification

We propose a new Message type called a Link, which is a long-lived, directed, typed relationship between two users (e.g. Alice follows Bob). Links can express different types of relationships and be upgraded to express relationships between users and non-user objects.

Links are similar to Reactions, except that they never expire due to a time based limit. They require active management from applications to ensure a good user experience when limits are reached (see Appendix A and Appendix B). Each user can store 2500 links, which was chosen after analysis of existing behaviors (see Appendix C). A Link message is at most 164 bytes, which will add a total of 382 GB / million users at most.

Message Data

Add a new LinkBody type to MessageData at the empty position 8.

message MessageData {
  ....
  oneof body {
    ...
    LinkBody link_body = 8;
    ....
  }
}

Message Type

Add LINK_ADD and LINK_REMOVE types at the empty positions 5 and 6.

enum MessageType {
  ...
  MESSAGE_TYPE_LINK_ADD = 5;                 
  MESSAGE_TYPE_LINK_REMOVE = 6;   
  ...
}

Link CRDT

Add a Link CRDT which validates and accepts LinkAdd and LinkRemove messages. The CRDT also ensures that the message m passes these validations:

1. m.signer must be a valid Signer in the add-set of the Signer CRDT for message.fid

A conflict occurs if two messages have the same values for m.data.fid,  m.data.body.target  and  m.data.body.type. Conflicts are resolved with the following rules:

1. If m.data.timestamp is distinct, discard the message with the lower timestamp.
2. If m.data.timestamp is identical and m.data.type is distinct, discard the LinkAdd message.
3. If m.data.timestamp and m.data.type are identical, discard the message with the lowest lexicographical order.

The Link CRDT has a per-user size limit of 2,500.

Link Message

A Link is a relationship between two users which can be one of several types. Links are added with a LinkAdd message and removed with a  LinkRemove message which shares a common body structure.

message LinkBody {
  string type = 1;   
  optional uint32 displayTimestamp = 2; 
  oneof target {
    uint64 fid = 3; 
  }
}

A Link message m must pass these validations and the validations for LinkAdd or LinkRemove:

1. m.signature_scheme must be SIGNATURE_SCHEME_ED25519.
2. m.data.body must be LinkBody.
3. m.data.body.type must be ≤ 8 bytes.
4. m.data.body.target must be a known fid.
5. m.data.body.displayTimestamp must be ≤ m.data.timestamp

A LinkAdd message m is valid only if it passes these validations:

1. m.data.type must be MESSAGE_TYPE_LINK_ADD

A LinkRemove in a message m is valid only if it passes these validations:

1. m.data.type must be MESSAGE_TYPE_LINK_REMOVE

Link APIs

Hubs must also provide the following APIs to fetch Link Messages:

// Returns a single Link message of a specific type between two fids 
rpc GetLink(LinkRequest) returns (Message);

// Returns all Links for a given fid, with optional parameters to filter and sort then
rpc GetLinksByFid(LinksByFidRequest) returns (MessagesResponse);

// Returns all Links to a given fid, with optional parameters to filter and sort then
rpc GetLinksByTarget(LinksByTargetRequest) returns (MessagesResponse);

// A convenience alias on GetLinksByFid
rpc GetAllLinkMessagesByFid(FidRequest) returns (MessagesResponse);

message LinkRequest {
  uint64 fid = 1;
  string link_type = 2;
  oneof target {
    uint64 target_fid = 3;
  }
}

message LinksByFidRequest {
  uint64 fid = 1;
  optional string link_type = 2;
  optional uint32 page_size = 3;
  optional bytes page_token = 4;
  optional bool reverse = 5;
}

message LinksByTargetRequest {
  oneof target {
    uint64 target_fid = 1;
  }
  optional string link_type = 2;
  optional uint32 page_size = 3;
  optional bytes page_token = 4;
  optional bool reverse = 5;
}

Rationale

Why are applications incentivized to publish the follow graphs of their users?

Farcaster cannot enforce publishing of data, but apps are strongly incentivized to publish casts (or users won't get engagement and churn) and weakly incentivized to publish reactions (or users will eventually notice and be annoyed). Publishing follows and other links can be incentivized if users and apps reward others who maintain follow relationships (e.g. airdrops for long term followers). There is some probability that such incentives are too weak to enforce publishing links and we may need to roll back this change.

Why not just extend reactions with a new 'Follow' type and fid target?

Reaction CRDT's expire messages to optimize for storage of a greater number of recent messages, since those are more valuable. The same is not true of Links, where older messages might be more valuable than newer messages and time-based expiry is a bad user experience.

Why is there a string type instead of an enum type like in Reactions?

A string type allows a greater deal of flexibility without requiring protocol changes, at the expense of being slightly larger in size and adding more complexity for apps to interpret and render them. If this works well, it might be worth upgrading reactions to have string types instead of enum types.

Release

Links will be included in the 2023.5.31 protocol release. Adding Links is not backwards compatible since it may cause Hubs to believe they are out of sync. Hubs must not accept Link messages or respond to Link RPC queries until 2023.6.14 or 1686700800000 in unix epoch, when older versions of the Hub are shut down.

Appendix A: Compaction

Message Graph CRDTs impose a per-user limit on the number of messages, and both add and remove messages are counted in the limit. A user who follows 2,500 people and then unfollows 500 people still takes up 2,500 slots because they have 2000 add and 500 remove messages. When the 2501-th message is received, the oldest message is kicked out which is usually a follow, resulting in 2000 add and 500 remove messages.

Applications can improve this UX by re-signing and re-ordering the add messages by giving them a greater timestamp than follows. When the 2501-th message is received, it replaces a remove message, resulting in 2001 adds and 499 removes. This allows users to take advantage of the maximum size allowed by CRDTs. Since timestamps become unreliable, links have an optional display timestamp property that can be set by users to indicate the “real” time of the action.

Apps should pick a full-ness limit (80%) and a compaction threshold (e.g. 1%). If a user adds a message using the application which uses up more than 80% of the CRDT’s limit and more than 1% of the messages are taken up by remove messages, a compaction is triggered. Apps should not trigger compaction constantly or in the background since this can result in network thrash, which may trigger hubs to rate limit the user.

Appendix B: Curation

When users approach their CRDT limit and there is no more room for compaction, some links must be removed to make space for new ones. Apps can make curation suggestions to users to remove unnecessary follows based on interaction or usage patterns.

Since CRDT’s are eventually consistent it may be possible the application is not aware of all the links yet. A user may have 2,495 links on one Hub and 2,500 on another which are in the process of syncing. Apps should therefore recommend curation well before this limit to prevent the oldest link from unintentionally being pruned. As a safety measure, apps can keep track of pruned LinkAdd messages and prompt the user to see if they intended to clear out the links. If not, the user can choose to remove some other Link and regenerate the pruned Link.

Appendix C: Follow Graph Analysis

The following data is taken from Warpcast, which implements a centralized form of follow relationships between users. Warpcast has ~ 12,000 registered users.

Number of follows created by users who were active within the last 90 days:

95th percentile: 307
99th percentile: 1898

Percentage of users active in the last 90 days with > x follows:

1000: 1.63% of users
2000: 0.96% of users
3000: 0.71% of users
4000: 0.61% of users
5000: 0.53% of users

[davidfurlong]

I'd love to see a viable solution to this problem! I agree that there are problems with implementing follows naively.

Making follows more composable or potentially carry more utility could change these incentives. Follows as NFTs does this effectively - although the gas fees for this make it very unappealing. What could an NFT-pseudoequivalent on a hub instead of a blockchain look like?

[TimDaub]

I‘m not able to comprehend the DoS concern here. When someone sends regular messages and they smartly define the timestamp of the message within the tolerance window, can‘t creating casts be equally used as a DoS vector? I‘d assume that both if users spam casts or spam follows, that they‘ll get banned from sending more messages to the nodes, right? E.g. the Fid could be tainted. But what am I missing?

[varunsrin]

there is a limit on casts and all other message types to prevent DoS. this fip is proposing that follows must also do the same.

[TimDaub]

makes sense, I think it‘s reasonable. Out of curiosity, what held you back priorly from adding this constraints and making follows part of the FC protocol?

[varunsrin]

the problems described above

[TimDaub]

@varunsrin Just trying to poke holes in your assumptions a bit further.

E.g. why use 1 message = 1 follow? My understanding is that someone could flood the network with messages and cause the node to use more storage. That‘s bad, OK. But can‘t this practically be prevented by

• allowing someone to follow multiple people in one message
• reducing the message payload for follows (e.g. use an incrementing number to identify the current 10k users instead of 160bit addresses)

[varunsrin]

1. you can use a full state crdt (1 message with entire state) instead of a delta state crdt (1 message per state change), but that leads to a whole class of data loss problems. what happens when A and B update your state at the same time to add a follow? one of the follows is lost forever.

2. we already do this. follows are based on compacted fids, not 160-bit addresses

[gskril]

So to clarify, is this proposal effectively scrapping amps and adding follows to the protocol with a limit (I'm guessing of 10k similar to other message types)? I like it. Would even be in favor of a lower limit on the basis of any time I see an account on Twitter follows ~2k+ people, I somewhat discount the significance of their follow.

I understand the problems you mentioned but I don't totally see how it's different from casts. Wouldn't it also be easier for a client not to publish casts, and the only way a user can find out is by checking other clients? The same thing can be said for private casts and client lock-in.

[varunsrin]

No proposal yet, just circulating the problem to get a first pass of feedback from people.

Difference relative to casts is if I don't push your casts to other apps, you get less engagement and are more likely to stop using my apps. Theres no short-term impact to your engagement or anything else if I don't push your follows.

[gskril]

I feel like this is only true for existing users with large-ish followings, and also assumes that all apps will use the same "following" feed vs an algo-default feed like TikTok. I definitely get your POV but personally don't think it's a reason to not include followers in the protocol. It feels like a core part of the network to me, and fwiw I personally wouldn't switch to a Warpcast competitor today if my followers didn't transfer (which is a good business move for Warpcast, but not ideal for the protocol IMO).

[varunsrin]

I definitely think we should include followers: the question is more about what the right parameters are, whether followers is the right term for it, what the expectations of apps should be etc, how we solve the ux problem around the technical challenges descried above.

[varunsrin]

Solutions (Incentives)

We outline two approaches to the incentive problems above and want to make sure we have buy-in from developers before choosing one. The solutions to technical problems will be discussed in a separate post.

App developers should comment below this with a clear vote for one of the options, or an alternative proposal

Follows

One approach is to simply approximate follows on existing social networks. A new follows CRDT is added which stores 1,000 messages with last-write-wins rules and no expiration, similar to the Signer Set.

Apps like Warpcast, Jam and Discove must agree to not introduce private follows and publish them correctly. The burden is on users to figure out whether their app is publishing correctly and leave for another app if it isn’t.

This model has little short-term risk since users and apps are very familiar with this setup. But it poses greater long-term risk — when a single apps stops publishing some follows, others might follow suit in retaliation.

Amps

Another approach is to introduce Amps, which is like a recast of a user. Amping someone means that you endorse them and all your followers will see their messages more often. Users are more likely to notice if their amps are not published correctly since they are infrequent, public and valuable actions. A new amps CRDT is added which stores 100 messages with last-write-wins rules and a 3 month expiration, similar to the Reaction Set.

Apps must teach users about Amps and if implemented correctly ensures that a small, but very important part of each user’s social graph is published. The cold start problem is partially solved since there is strong incentive for a small but valuable part of the social graph to always live on Hubs. Apps can also support private follows and algo feeds in addition to amps and there is no limitation on what they can do.

This model has more short-term risk since it takes a lot longer to implement at the app level and users may not like it. However, the tradeoff is that it might address the long-term incentive problem much better and be a more durable primitive for decentralized social networks.

[zachterrell57]

TLDR: Follows > Amps

I think this proposal underestimates the importance of follows as a social primitive. One of the major selling points of a (sufficiently) decentralized social media protocol is follower portability, and if that is lost I think you leave a lot of people wondering why they should use Farcaster over another service. Because followers are so important, I think it's unlikely that a client will intentionally withhold their data from the protocol.

Difference relative to casts is if I don't push your casts to other apps, you get less engagement

The same can be said for not publishing follows too, right?

1. Client "GoodCaster" publishes all data, including follows
2. Client "NefariousCaster" withholds their follower data (nefariously)

If I am a user who happens to cast on NefariousCaster, and my following data is withheld, my followers who use Goodcaster won't see them, leading to less engagement, right?

Apps like Warpcast, Jam and Discove must agree to not introduce private follows and publish them correctly

These apps can introduce private follows if they are also propagating public follows, right? As long as users have the ability to follow in the public sense, I see a "private follow" as a useful feature in a client. This would be something that mirrors the functionality of a Twitter list. I personally don't think that clients having a soft agreement to not introduce certain features scales.

I can also see the issue of clients not propagating their data to hubs being solved by the "free market" instead of a protocol restriction. One possibility is that a service could come along that "audits" clients, making sure that they are properly publishing all necessary data.

I think Amps are an interesting and novel feature, but think the core concept is one that should live alongside follows, not a replacement. YouTube does this with a channel being able to recommend other channels. Substack has some sort of "endorsement" feature as well I think.

[davidfurlong]

Another thought: what would a client likely do if there were enough users that wanted to privately follow some other users?

I think there's a credible honest use case for not publishing some follows, when the user wants it to be private. I think we could expect some clients to support both published and private follows in the long run, based on what the user wants. Private follows have other downsides for the user following. The alternative is the user follows some sort of list in a client instead of following a user directly.

An alternative I see is something like a contact book - a private list of follows, that is made available to a client given the user's permission. This may take the form of encrypted follows on the protocol, decryptable by having a valid signer key

[varunsrin]

I think this proposal underestimates the importance of follows as a social primitive

@zachterrell57 i don't think anyone in this thread thinks that decentralizing the social graph is not important. the question is which design will result in the greatest degree of decentralization of the public social graph with the least amount of associated risk.

The same can be said for not publishing follows too, right?

No, Nefarious caster's behavior of not publishing follows created by users of its platform only affects the distribution of people on other platform who are followed by users on Nefarious caster.

One possibility is that a service could come along that "audits" clients, making sure that they are properly publishing all necessary data.

This seems quite tricky in practice both from an implementation perspective and an enforcement perspective. If people start withholding follows, I think the game theory leads to the feature not being used. Which may be OK, and we just have to launch Amps or something else entirely.

[varunsrin]

It seems likely that additional experiences will become contingent on following or following by a certain date - many NFT projects verify twitter following for drops, for example.

@davidfurlong This may be one of the stronger arguments for why follows will work

It also seems to be in direct opposition to the claim that there's a lack of incentive to publish follows - either follows are a helpful signal for other clients or they're not.

A follow can be helpful to clients that use a follow based model and less helpful to other clients that use an ML-based model. If you wanted to be nefarious you'd start by absorbing all the public follows to bootstrap your recommendation algorithm but never publish anything back.

Problem 2. Follows don't expire, so inactive accounts can maintain their status without being active

I'm not too worried about this one personally, anyone who is using follows to "rank" users can easily look at the cast history as well to calculate an aggregated score.

[zachterrell57]

@varunsrin Should have been more clear, I meant "I think this proposal underestimates the importance of follows as they currently exist as a social primitive" (instead of switching to the Amps model)

[lesgreys]

Amps gets my vote.

I think follows at individual client level is better than protocol level. May even act as an incentive driver for clustering differentiation across clients in different industries. Allowing users to port following from client X to Y because X & Y share same graph schema but not with the protocol. Allowing for following to take on a different form within different consumer behaviors. Free markets sound good to me.

Don't fully get how it works, yet. Overall, moving away from follows as a predominant theme is a good move for the future of consumer social. Might be a slightly blind take.

[vernonjohnson]

Adding follows to hubs is a no brainer. I think the incentives issues are overblown. Follows is a core primitive for building a social graph, and is critical for building a basic personalized feed. Without follows being in hubs, clients will be forced to implement their own ad hoc solutions, which fragments users social graphs across different clients. Follow graphs should be portable across clients.

To address the concerns:

1. It 100% affects the UX because it affects the feed. Having this as core hub feature, enshrines follows into the protocol, and encourages clients to publish. If clients don't publish then so be it, this argument applies to other data that's stored as well, including likes and recasts.
2. Not sure what's meant by private follows. I think private accounts would be a bit more common. Clients are free to experiment with this, but not reason to exclude follows entirely from hubs.
3. This is not unique to follows and applies to ALL other protocol actions. Every action has equivalent level of censorship resistance at protocol level. That's the tradeoff of having independent network for protocol, rather than using established BFT networks.
4. Most algorithmic feeds at a bare minimum include follows as variable to inform feed, as well as other actions.

[davidfurlong]

private follows means a client would allow a user to follow another user, but not publish that to the protocol, nor make it visible to other users. The follow would solely be used to curate that user's feed

[vernonjohnson]

Got it. I'm not sure why that issue also wouldn't apply to amps.

[davidfurlong]

Amps are meant to be a signal boost on the protocol to other users as well; A bit like a recast of a profile. Making them private would defeat most of their intended utility, whereas the same isn't true for follows

[prood]

Vote for amps

[michaelhly]

Amps

...
Apps must teach users ...
...
This model has more short-term risk since it takes a lot longer to implement at the app level and users may not like it.

This risk doesn’t make sense to me. Applications without product market fit should only spend time implementing features that benefit their users. Perhaps amps can be reconsidered when there is a sufficient number of clients + active users to test on.

Amps design leans too heavily on application incentives. User behavior of the proposed 3-month ephemeral boost is largely unknown. I think amps should be A/B tested on Warpcast first before being considered for implementation as a protocol primitive.

Observing actual user behavior > hypothesizing in theory.

[davidfurlong]

I think amps should be A/B tested on Warpcast first before being considered for implementation as a protocol primitive.

I think there's some merit to the idea of testing this feature on Warpcast

[ildi-x]

My vote is for integrating follows at the protocol layer. If we want to make good on the promise of enabling devs to build on top of a growing userbase, then it's more benificial for a new app to take advantage of the existing follower social graph. Amps do sound interesting but if I gained a following of 2000+ users on Warpcast, I may be less motivated to join any other client where ill have to start with only 100 of those followers.

I am worried about the tombstone pollution and I fear that users will be confused by it. This is less of an issue if the avg user never gets close to the max number of follow slots allowed. Users would need to be educated on how follows and unfollows count against the total number of slots available.

Im unclear about one thing: if a dev is building a new app and wanted to build a unique follower social graph, could they still do this in a centralized way and simply ignore the decentralized follows that will be provided by hubs?

[davidfurlong]

That's an interesting question - is it easy to tell which Signer created a follow? That would make it easy for a client to partition follows if needed while still publishing to the protocol

[alexpaden]

I'm less concerned about Jam cloning my warpcast (publicly available) follow list and adding ~100 people than I am not having a unique following for the next niche I use farcaster with.

[varunsrin]

@ildi-x I'll write up some thoughts on how apps can automatically handle tombstone pollution and not expose users to it. I think thats a problem we have to solve irrespective of follows or amps, so we can discuss that once there is alignment on which higher level approach to take.

to your second question - yes, apps can do that if they'd like to, theres no way for the protocol to stop them

[ildi-x]

I'm less concerned about Jam cloning my warpcast (publicly available) follow list and adding ~100 people than I am not having a unique following for the next niche I use farcaster with.

@alexpaden I do agree with you that some clients may want to start from scratch. But this is why I asked my second question above and @varunsrin has confirmed that an app can build their own centralized social graph which means you can have a unique following for the next niche app you join. But you lose the benefit of decentralization.

@davidfurlong I would also like to know if its easy to tell which Signer created a follow. Having this would also provide visibility into how individual apps are contributing to user growth of the Farcaster protocol.

[alexpaden]

I'm less concerned about Jam cloning my warpcast (publicly available) follow list and adding ~100 people than I am not having a unique following for the next niche I use farcaster with.

@alexpaden I do agree with you that some clients may want to start from scratch. But this is why I asked my second question above and @varunsrin has confirmed that an app can build their own centralized social graph which means you can have a unique following for the next niche app you join. But you lose the benefit of decentralization.

@davidfurlong I would also like to know if its easy to tell which Signer created a follow. Having this would also provide visibility into how individual apps are contributing to user growth of the Farcaster protocol.

I see, that makes sense. So I guess something like private follow (centralized) or super follow (decentralized).

[mko4444]

I vote for follows

• Follows are a form of consumption and amps are a form of expression. They’re two different behaviors IMO and I don’t think one can just replace the other.
• A portable follow graph is something a lot of people want and thus could serve as a selling point to potential users. I haven't heard anyone ask for something like amps.
• Amps still confuse me, and if they confuse me they will definitely confuse new users.
• Amps could be a fun experiment in WC (in addition to follows), but I don't think it's worth risking adoption of the protocol over it.
• Follows are Lindy

[codewithmilo]

Another vote for follows!

• As I understand Amps, they actually remove control of feeds from users: if user A amps user B, I see user B more often but I had no input into that. That seems like unexpected and not-ideal behavior in an era where users want more control over the content they receive
• Also, amps seem even more difficult to notice than follows. In the above example, how do either users A or B know that A's followers are seeing more of B? They'd also still rely on follows: if follows didn't reliably move across clients, amps would behave completely differently on different clients as well.
• Follows in my mind are essential to addressing cold start for new apps: we can push culturally for them to be published by clients, but not having them feels like a huge issue
• Agree with some other comments about having both public/private follows in clients is a great option. This would kind of address the "finsta" phenomenon, where I could have a different set of follows on different clients, e.g. for images/video vs text/essays

Those are my thoughts, but also just want to say how neat and fun it is to be able to think about this and participate in the discussion. Love you all! 💜

[alexpaden]

I just don't think follows make sense outside of a single theme (such as Warpcast or, more broadly, Ethereum).

I care more about distribution than individual followers, especially after several years. Amps, despite the cartoonish name, seem like a better way to reach a wider audience and achieve more distribution.

On my old Twitter account, I had around 2,000 or 3,000 followers, but only about 100 of them were meaningfully related to Ethereum or crypto, which is my main reason for using social media these days. Moreover, it seems like you're suggesting that following would be capped. In my opinion, that's even worse. The only argument supporting this, from a consumer perspective, is the follower-to-following ratio, but that's subjective and would make gaining followers even more difficult, potentially creating an unfair advantage worse than the auto-follow-50 feature.

[varunsrin]

@alexpaden i'm not sure i understand your comment

[gskril]

fwiw I think 1k messages (so in practice less than 1k follows) is too low of a limit, but definitely agree that having some sort of limit is a good thing. Anytime I see a Twitter account that follows >~3k people I immediately get a sense of spam activity.

[alexpaden]

fwiw I think 1k messages (so in practice less than 1k follows) is too low of a limit, but definitely agree that having some sort of limit is a good thing. Anytime I see a Twitter account that follows >~3k people I immediately get a sense of spam activity.

This # is pretty subjective, though. For example, garry tan follows 4k. While the perception is probably true on Twitter (I'm guilty of ratio thoughts), esp web3 twitter, it doesn't seem like it holds true on FC. I went from 6 new followers in a week to 40 in a day where people read my feed and interact with old content simply because I followed them on WC.

I've tested quite a few growth metrics from liking, replying, following, and nothing on WC. It's pretty clear that following people is where new activity is coming from for me. And that's against my desire to have a 1:10 ratio

This is merely my opinion on why it's bad for me in the short term.

[alexpaden]

Rate-limits could be a better way of limiting storage impact; I also agree that actually capping data seems harmful.

@codewithmilo I don't think capping data is that bad. The median farcaster user has something like 150 follows and the 99th percentile is something like 400. Twitter has a cap (~5000 for most users) and this doesn't seem to cause any problems for them. Most other social networks have something similar to prevent follow abuse.

Rate limits don't prevent unbounded storage growth, see this for rationale on why we need hard storage limits: https://hackmd.io/@farcasterxyz/BJj3zuVVj

This isn't entirely true.

Twitter STARTS a cap at 5K; they do not cap it at 5K. You can follow 4 million people on Twitter if you want (and deploy tactics for maintaining ratio) https://www.trackalytics.com/the-most-following-twitter-profiles/page/1/

Facebook also uses a 5K friend cap. However, there is no publicly disclosed follow limit on Facebook.

In the short term, I think you're discounting the game of social media with this.
In the long term, I just don't understand how I can use multiple niches, and in any world, 1k (or lets say 3k) is a good number.

For context, I had probably 2k friends on Facebook from racing before I stopped adding people, I had 2k on Twitter before I decided I wanted a new niche and moved on from my childhood account. I had a modern industry cyber security list on LinkedIn. (Reddit, snapchat, myspace, and every pilot social app I tried for a month or that went bust.)
I guess I just don't understand how any cap like this would suit me back then, and definitely not as working online and growing a digital audience increases in the future. I think most perfected ratios are from existing elite professionals and celebrities, not people who started building the network through the social itself (referencing @tszzl at 6k following again, and his bad ratio as a growth tactic which worked for micro-celebrity when paired with knowledge).

Hope this clarifies some. Otherwise, I likely don't understand the topic well enough to continue.

[codewithmilo]

Thanks @varunsrin for the context, that was a great read. One thought is agreement with folks that dropping the earliest follows when the limit is reached could be trouble...maybe a more complicated calculation, something like least interacted with, or least active?

[TheLDB]

I'm more inclined to lean towards follows here instead of Amps

Amps feel very limiting in a way, and like trying to reinvent the social wheel whereas thus far I have seen Farcaster as a better wheel. It does everything a social system should allow you to do, just better, with decentralization and portability.

If anything, Amps sound like more of a client-side optimization in terms of the feed and algorithm vs something the protocol should be incentivizing (vs a follow list that apps can simply pull a chron feed based off of)

As stated there has to be a follow cap obviously because of network limitations and attacks, I have a couple of thoughts on this:

1. 1,000 feels pretty limiting especially for the bigger accounts as the protocol scales
2. Could some level of a second-hand off-protocol, yet still decentralized/trustful layer or solution co-exist with protocol data to allow additional follows? Obviously this can exist in app-by-app basis but then comes the issue of portability and censorship.

It just makes me worried about limiting a users functionality on a protocol level, at scale. Feels like it'll push people away when they learn the tech behind their favorite social app is actually limiting their experience, especially if something like AT Protocol comes along and says "oh we'll allow you to follow up to 20,000 people"

[betashop]

Hi, I've written a ton of notes on this but I'm not prepared to publish them all yet as I want to offer clear well-thought through proposals rather than just fast opinions/reactions.

I do think there are potentially better options/alternatives than the 2 proposed, but I'm not in a position to share them quite yet and I don't feel great about being rushed to have a vote by end of week on this. (It feels like 90+ days of "it's definitely not follows" followed by 1 week of, "everyone vote on follows ASAP!")

What I can share now is probably more helpful for the debate: what we plan to do at Jam, regardless of the decision around Follows / Amps -- so core team can factor that into their thinking.

We do not plan to have Follows on Jam. We plan to have a For You feed which presents casts and content users might like based on all of the signals we are able to get about their preferences on Jam, on Farcaster apps/clients, and elsewhere on-chain and off-chain. We plan to give users full control over their For You and enable them to create custom feeds as well. We will introduce other ways to interact with and consume content beyond twitter-like feeds from follows. And we will make attempts to be interoperable with other apps and networks; the ethereum ecosystem does not stop at Farcaster's hubs. I'm putting all this out there because i think it's important for core devs and the ecosystem to understand how one of the top FC clients/apps thinks about this.

On the Follow/Amps debate: I do think there are opportunities for Farcaster to introduce new web3 primitives for social engagement that go beyond web2 follows, and that if we do pursue a new web3 social model it can help us move past the twitter-clone state of farcaster today and help unleash new apps and models. That said, it's also is very hard for new apps to solve the cold start and keep up with Warpcast without starting with some sort of follows. So i understand both sides of the debate.

If i was absolutely forced to vote today, i'd prob vote against follows, but in favor of a different type of Amp that enables us to solve the cold start with on-chain capturing of user's interests across all the farcaster apps/clients. Both from engagements with other users and with the engagements with objects in the newest version of the protocol.

I worry about statements like this one: "Apps like Warpcast, Jam and Discove must agree to not introduce private follows" -- is our "For You" private following? I don't think so -- would be important to clear up now though if FC is going to issue such an edict to FC apps.

Last point for now. For a long while i was very frustrated by the idea of Warpcast having follows when its not in the protocol, as it gives WC a huge advantage on other apps as the "home app" and especially as the onboarding app for everyone until the end of the year. But then I was like, whatevs it, it'll just motivate us to try to build something different, which is probably better for everyone anyways.

[varunsrin]

OK, my main takeaways are:

1. You're not going to publish follows, but might read follows from other apps and use it to improve Jam's For You feed.

2. You're not choosing any of the proposed alternatives, or committing to proposing an alternative in any timeframe.

Let me know if I'm interpreting this incorrectly. My responses:

(1) is fine by me I think this is an inevitable consequence of the design, and I appreciate you being transparent about it, and other apps can make their decisions accordingly.

(2) is fine too, we're not closing the door on changing this in the future, so if you come back with something that is clearly better and easy to implement, we can always evolve the protocol.

[betashop]

1a. If follows are made available in the protocol, we'll read them. If they're not, we'll deal with whatever we get in the protocol. We're not stressed by it.

1b. We're not going to have follows on Jam, so there would be no way to publish follows per se from Jam. We could publish who people add/remove from their for you feed but it's different from a follows list. Not opposed to it.

2. I'm working on proposing alternatives. Hoping to get it over today.

[codewithmilo]

We could publish who people add/remove from their for you feed but it's different from a follows list.

How does this work? What's materially different about following someone vs "adding someone to appear in a personalized feed"?

[betashop]

User can select people to add or remove from their For You. The machine also adds people automatically based on the user's engagement. Users can always remove/edit who is in their For You though (override the machine). But it's not a follow. There's no notice to the other user that they've been followed, and no public indication of who follows who. It's a personalized feed, not a social connection.

[lyoshenka]

Two thoughts

1

In addition to @davidfurlong’s great point about follower-based experiences, here are two more incentives for apps to publish all follows:

• The top creators on social media are very narcissistic. I’m not judging, just observing a personality trait. They want high follower numbers, so they will be loudly against apps that don’t publish all follows.
• Top creators can also make money from sponsors and advertisers (eg most podcasts out there). Sponsors will pay more to creators with more followers. So creators will advocate to their followers to use public follows.

2

On the other hand, by having a 1000 follower limit, you are all but ensuring that apps will implement private follows. As an app dev, I’m not going to force my users to understand why they can only follow so many accounts. No other service works that way, and it’s not what users want. Instead I’m just gonna work around it somehow, most likely by hiding the limit from users and doing private follows or by not doing follows at all.

Edit: after reading more comments, id update point 2 to say that this may not be a big deal since it won’t affect most ppl (and the cap can be raised too). I still think it’s a real effect in principle.

[varunsrin]

yeah the 1,000 limit is chosen because:

1. we need some limit on a users total data set and the less we allocate to follows the more we can allocate to casts
2. 99.9% of non bot users don't seem to be close to hitting it
3. better to start lower and go higher later than the other way around

[TimDaub]

If one could pack all follows in a bloom filter, e.g. 2^16 bits is just 8 kilobytes but 65k follows, and I think it can be made quite efficient where we try to map FID space into it (only 10k or so rn).

Seems premature to decide for or against follows with a vote as I‘m sure we can come up with an appropriate solution for eg node-based follows with enough consideration being put into it. Design space is still quite underexplored.

[varunsrin]

What happens if two apps add a follow at the same time generating two distinct bloom filters? My guess is that one of the app's follows must be discarded, which is not a great user experience.

The reason we chose delta-state CRDT is for maximal concurrency - even if you have multiple apps changing data simultaneously they will always merge safely. Bloom filters imply an architecture change to full-state CRDTs instead of delta-state CRDTs since there is no way to delta update a bloom filter AFAIK.

[TimDaub]

makes sense. I could imagine there there is a middle ground though where one can leverage bloom filters and delta updates. I‘ll think about it some more.

[thebillzh]

If I had to choose, I'd pick follow.

However, I'd suggest:

1. Build follow into the protocol

2. Start testing amp on WC immediately, with centralized API publishing amp data to ecosystem devs. Evaluate effectiveness in 1-2 months and decide if we should put it into protocol

3. Encourage devs to build toolings that will publish the "honesty score" of each client. The goal is to make sure clients are doing what they say they plan to - if they commit to publish follows, the community can check if they are withholding any following data. If a client doesn't want to publish follows / doesn't have follows, it is perfectly fine as long as they are transparent about it. I imagine this would not be a fully automated solution, but still doable.

Ultimately, users have the biggest incentives to push clients to be honest because they don't want to be locked in - so we just need to leverage free market while brining transparency into what clients are really doing.

[zachterrell57]

@billzhengC I had a similar suggestion to 3), @varunsrin thinks it might be too tricky though

[thebillzh]

Just saw Varun's reply

This seems quite tricky in practice both from an implementation perspective and an enforcement perspective. If people start withholding follows, I think the game theory leads to the feature not being used. Which may be OK, and we just have to launch Amps or something else entirely.

I think if people start withholding follows, users deserve to know and there are (non-automated) ways to find out.

[michaelhly]

What about punting 1 and just do 2 and see what happens?

[varunsrin]

a lot of clients are dependent on (1) via the warpcast apis, and i think its important that warpcast apis do not offer any data that does not exist on hubs so that we can move to a permissionless system as quickly as possible

[thebillzh]

we can move to a permissionless system as quickly as possible

Absolutely - that's our shared mission.

But how do we test amp?

[michaelhly]

On testing Amps on Warpcast,

• If people end up not liking Amps, regular Warpcast users might naturally try out alternative clients like Discove and Jam
• If improved or no noticeable user behavior changes -> proceed to implement it into the protocol

~3000 MAU is not a great sample size but it's better than what we have here

[betashop]

Below is a theoretical discussion about a different option. It’s not yet at the technical proposal level. I'd love to see a group of us spend some cycles thinking this through together.

–

Rather than rush into a decision on Follows, I propose we take a step back and think more holistically about how to create a system that enables a wide range of social applications to flourish, supporting all sorts of models that clients can choose to implement, including Follows and alternative social models, as desired.

What I propose is a framework that:
Enables clients to contribute to and benefit from from various signals about users’ relationships with users and objects
Enables users to control their own data

Introducing: Caster Scores
A method for recording and managing user’s interests towards other users and towards content and objects on the Farcaster network

Devs should be able to propose variables that get added to Caster Scores.

FIP-1 Canonical URIs #72 provides a good precedent. Similar to how devs can propose new URIs that get added to “a finite and mutually agreed upon set of URIs” (that will will result in maximal cross compatibility across different clients. Each client can deterministically know if it can render all valid content produced by other applications) – I recommend that devs can propose new CSV’s (Cast Score Variables) that can be accepted into the protocol.

Here are just some example of CSV’s that could be added by clients and made available to other clients through the protocol:

• Like cast by person (Alice likes a cast by Bob)
• Recast cast by person (Alice recasts a cast by Bob)
• Reply to cast by person (Alice replies to a cast by Bob)
• Follow Person (Alice follows Bob)
• Connection (Alice follows Bob, Bob follows Alice)
• Collect cast by Person (Alice collects a cast by Bob)
• Subscribe to Person (Alice pays to subscribe to content from Bob)
• Upvote cast by Person (Alice upvotes a cast by Bob)
• Member of same group (e.g. own same NFT)
• Token ownership
• DAO participation
• Cast an object (Alice casts an NFT, POAP, Token, News article, etc.)
• Like an object (Alice likes an NFT, POAP, Token, News article, etc.)
• Reply to an object
• Could be even more granular/specific in the future (earned POAP, voted on a DAO proposal)
• Upvote an object
• Subscribe to an object
• Block a person
• Mute a person

Devs can propose new CSVs that are considered and approved or rejected via technical governance or some sort of DAO voting.

Approved CSVs are made available for all devs to submit and read from.

Clients submit CSVs by posting messages to the protocol.
(There could also be other ways of just submitting verifiable on-chain data (e.g. token ownership) but i'm not sure yet how.)

The protocol enables clients to read all of the CS scores of all users (e.g. Alice liked content by Bob 973 times across 15 different clients)

Clients are able to decide on their own how they want to make use of CSVs and implement whatever front end models they desire with them.

Users are able to access their CSVs and delete or expire records as desired. At some point users could even control which apps get access to their CSVs.

Other considerations over time:

• Rewards for CS contributors (supply side)
• Costs for accessing CS (demand side)
• Scores could be assigned to different CSVs (e.g. Mutual Connection is 10 CS score, whereas one way following is 5, and liking is 1), however I think this might be overkill – it could be just left to clients to figure out the scorings on their own.

[michaelhly]

Same as Amps, should be tested on real users.

If teams are concerned that the sample size is too small to run tests, then apps should focus on delivering more value to users, and protocol should focus on delivering more value to apps.

[varunsrin]

Rather than rush into a decision on Follows, I propose we take a step back and think more holistically about how to create a system that enables a wide range of social applications to flourish, supporting all sorts of models that clients can choose to implement, including Follows and alternative social models, as desired.

Connection (Alice follows Bob, Bob follows Alice)

for the most part, this just seems like an extension to add more types beyond follows and likes? it should be not too hard to make the follow data structure flexible like the reactions data structure so you can add types later and i can work that into the current proposal.

[betashop]

sort of.

A difference is, rather than writing in stone that Farcaster = follows, I'm suggesting build a framework that is flexible and enables there to be all sorts of flavors, whether it's follows, amps, up votes, subscriptions, memberships, ownership, etc.

[varunsrin]

A difference is, rather than writing in stone that Farcaster = follows, I'm suggesting build a framework that is flexible and enables there to be all sorts of flavors, whether it's follows, amps, up votes, subscriptions, memberships, ownership, etc.

I don't see the difference, we already build data structures in a highly flexible way (see reactions) and we are going to do the same for follows. So this can be extended over time.

[davidfurlong]

I agree follows shouldn't be rigid, but I never expected it to be.
I think CSVs are strange because most of this data is already available - whats the value in posting it again?

I think layering addition types and data on top of follows makes sense over time, that may support something like categories, or type.

[psatyajeet]

I would prefer to see follows enshrined in the protocol before amps.

Follows are inherently different from casts and there needs to be a data structure for hubs to represent them.

If I understand Amps correctly, they could be implemented within casts. Casts last 1 year. Amps last 3 months. If an app casts "@pal amps @v", then that app (and other apps) could search for messages with amp metadata and change the behavior of the feed based on those amps. This would allow apps to experiment with amps right now, without requiring a protocol change.

The same is not true of follows. I don't want my follows to expire after 1 year

[seeARMS]

Myself and Paragraph vote for follows. Private social graphs would reduce the usefulness of features like this greatly. We could rely on heuristics (likes, etc), but not ideal & not consistent x-product. I've always thought fully portable social graphs were one of the biggest value props of decentralized social and I don't think amps are an equivalent model.

[betashop]

Hi @varunsrin circling back on the Follows topic for tomorrow.

At Jam we planned for there not being follows. So we designed our "For You" features in a way that it could launch already and continue improving, and then get even better when Amps are introduced.

Wrt to adding Follows to the protocol. I'm not against it. If it helps developers onboard faster and build better FC apps and helps us grow the ecosystem and community, i'm all for it!

Just a few last notes/ caveats from my side before the meeting:

1. I'd hate for Jam to be chastized if we choose to read Follows but not write Follows IF we don't have explicit Follows in our product. That's only in the scenario where we decide to continue on our For You path and not have explicit Follows in Jam. In a permissionless world I don't think we can force apps to do anything, as you have pointed out.

2. That said, if there are Follows in the protocol, I'm not ruling out that we might change our mind and also enable users to Follow from Jam in addition to controling other variables in their For You, and in such case we would absolutely read/write Follows.

3. While there's excitement about Follows now, I just want to make sure we all leave the door open to there being other social primitives in the protocol in the future. I can see a world where both Follows and Amps and other factors exist in the protocol and apps can pick and chooose which they prefer to use.

For some apps it also may make more sense for it to be "Connect" not follow, more like LinkedIn/Facebook than Twiter/IG. We should be open to that. Maybe it involves a token so connection has some cost, tbd.

4. I'm not smart enough to understand the 1000 follows constraints and why they are truly constraints. Maybe 1000 was just an arbitrary example? It's way too low to be practical IMO. Perhaps a model where there is a max of 10,000 and we study it and if a lot of users want/need to go beyond the 10,000 mark by paying some support to the protocol.

[varunsrin]

I'd hate for Jam to be chastized if we choose to read Follows but not write Follows

I'm sure other apps would appreciate it if you contributed any follow-like relationships back to the shared data set so that everyone would benefit. But from the Farcaster POV, there's no rule enforcing this at the protocol level and you're free to do what you like.

I'm not smart enough to understand the 1000 follows constraints and why they are truly constraints. Maybe 1000 was just an arbitrary example?

The 1,000 number was a rough proposal, the draft version of this FIP will have a more concrete suggestion.

Storage is limited on the hubs and each user has a budget for X messages (slight oversimplification, but roughly correct). Whatever we increase follows by will have to come out of somewhere else (casts, reactions etc.) So being conservative here lets us assign a longer history to casts, reactions and verifications.

It is also far easier to increase this number in the future than it is to decrease it, so I'd rather make the mistake of choosing a number that is slightly too low instead of one that is slightly too high.

[seanbhart]

I think we might be going down the wrong path with this entire discussion, unfortunately. It seems like implementing something so specific like "follows" or "amps" at the protocol level is not best for Farcaster long-term.

I really like @michaelhly 's overview of how Farcaster could become a flexible, interoperable protocol with the goal to "facilitate an ecosystem of diverse applications".

@varunsrin gave a brilliant overview of a similar vision in response. This is what Farcaster needs to become. It will enable so much more potential and allow the core team to focus on more fundamental problems than "follows vs. amps".

The apps can create their own "modules" with specific event / interaction metadata and let other apps decide what they want to use. It's similar to deployed contracts on Ethereum allowing other contracts to read or write according to its internal rules, and if a protocol doesn't like those rules, they can go deploy their own version of the contract. Perhaps hubs can even choose which "modules" to store and propagate.

Farcaster has the potential to be so much more than a single type of application, and as Saypien recently pointed out:

We are now entering the age of User Generated Experiences (UGX), where the combination of users, AI models, and composable data layers like crypto become the new apex user experience paradigm. . .

However, despite the added dimensions of customizability inherent in Web3 social, front-end applications like Lenster and others have taken a more skeuomorphic approach to building where the objective appears to be feature parity with incumbent platforms like Twitter. This intuitively feels like a strategic gaffe. Even with creative token loyalty systems or greater financialization of content, Web3 social front-end applications don’t have strong moats to retain users since users can jump from app to app due to the open data structures.

In new tech paradigms, the winning strategies are novel and accentuate a key characteristic unavailable to incumbents. In Web3 social, that is the near infinite customizability of the experience layer and user data portability. Therefore, instead of making a deterministic front-end application that needs to retain users, it's likely a better strategic decision to build a platform that allows users to build their own experience layers. This enables the platform to keep proprietary its app generation process (i.e. a moat) while giving users a novel value prop that's difficult to be adopted by incumbents

[varunsrin]

I think there's some pareto optimal point between the extremes of a rigid system (where we are today) and a totally open ended system.

The extremes are undesirable - too much ridigity prevents new ideas from emerging and too much flexibility means apps don't standardize on anything and there is no economy of scale for building on the same network as everyone else.

[seanbhart]

for sure, FC shouldn't be another Ethereum - it should definitely be focused on social, but it should enable building "diverse networks like Facebook, LinkedIn, YouTube, or Whatsapp". You will have the biggest impact on the world if you don't need to worry about specific social interactions and instead enable a flourishing ecosystem of various interactions.

What if things like reaction types (as an example) were specified by others, and hub messaging merely allowed the addition of "reaction modules" (as an example)?

[varunsrin]

Some data on follows on Warpcast today, for discussion tomorrow:

• 50th percentile: 52
• 95th percentile: 254
• 99th percentile: 1462

Another way to look at is % of users with > x follows:

• 1000: 1.34% of users
• 2000: 0.80% of users
• 3000: 0.59% of users
• 4000: 0.48% of users
• 5000: 0.41% of users

[psatyajeet]

Might be helpful to filter this data by users who have >0 casts or active in the last month. Apparently 30% of casters have never casted and about 25% of casters are active in the last month. I'd be more interested in the same breakdown above but only on users active in the past month.

[varunsrin]

Analysis of users who were DAU's in the last 90 days:

95th percentile: 307
99th percentile: 1898

When looking at % of users with > x follows:

1000: 1.63% of users
2000: 0.96% of users
3000: 0.71% of users
4000: 0.61% of users
5000: 0.53% of users

I think around 2000 is a reasonable size for our follows set, only about 100 users will be affected, and:

• some are bots or accounts who "auto follow everyone" (if this is really a need, a global feed solves this)
• most are following at least N inactive accounts that can be easily pruned without any impact to experience

[psatyajeet]

Super helpful to see that the numbers don't change that much. I agree with your take that 2000 is a reasonable cutoff

[betashop]

Just curious:

Why are we basing this analysis off of the current userbase of 13k users / 1600 WAU?

Do we think the same # of follows holds same when there are 25k users and 3000 WAU? How about at 100k users, 250k users, 1M users, 10M users?

[betashop]

Hi @varunsrin @danromero

I wanted to follow up with one thing that literally kept me up thinking last night.

Part of the "promise" of web3 is more user control over their data.

In web 2.0 when Facebook, Twitter, etc. first started making their social graphs available via APIs, it was initially possible to get all of a user's social graph without them ever joining your app. This helped early apps grow rapidly because they could kickstart networks easier, but then FB, TW, and the like reigned that in to be more user friendly, and made it such that you can only get the follows of someone when they join your app (give your app permission), and not before. You could construct the social graph one person at a time, but not just read the entire graph publicly.

With blockchain, if we put all of the social graph on-chain, it's all public.

I am wondering if we should at least stop and think about ways for:

1. Users to control which apps have access to their social graph
2. Users to be able to revoke app's access to their social graph
3. Users to be able to have their social graph private until authorizing an app

Not stating a firm position on my side yet., but wanted to make sure we're at least considering these matters.

I think it's at least worth a stop and think on the topics above.

[psatyajeet]

It's good that we're discussing this topic.

I think "more user control over their data" is a bit of a meme when it comes to the promise of web3, especially in the current state of the technology. It's a concept that gets thrown around as a way to sell Web3 without any real meaning.

Farcaster already doesn't allow users to control their most valuable asset, casts, which are public. Similarly, it may not be the right time to focus on giving users control over follows, as it might not be a priority for them.

A relevant case was Cambridge Analytica, where Facebook had exclusive access to profiles, messages, profile metadata, and used that monopoly to sell that data to advertisers without user consent. Was the fact that data became available the concern for users or was it that it was sold to the highest bidder to surface ads that users couldn't opt out of? With Farcaster, users could move to a new app if they felt an app was misusing their data to show ads.

Of course, as I write this, I do think we should be cautious about sharing sensitive user metadata publicly, such if location data was stored at the protocol level.

I'm no expert on the technology required, but eventually, it could make sense to have optional encryption for follow data (or even casts) on an individual user level.

[michaelhly]

Understand that we need to get the follow/endorse parts implemented so existing full-featured clients can migrate off of the Warpcast APIs, will there be a part 2 discussion on what the subscription upgrade might entail?

[michaelhly]

is this where the discussion is taking place?
#92

[varunsrin]

wdym by subscription upgrade?

[michaelhly]

can be upgraded to express relationships between users and non-user objects.

[varunsrin]

no discussion around that yet, would be curious to hear the usecase youre thinking of for it