This is my attempt to share my thoughts after attending FarCon '24 last week. I'll briefly cover the conference, the protocol (Farcaster), the ecosystem, and the decentralized web in general.

Note: bare with me since I don't plan on doing much editing or rewriting. I will split it into different topics so feel free to skip around.

Let me know on Farcaster (@gabrielayuso.eth) if you'd like me to expand more on a particular topic on future posts.

Topics

• Farcaster and Me

• FarCon

• Farcaster user/bot growth

• Farcaster the protocol, Warpcast and the ecosystem

• Why this all matters

I joined Farcaster when there were less than 1K registered users, I've been active ever since.

I joined because I was looking for the signal amongst all the noise during the last crypto bull market. I was looking for glimpses of the future of the decentralized web enabled by blockchains, beyond the casino.

The two projects I found that point towards the future of the web as I hope it'll be are Nouns and Farcaster.

The Merkle team is building the protocol and the first client, Warpcast, in a very pragmatic and disciplined way. The idea of it being a sufficiently decentralized protocol that leverages blockchains for identity and registries, with its own p2p network tailor-made to the protocol's content and usage patterns resonate with my engineering sensibilities.

The care that was put into making a good quality product with a good quality network from the start resonate with my product sensibilities. It attracted and retained users with similar sensibilities early on, that's why the community's bond is strong.

Last week I attended FarCon '24, a community organized conference, in Venice Beach.

This wasn't my first FarCon. In 2023 I flew to Boston for the first FarCon which was an order of magnitude smaller than this year's conference. Farcaster itself now has an order of magnitude (or two) more active accounts than it did then.

A year ago, the protocol wasn't in mainnet (production), signups weren't permissionless, the idea of channels had just been introduced, frames weren't a thing and there was no memecoin tipping. FarCon attendees were mostly just users since few were building on top of the protocol then. There was no hackathon, no big funding announcements and no VCs.

Props to everyone involved in making the conference happen since it was a huge success, despite it expanding drastically only a few months before it took place.

I preferred the size of FarCon '23. It was more intimate, conducive to deeper group conversations and participation in the talks. This year I missed most of the talks and had just a few deep conversations since there was so much going on and so many people to say hi to.

I was overwhelmed, but everyone's mileage in these social situations is different.

I'm not sure if I'll attend FarCon '25. I'm more likely to attend smaller meetups instead.

The protocol has grown considerably this year, with both humans and bots.

There have been several discussions on Farcaster and Twitter about the DAU number, its relationship to memecoin tipping, bots that aim to extract value from tipping, etc.

On the web, there will always be bots, there will always be spam, there will always be scams, etc. Companies like Meta and Alphabet have large teams and infrastructure dedicated to keep bots and their content away from users as much as possible, yet they don't always succeed. Google Search's web results are less useful in large part because the open web has turned into garbage full of low quality, clickbait-y, filler content. Twitter is full of garbage replies from bots. Even ads are scammy, I helped take down many phishing crypto ads on Google Search. It'll always be a cat and mouse game, companies trying to filter out bot's content while bots get better at mimicking human behavior, now with the aid of LLMs.

Bots and spam can drastically reduce the quality of a social network so it's critical for clients to address this. One benefit that comes with the need to filter content is that it forces the discussion on decentralization and the need for diverse clients and data providers to give users more choice and control of their feeds.

Dan and Varun (Merkle's cofounders) stated in the opening talk at FarCon that they plan to grow Farcaster with crypto. There are both good things and bad things about this.

The good thing is that by embracing crypto trends, such as memecoins, it's more likely that folks on crypto Twitter will move to Farcaster, growing the protocol's network and that people coming to crypto will join Farcaster directly without even passing through crypto Twitter first.

The bad thing is that by embracing crypto trends and focusing on crypto natives, the carefully curated community which was more focused on crypto the computer could shift more towards crypto the casino. It can also deviate from building a product that explores UX for general consumer beyond crypto natives.

I'm not too worried about this since crypto the casino and the amount of crypto natives is small, and crypto will remain small unless it can move beyond the casino and can appeal to the general consumer space.

The way to do it is by building compelling product experiences that show the benefits of participating in the new decentralized web powered by blockchains without making crypto and the ease with which it enables speculation the main thing.

If you want to know the technical underpinnings of Farcaster the protocol read Varun's Sufficiently Decentralization for Social Networks and The Goldilocks consensus problem essays.

The way I see it, Farcaster provides:

1. User Owned Social Identity and Auth

2. Open Social/Engagement Graph

3. Permissionless Content Feeds

4. Frames (extension of #1)

Every Farcaster user has a globally unique FID which can be associated with a username (fname, ENS), a social profile (pfp, bio), multiple authorized signers and verified wallets. Signers are what give Farcaster profiles the power to become a trusted auth system across apps and frames. It's like a crypto version of Google SSO.

The Farcaster account system can be used as an identity and auth layer without using the social graph and content feeds. For example, if someone signs in with Farcaster, then you immediately know that that user owns all the tokens associated with all the verified wallets associated with the account without having to ask them to sign a message with a wallet.

Since Farcaster is a social networking protocol, it has a social graph baked into it (users can follow/unfollow other users). More importantly, the protocol also keeps track of an account's content engagement via likes, replies and recasts. These engagements form a different type of graph between accounts.

It's well known that one of the biggest challenges for any new product is overcoming the cold start problem. By integrating with Farcaster, products can build on top of a pre-existing network of users.

I don't remember the specifics but Instagram built their social network by essentially letting users import their graphs from Twitter and Facebook before they closed down those APIs. This way, you could start following people from Twitter and Facebook on Instagram as soon as they created an account.

Apps can use Farcaster's graph to either find others from Farcaster that are using the app and bootstrap their own follow graph, or by fully integrating with Farcaster's follow graph without the need of a separate one. Also, apps can use Farcaster's engagement graph to recommend accounts that you've engaged with on Farcaster.

Farcaster was born as a sufficiently decentralized social network protocol in the likes of Twitter but if you think about the underlying data layer and not about the main product that has been built on top of it, Farcaster is a content feeds protocol.

Since the system that stores the content is a p2p network with global state, there are tight constraints on the data that can be pushed to the network. A small amount of text and embeds (links to other content) is all that the protocol lets you store. Each entry (cast) is associated with the author's FID.

Like Twitter, the protocol supports replying to a cast, which means that casts can be parented to other casts. This parent-child relationship is what makes replies and threads possible. The feeds are actually trees not just lists.

One simple tweak let the protocol go beyond its Twitter roots to enable what Warpcast calls channels. Casts can be parented to any URL, not just other casts. All casts parented to the same URL can form a new feed. For example, all casts in the Nouns channel are parented to a URL that corresponds to the Nouns token contract.

By leveraging the ability to parent to any URL, Farcaster can be used to build many different content feeds.

By leveraging the ability to embed URLs in casts, Farcaster can be used to build feeds with many different types of content.

The feature that brought the most attention to Farcaster earlier this year was the introduction of Frames. Frames are interactive embedded URL previews.

Social networks use HTML meta tags pulled from websites to present links in a nicer way (such as with an image, title and description) than just the plain URL. Merkle expanded on this to let websites tell clients to render interactive components such as buttons and which HTTP endpoints to call when each button is pressed. This allows developers to build "mini apps" that can be embedded into casts in a feed.

The most powerful aspect of frames is that the client sends Farcaster auth data to the frame server when a user interacts with it. This means that the server has proof that a specific user interacted with a frame and also has proof that the user owns the wallets associated with the user's Farcaster account. Since both Farcaster and wallet data is open, the frame server has a lot to play with.

Apps have opportunities to integrate Farcaster in different ways, as described above. This enables a rich ecosystem of apps and tools that leverage (1) the Farcaster auth system, (2) the social/engagement graph or (3) the content in one way or another. For example, events.xyz uses the Farcaster auth system to let users RSVP to events including directly on a feed via a Frame.

Apps that integrate the protocol fully are considered clients. The main client developed by Merkle, in tandem with the protocol, is Warpcast, which is a Twitter-like client. There are other clients such as Supercast and Nook. Clients don't necessarily need to have a Twitter-like feel but they usually do.

There have recently been discussions about Warpcast's dominance. Dan answered my question during FarCon about growing the ecosystem by stating that there isn't much economic incentive to build other clients at the current size of the user base (~40K DAUs) and that there will be more room for other clients once the protocol hits ~10M DAUs.

Despite that, there are now at least two other VC funded clients, Nook and Kiosk. I'm particularly curious (and surprised) about Kiosk since it seems to be very well funded yet there is little info about it other than an announcement teaser video that makes it look memecoin channel centric with cast minting and native tipping.

At this size, it's fine to have Warpcast as the main Twitter-like client with a few smaller boutique ones.

What interests me is leveraging the protocol to provide other types of experiences beyond the Twitter/Reddit-like clients. Experiences that could expand the protocol and the ecosystem beyond what Warpcast is doing.

Imagine if the web had stayed as Tim Berners-Lee envisioned it without Marc Andreessen and other's pushing it beyond the academic use cases.

Building tools and clients that just address "opportunities for a another client" won't move the needle and will eventually shutdown due to low usage or be sherlocked.

We should explore beyond Twitter/Reddit-like clients. We should also build with the protocol and extend to it as opposed to just using it as a bootstrapping and GTM conduit.

Remember Farcaster is: Auth, Graphs, Feeds, Frames

The second priority Dan and Varun mentioned at FarCon was focusing on enabling cozy corners to form in the protocol. Cozy corners are subnetworks within the larger Farcaster network, such as channels and communities.

Dan also mentioned that he believes there are more opportunities for channel centric clients to succeed. Such as turning a channel into a fully formed app.

I tend to agree completely with Dan and Varun. Going deeper into communities can unlock more use cases yet unexplored. I'm biased since I'm building in exactly this space, starting with Nouns (prototype: 498.wtf) but aiming to scale beyond.

Finally, Dan and Varun mentioned that another goal is to build more legos. Initially by incorporating direct casts (DCs) and channel registries into the protocol.

A big reason why building beyond the Twitter/Reddit-like client paradigm is important is to increase the amount of legos we can come up with.

I'm particularly excited about legos that let us move beyond the client paradigm. Legos that allow for much more composability at the application layer, that take us forward in the new world of computing and data.

Ok cool, but why would one care about all this? Why would one care enough to dedicate time and money to help grow Farcaster's user base and ecosystem?

Because the open web is dead.

Websites are full of garbage content and obtrusive, useless ads. Social media walled gardens have complete control over creator content and monetize it for themselves. Data is trapped behind their control so what they say goes. We live in a monarchy of data, the lords control it and do with it as they please not letting free cities and free economies to flourish, stifling innovation.

Decentralized protocols like Farcaster are large part of the solution. Inversion of control and power, from the self appointed monarches to the citizens.

Long live the open web.