Points for Channels -- beyond airdrops

Dan posted this recently:


Link to tweet

And two lines jumped out at me.

  • “the only way to measure relevance and influence of a given Farcaster account is who is following and engaging with an account, not the raw numbers”

Which I’ll frame as “Who is this person to this network?” and

  • “just because an FID has a lot of followers and raw engagement numbers on the protocol, doesn’t mean the average user on clients is seeing it.”

Which I’ll frame as “Who is this person to this app?”

Both: “Who is this person to this network?” and “Who is this person to this app?” are both feed ranking problems, and show that the value of any particular post varies based on its context.

With web2 social clients, the feed is curated for you, enforcing whatever it knows you want to see. However, navigating these issues represents novel challenges, or “good new problems”, that get created by permissionless clients and web3 in general.

Here’s a more specific example of one post in multiple contexts in web2.

When your tweet goes viral, escaping out of your local sphere. It’s being interpreted differently by a different community. It can be taken extremely out of context “the equivalent of a sound bite” outside of your bubble, u might get owned.

Points for Channels (might) help make this “multiple context” problem more transparent. They aren’t unique, but give users more control should have better tools (onchain filters) and a wider choice in clients. Hopefully all this results in easier bootstrapping of more interesting permissionless feeds and communities. So what’s this look like?

  1. Let channels directly toggle using some filters for ranking. Some examples could just be common Snapshot Strategies such as has $MOCHI .
  2. At X time, or finalization:
  • posts and users are awarded points onchain. i.e MOCHI Feed Points
  • Now, apps and communities can use $MOCHI Feed Points to continuously rerank posts and users in their feed.
  1. As a community and or ecosystem of apps, you can compose new feeds by creating a new index, that could be scored based on $MOCHI Feed Points and $TYBG Feed Points.

Hopefully this complements traditional feed scoring algos (ML stuff), that apps mostly use today. And leaves room for communities to self moderate in ways that are more scalable less annoying to manage than normal mod / hard block / soft block tooling.

Zooming Out

This kind of composability is an extension of what’s already happening in a few different places:

  • Airdrops: → I give u token, based on what you did previously. Goes without saying, but the most “popular” airdrops are those that “remix” what you got from another chain / project / web2 network. – As an aside, I think the first version of this I saw was the Handshake airdrop, but dropping tokens to Github devs has been one way in which one action, has been reintepreted permissionlessly by people.
  • Tips: → I give u tipping power, based on what you engaged with in past week
  • Contests: → I give u token, based on what great posts you had in past week
  • Governance Voting: → I give u token, based on what great posts you had in past week

Right now, airdrops are the only thing that really enable you to remix onchain things between communities. Whereas Tips, Contests, Governance Voting happen “internally” to one community.

By enabling this remixing of feeds, we could enable new communities to form, without needing to drop a new token right at the beginning, without forcing something. So basically you could curate a CryptoXAI channel that curates posts from $AI Feed Points , $CRYPTO Feed Points , and $NVDA Feed Points holders.

Overall this is inspired by some stuff like the OG https://en.wikipedia.org/wiki/Favstar and more recently https://hive.one/ (RIP cause Twitter Algo).

Either way, all of this is a reminder that onchain is permissionless. And how any one transaction or post can get reinterpreted in many different ways. We’re working on tuning our feed algos at @commondotxyz, and communities alike. So hit us up if you want to jam on this.

This article was first created and posted in Common. You can check out and comment on the original post here.