During the latest Farcaster Devs call, Dan presented a first draft of how they think channels will be decentralized. https://warpcast.notion.site/Public-draft-Decentralized-Channels-d40d98468b7b4b3ba330b35ca2e341b6
Update, 2024-05-14: There is a new version of the proposal https://warpcast.com/dwr.eth/0x6557744a
I will try to present here the high level concepts of this new proposal. I will not get into the technical details because they are still vague.
A new mental model for Channels
If you are a developer, or if you have been engaged in Farcaster protocol discussions in the past, you probably have to switch your mental model when it comes to Channels for the proposal to make sense.
So, let's take a step back.
Imagine you are a newspaper editor. You handle the editor@newspaper.something email. Anyone can send an email to this address: Writers send their articles, prominent figures may send letters to the editor, regular users may send their thoughts and complaints, scammers and spammers will definitely send their stuff.
So, everyone can post to editor@newspaper.something, but it's actually up to you, the editor, to decide what shows up in the paper and what not.
This is how you should think of the "new" Channels: Everyone can post, but the Channel editor (or host, curator, owner, whatever we end up calling them) decides what shows up in their channel. Technically, every cast posted to a channel is there, but the editor decides what you see when you visit the channel.
The new Channels will be a standard that lets Farcaster clients (like Warpcast, Supercast, Nook, erc.) know what to show in a channel and not who is allowed to "post in a channel". Or, if you want to think about it in DRBMS terms, everyone can use INSERT, but we now have a well defined SELECT that clients should use, and the Channel editor defines the WHERE clauses.
Now, I keep saying this is a new mental model, but it's not. This is what Warpcast has been doing all this time. Channel passes and cast moderation (hiding casts, etc.) are rules enforced by Warpcast at the client level. Even if your Channel Pass has been revoked a) you can use an other client to post to a Channel and b) even if you do so, Warpcast will not show your cast. What's new, is that we get a standard way of implementing this at the protocol level.
A new curation mechanism
The other important component of this proposal is a programatic way of describing a wide range of curation models:
I want an NFT gated channel,
I want only FIDs that I follow,
I want FIDs with more then $1,000,000 worth of assets in their connected wallet,
I want FIDs that have used a specific DeFi protocol more than X times in the last Y days,
I want FIDs who have set their location to Athens, Greece for more than two months,
I want FIDs who have paid their monthly subscription...
How do you describe all these, and probably many more, complex rules?
The proposal describes a simple but powerful curation mechanism: The channel curator will have to "approve" each cast, one by one. Which may seem counterproductive, but it allows for maximum flexibility. You can have a Channel that's a personally curated list of hand-picked casts. Or you can use a service like https://automod.sh that lets you create complex rules and have it automatically enforce them (curate each cast according to the rules you set).
By defining different rules, Channels become a primitive that can express very different use cases. From the "NFT community" channel, to "Reviews from users who bought this product" channel, to the "five experts in agriculture discuss and share insights" channel, to "my important stuff" channel.
Final thoughts
I love this model for a couple more reasons:
First, it's compatible with the global state model, that allows me to run my own Farcaster hub at home and build apps that interact with Farcaster and are hosted locally. In this case, it is easy to run your own channel curation/moderation bot on your own infrastructure. It can't get more decentralized than this.
Second, it could create a new marketplace for channel-related services. Automod is a great example, but I hope we will see other services, competing in features, pricing or even business models. And there's also room for custom solutions that integrate exotic data sources and rules.
The proposal also includes the option of "open" channels where curation is turned off. I did not mention open channels so far, because there are very much like we have today: anyone can post anything they like and it's up to the clients to apply filters that hide spam or low-quality casts, if they want to.
We still have to see the technical details of the proposal. But I like the proposed solution. It's simple but very extensible and unlocks new use cases. And it definitely makes channels permissionles and decentralized.
Well done, Dan and team!
Updates and content posted after this article
