FIP: Opportunity For Another Curator

[CassOnMars]

Problem

Tastemaking is the dirty secret of growing a social media platform. It isn't easy, it isn't cheap, and it isn't decentralized (yet). The costs of quality feed generation is expensive, resulting in client teams building their own, and having to deal with the inherent costs of doing so. This can be achieved instead as an independent feature of the protocol, allowing curation to live as a protocol primitive rather than an ad-hoc externality of building a farcaster client, enabling the client diversity to grow and amplify each other instead of competing.

High Level Solution

Add a new message type, Curation, which enables tastemakers of any kind (algorithmic, manual, simple like "reply bumping"), which users on the protocol can create, that provides a choice for clients to surface to users:

/** Adds a new Curation */
message CurationAddBody {
  string name = 1;
  string description = 2;
  repeated strings strategies = 3; // e.g. "machine-learning", "manual", "algorithmic", "personalized"
  string feed_url = 4;
  string source_url = 5;
}

/** Removes an existing Curation */
message CurationRemoveBody {
  bytes target_hash = 1; // Hash of the cast to remove
}

The idea is that feeds are standardized in a url (e.g. a compliant feed must have a common url shape), and should be open source and scrutinizable (but not mandatory). A basic requirement to add on is that a curator must also be an active snapchain node runner, otherwise it suggests feed generation will be outdated or at least late.

Notes

This is an incomplete draft proposal, a full LOE will be added soon.

[vrypan]

Cassie, what do you think of this approach?
farcasterxyz/miniapps#490

The downside is that it's client-specific but on the plus side, it's really easy for clients to implement.

[CassOnMars]

This is genuinely intriguing – miniapps aren't on protocol, so it makes discovery hard, but I see where you're going with this now and I like what you're suggesting. How would you solve for the discovery issue?

[vrypan]

Discovery of what, by whom? :-) It's not clear to me.

If you refer to content discovery, this is up to each miniapp, and depends on what they want to do. An algorithmic one, may filter what your social circle interacted with. A filtering one, may just filter the snapchain feed for keywords. A "why did X unfollow" one could find the last cast posted before X unfollowed. A "first cast" miniapp may look for the first cast new users post after they sign up.

We already have so many miniapps, that identify different signals: Trending tokens by clout, top posts, bangers, etc. Buoy, WDIM, Cura, Banger, all the tipping apps, could have their own feeds, and users would get a modular feed, they can tailor to their taste. No social app has something like this today.

If you mean how users will discover the right miniapp, well, it's not a solved problem, but I think word of mouth is a good starting point.

[CassOnMars]

Right, but how do people discover the miniapps that produce the feed sources in this miniapps-drive-feeds model?

[vrypan]

I don't have an answer. I think this is a meta-problem. I think we all discover miniapps from other users that share them, and it works ok. Not perfect, but has worked so far.

[wenakita]

It has not worked for me, at all whatsoever. As a builder coming in with some reputation (won Social track of On-Chain Summer Buildathon 2024) i have had 0 exposure, 0 likes, in fact 0 views on my farcaster miniapp.

[allemanfredi]

It’s not easy to verify that a curator is also a node operator who correctly generated the feed. Enforcing this requirement would imply that feed generation must be accompanied by some form of proof (or TEE attestation) demonstrating that the feed was generated using the correct code (for example, code available on GitHub) and that it was produced by the correct entity. This would introduce additional complexity and significantly raise the entry barrier, especially given that running a node is not cheap and that becoming a Snapchain node operator is itself non-trivial.

For these reasons, I would remove the requirement that a curator must also be an active Snapchain node runner and instead rely on reputation. Inefficient feeds will naturally fall out of use, while efficient ones will be adopted.

[CassOnMars]

Seems reasonable, and I wasn't suggesting verification that the feed was verifiable, just that it should ideally be transparently auditable. As of now, neither of the two largest apps do this anyway.

[vrypan]

What should I expect to find at the other end of feed_url and source_url?