We already agree that Farcaster is not be the best place to find the latest news (it's getting better, but we are in no way Twitter), but it's a great place to hold conversations.

Is it the culture? The friction imposed by the signup cost? The way clients work? The size of the network? I'm not sure, but it's a fact.

In any case, why not make it, Farcaster's unique selling point?

First of all, high quality conversations don't require a large network.

If you are interested in distrubution, you want to find the largest venue, ideally packed with people —when it comes to distribution and reach, size matters.

But if you want to have a good conversation, you pick a few, often a handful, of people —when it comes to engagement, quality matters more than size.

Second, the cost of using Farcaster (storage unit and signers costs) is better aligned with quality, than size —it's ok to add friction if you are more interested in audience quality than audience size.

Third, engagement and conversation drive daily, reoccurring usage. Every reply is a new invitation to respond or react, and the more time users spend on Farcaster, the higher the probability of sharing high-quality, original content.

If this is a strategy worth pursuing, we should review all features and touch points: Do they promote or facilitate conversations? Is there something we could add or change?

For example, can we improve how threads are presented in clients? Or maybe, is there an opportunity for a client that gives a better overview of long, nested threads and better tools to manage them?

How can we add more context to discussion threads? Would it add value if it was easy to see if the person who replied in a discussion about sports is a fan of team A or team B? Or in a political discussion if they are on the left or the right? Or in a crypto discussion if they are a BTC maxi, and ETH maxi, or chain agnostic? If yes, maybe we should introduce badges? Maybe badges that are channel-specific?

Or maybe we want better moderation tools per discussion. Would it make it a better place to hold discussions if I could moderate or token-gate or add some other type of control on who can respond? When they can respond, or how many times they can respond? Something else?

Should we look at FIP-2 again, through a different lens?

I'm sure that if we make conversation quality a top priority (even higher than better content), there will be many, and most probably, better ideas.

Is focusing on engagement a better strategy than focusing on growth? I can't be sure, but it looks appealing to me.

While there may be a tension between network size and engagement quality, there is no tension between content quality and conversation quality. They are probably complementary.

Could it be a viable, long-term strategy? Again, I'm not sure. It definitely has its advantages at the stage we are right now, but maybe it will be less effective if the size of Farcaster grows 10x.

In any case, I think it's worth exploring the idea, even if it's only as a thought experiment.

These use cases, may have special requirements such as very fast, real-time interactions and app-specific context (for example, the minute of the game), things that Farcaster is not very good at. And on the other hand, things that Farcaster is good at, such as censorship resistance, may not be very important.

In these cases, you could build what could be called a "Farcaster rollup".

You can think of a Farcaster rollup as a discussion that happened someplace other than hubs. It takes advantage of the Farcaster identity system (so, your users have to use their FID), and could use a signed proof of some kind (from an app-specific signer, to a message signed by an other signer such as Warpcast, similar to how frame payloads are signed) to prove that the user is participating in the rollup. It has a start and an end in time, and once it's completed, the app posts a "proof" it happened as a cast.

Depending on the application requirements there are various levers one can adjust, but let's take a simple (and probably popular) example, an app that lets casters comment in real time during a basketball game.

Your app would announce the game using a cast, and a frame that lets users sign-in. Your app stores the signed payload sent by the frame as a way to prove that a user actually joined the chat. Then it redirects you to a centralized chat server where you sign-in with Farcaster and you can comment in real time. At the end of the game, your app saves the whole discussion as a json on IPFS, alongside the proofs for each participant. Then it posts the whole discussion as "extrenal data" (the FIP is draft, but will probaby be finalized soon). It may also mention users that participated, in replies to this cast.

So, you leveraged FIDs, no need for signups, avatars, etc. You also have a proof that users actually joined the chat. Your users did not consume any Farcaster storage space, experienced a real-time chat that is hard to impossible to implement in a decentralized way. In the final transcript, each comment is tagged with the minute:second of the game. It can also show additional context, like the team each user supported, or score changes. And when the game was over, everything was rolled up, and posted to Farcaster.

Your app could also post intermediate "checkpoints" to Farcaster, something like "@A, @B, @C and 20 other users are currently commenting on the game", every 10 minutes, to drive participation.

If this was about a more sensitive topic, let's say, a political debate, the app could work like a traditional Farcaster client (request the user to approve a new signer, and sign each message), or even implement a stronger model, using client-side signatures.

When we discuss how Farcaster can scale to millions, it is often assumed that sharding may be unavoidable. But maybe something that resembles rollups may be a better solution that will preserve the global state model without unreasonable hardware requirements.

In a dramatic turn of events, the White House is facing a wave of political turmoil following the resurfacing of controversial casts from one of President Taylor's closest advisors, David Sullivan. The casts, dating back to 2024, were not previously accessible but have recently been brought back to light by an anonymous online user. The content of one specific cast has sparked outrage across the political spectrum, putting the administration on the defensive.

David Sullivan, a seasoned political strategist and long-time confidant of President Taylor, has played a crucial role in shaping the administration's policies and public messaging. His influence extends deep within the corridors of power, making the revelations even more shocking to both the public and political insiders.

The cast in question, dating back to September 2024, indicates that Sullivan had talks with Russian officials during President Taylor’s campaign.

spoke with Russian officials, especially during the campaign. Don’t be stupid. #diplomacy

This revelation is particularly jarring given President Taylor's publicly strong stance against Russia. Throughout his administration, Taylor has consistently condemned Russian interference in global affairs and has imposed several rounds of sanctions on the Russian government.

Farcaster will purge old casts after a year if the user does not pay for storage, and all Sullivan’s casts were purged in November 2024. However, last week an anonymous user paid for Sullivan’s Farcaster account, and immediately after it, Sullivan’s old casts appeared again.

Dan Romero, co-founder of Farcaster, explained that “each cast is a signed message sent to the protocol. Hubs may prune these messages for various reasons, but if you have a copy of the original message, you can re-post it.”

The White House has been slow to respond. In a statement released yesterday, Press Secretary Lisa Graham addressed the controversy, stating that "Sullivan's casts were doctored and do not represent reality.” She added that Sullivan has the full support of the President and that the FBI is conducting a thorough investigation of the situation.

Sullivan himself took the battle back to social media. “I could never have written something like this, because it is not the truth. This is an attack on the President, not me.“ he casted. “I will not delete the cast in question until the FBI has concluded the investigation.”

The resurfaced cast has sparked fierce criticism from across the political spectrum. Senator Maria Gonzalez (D-CA) accused the President of hypocrisy, stating, "President Taylor's strong public stance against Russia is completely undermined by these revelations. This casts serious doubt on his integrity and the credibility of his administration."

Representative John Mitchell (R-TX) went even further, suggesting treasonous behavior. "If these allegations are true, it means the President and his closest advisors have been deceiving the American public while engaging in back-channel talks with a hostile nation. This is not just hypocrisy; it's a betrayal of our country."

Political analysts are closely monitoring how President Taylor manages the situation. The controversy arises at a crucial moment, with negotiations with China at their peak. Some insiders also believe that Taylor's handling of this scandal could significantly affect his political capital and the public's trust in his leadership.

"The President is in a precarious position," said Dr. Elaine Matthews, a political science professor at Georgetown University. "On one hand, he needs to maintain the support of his key advisors. On the other, he must address the valid concerns of the public and his political base. How he navigates this will be telling of his administration's values and resilience."

As the story continues to unfold, it is clear that the resurfaced casts have struck a nerve in the nation's capital. The coming days will likely see further developments as the White House grapples with the fallout and the public awaits President Taylor's next move.

By: Jonathan Harper, Washington Post

Washington, D.C. — June 24, 2026

In a stunning development, new evidence has emerged that could significantly alter the narrative surrounding the controversial cast from David Sullivan, a close advisor to President Taylor. Independent researchers have retrieved additional casts indicating that the original message, which suggested talks with Russian officials during President Taylor's campaign, was quickly deleted and replaced with a contradictory statement.

The new casts, uncovered by digital forensics experts from the non-profit organization Digital Integrity Watch, show that Sullivan initially posted:

"spoke with Russian officials, especially during the campaign. Don’t be stupid. #diplomacy"

However, within seconds, Sullivan deleted this cast and replaced it with:

"Never spoke with Russian officials, especially during the campaign. Don’t be stupid. #diplomacy"

Dr. Molina Green, a lead researcher at Digital Integrity Watch, explained the significance of the findings. "Our analysis shows that the initial cast was deleted almost immediately, indicating an attempt to correct a genuine mistake—a common occurrence among Farcaster users. The troubling aspect is that the person who reactivated Sullivan's account selectively restored messages, seemingly to misrepresent what Sullivan actually posted."

The White House has yet to respond to this latest development. However, Press Secretary Lisa Graham reiterated in a brief statement that "the administration stands by its previous assertion that the initial cast was doctored and does not reflect reality." She also noted that the FBI's investigation into the matter is nearing completion.

The new evidence has sparked renewed debate among political figures and analysts. "This entire incident reeks of a coordinated effort by our adversaries to undermine the President at a critical juncture in our negotiations with China," said Senator Thomas Blake (D-CA). "We must remain vigilant against attempts to weaken our leadership and national unity."

Representative John Mitchell (R-TX) echoed these sentiments, calling for immediate congressional hearings. "This latest twist in the story only underscores the need for a thorough and public investigation. The stakes are too high to ignore."

Political analysts are closely monitoring the situation, noting that the administration's handling of the scandal could have far-reaching implications. "The President needs to address these new developments head-on," said Dr. Elaine Matthews, a political science professor at Georgetown University. "How he navigates this will be critical in maintaining the public's trust and his political standing."

As the FBI continues its investigation and the White House prepares for potential congressional scrutiny, the nation watches with bated breath. The coming days are expected to bring further revelations as the full story behind the controversial casts continues to unfold.

By: Jonathan Harper, Washington Post

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.

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.

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.

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

Farcaster

Tony D’Addeo on Warpcast

the permissionless channel proposal unlocks channel owner's ability to monetize their channel with advertising via a moderation rule that allows advertisers to pay for inclusion ad marketplaces that you can opt into just like that and monetize that sweet attention across every Farcaster client this is crazy shift

The Farcaster network is a network of hubs that exchange messages between them. Each hub holds the entire "global state": every cast, reaction, follow, every user's profile data, everything.

The farcaster app you are using, only has to connect to one of the hubs to read and post messages. Then this hub syncs with the rest of the network and every other hub receives your activity.

Hubs exchange messages between them in two ways:

1. The first one, is practically real-time: The hub that receives a message uses a protocol called gossipsub and sends the message to the hubs it's connected to, then they do the same and in just a few seconds all hubs have received the message.

2. The second is an out-of-band sync. This one is slower and only happens every few minutes (or whenever it's feasible, more on this later). During the out-of-band sync, two hubs practically compare their databases, and exchange deltas in order to get to the same status (exchange deltas to reach the same state).

If you are interested, there is a video describing the concept in more detail.

Advantages

This model has a number of advantages:

• It's developer friendly, because a developer can have a full copy of the network, locally, to work with

• It's decentralized and censorship resistant because there's no single point of entry to the network

• It's very resilient because you can take away any number of hubs (a recent count of Farcaster hubs brings them to ~150) and if there is at least one left, spawn new ones and reconstruct the network as if nothing happened.

These characteristics make Farcaster ideal for a number of environments where other social networks (centralized or federated) would fail.

When the office ISP went down

Imagine you are at work, using Farcaster by connecting to the office Farcaster hub that runs locally, and you are using a Farcaster client that connects directly to the hub [*]. At some point, your ISP goes down.

Here is what happens during the period you have lost connection to the rest of the Internet:

1. You continue to have access to everything that was posted on Farcaster up to the moment the Internet connection went down.

2. You can also cast, like, recast, follow and unfollow as if nothing changed.

3. You can also see new casts and reactions from your colleagues that use the same hub, and you can reply and react to their casts.

The most important thing that changes during the period the ISP is down, is that you don't see any activity that happens outside your office (your office farcaster hub). But as soon as the ISP is up again, your hub will connect to the other hubs, it will propagate any activity that happened (in the office) during downtime, and receive all activity that happened outside your hub!

There are a few things that wouldn't work while the ISP is down:

1. Any Farcaster activity that requires an onchain transaction, such as creating new accounts, approving and removing signers, or purchasing storage units.

2. Of course, any content referenced or embedded in casts will not be available, such as images -but that's not Farcaster's problem and if someone really wanted to, they could fix it by using a caching proxy or something similar.

Social media on the Mars colony

One of the challenges a crew of a future the Mars colony will have to overcome is staying connected with Earth. Radio signals take 4-22 minutes to get from Earth to Mars, and it will take as much for a response to come back. There's not much we can do about this, unless we find a way for the radio signals to travel faster than light.

One more problem is that the available bandwidth is nothing compared to what we are used on terrestrial communications. I expect that all available bandwidth, will be used to support the operations of the station, and to exchange asynchronous messages between the station crew and Earth command center and their families.

One thing is for sure: The Mars crew will not be able to use X/Twitter, because it's built on HTTP, a synchronous protocol. However, our astronauts could use Farcaster!

An other cool thing is that Earth-March syncing could also be performed entirely off-line: Every mission to Mars could also carry a Earth-synced hub, that would sync with Mars when it gets there and every mission from Mars to Earth could carry the Mars state back to Earth.

Astronauts will have full access to everything discussed on Farcaster on Earth, interact between them, share their thoughts, and when their hub syncs with Earth, we will all be able to see their activity, react to it, etc., and vice versa.

We may have to create an FIP to introduce some small changes to support the Mars colony use case, but I'm optimistic that space settlers count as qDAUs and it will get the full support of the devs.

So, yes: Farcaster is a better match for SpaceX than X!

[*] A small note on Farcaster clients connecting directly to hubs. Today, most Farcaster clients depend on a backend hosted by the developer or a third party. These backends take a lot of the load that otherwise a client would have to do, like hosting a database that can be easily queried. These clients will not work without connection to this backend. However, it's 100% feasible to create a client that connects directly to a Farcaster hub, or even have a local installation of the backend required.

In order to understand signers, you have to keep in mind that all interactions with hubs take place by sending hubs a "message" that has a specific structure. So, when you cast, like, or recast, the app you are using sends a message to a hub saying "@vrypan.eth casted Hello World", or "@vrypan.eth liked this cast".

Messages look something like this under the hood:

As you can see such messages have two parts.

• The data part: this is more or less what we usually consider the content, like the text of the cast, the date it was casted, the user who casted.

• The metadata part which has a hash of the data, a digital signature of the hash, and the key that produced the signature: the signer.

What you see in the signer filed is not the actual signer, but the public key of the signer.

Why we need signers

In a centralized network such as twitter or facebook, you usually have a username and a password. You use your credentials to connect to a server, and then the server knows that you are who your credentials say you are. There is no other way to post something to the service, and the centralized server is the absolute authority of what was posted by whom.

Farcaster is an open, p2p network. Anyone with some technical knowledge can create a program that sends messages to the Farcaster network. The only way to verify the authenticity of these messages, is by their digital signature.

Each Farcaster user has their own keypair, a private and a public key. If you signed up using Warpcast, your recovery phrase can be used to generate this pair. This keypair also corresponds to an ethereum address, what is often called in Farcaster the custody wallet.

So, you could actually sign your messages using your private key. But users rarely create these messages on their computer using a program they wrote. They connect to a service or app, like buidler and after authenticating with it, it posts on their behalf. The problem is you don't want to give them your private key. This would be the equivalent of giving a gmail integration your username and password (and to some extent, not even being able to change the password).

Here is where Farcaster Signers come to play: Instead of giving an app your private key, the app creates a new random key, and asks you to approve it. You approve it using your private key and you register your approval onchain (gas cost!). From this point on, any hub that receives a message signed by this Signer, can check the blockchain to verify that you have approved the signer and accept it as authentic.

Warpcast and meta-transactions

When you make a call to a smart contract, the caller has to pay the gas for its execution. This is why adding or revoking a signer (onchain transactions) have a cost.

Normally, your Farcaster custody wallet would need to have some OP ETH to perform these transactions.

But wait. There's a workaround: KeyGateway, the smart contract used to approve Signers, allows meta-transactions. You can think of meta-transactions like this:

• The user who wants to perform a transaction signs the transaction or an authorization to perform the transaction using his wallet. This is an offline action.

• The signed transaction is not sent to the smart contract, but it is shared offchain with a third party, usually called the "relayer".

• The relayer performs the transaction and pays the required gas.

Warpcast takes advantage of this feature to hide the added complexity of using a blockchain: It will ask the user to pay them $1, and then they use a meta-transaction and they pay for the gas.

This is roughly the equivalent of them saying "Just sign this paper, give me $1, and I'll take care of the rest."

The actual gas cost for adding and removing signers is usually well bellow $1. Warpcast now allows users to also pay using Warps, an in-app credit system: You can buy 500 Wraps for $5, and approving a signer will usually cost around 40-50 Warps (depending on gas cost at the time of the transaction).

(Warps are an interesting experiment that deserve a separate article.)

Revoking a signer

Obviously, a user must be able to revoke a signer, and they can do so using their private key and posting the revokation onchain to let everyone know that the signer is no longer authorized to act on their behalf. This was the whole point of not giving away our private key in the first place.

But, when a signer is revoked, hubs see messages that are no longer signed by a valid signer. Most people's first thought is OK, but these are old messages signed when the signer was valid. But you have to keep in mind that Farcaster is an open, p2p network. Hubs are added and removed all the time. You could spin up your hub right now (it's actually quite easy) and your hub would receive messages from other hubs it discovers in order to get its history (aka state) up to date. How can your newly created hub know when a message was signed?

This is why hubs have a simple way of "thinking": not a valid signer, not a valid message. And, as a result, when you revoke a Signer, all messages signed using it, are pruned by hubs!

This looks bad. The truth is there is a simple solution that no app (to my knowledge) has implemented (yet). Remember the message example we used earlier? What if you signed the same message with a different signer?

Signing the message with new signer will create a new signature, but the message data and the message hash will stay the same: Same user (fid), same content, same timestamp.

• To any client, this new, re-signed message is the same as the original one.

• To any hub, this is a valid message, provided that the original (same hash) is not in the hub's database.

So, an app could:

1. Download all your messages (your Farcaster history)

2. When you remove a signer, and some messages are pruned, re-sign these messages (from your download) with a new signer.

3. Post the re-signed messages to a hub.

You can perform the above steps using https://github.com/vrypan/fario if you are comfortable working in the command line. You will have to:

• Backup your data using fario-out --all.

• Use fario-grep to select the records signed by the signer you want to remove.

• Remove the signer using fario-signers remove and create a new signer using fario-signers add

• Re-sign the messages using fario-signers sign

• Upload the re-signed messages using fario-in

Final thoughts

Signers are an elegant approach to delegating permissions. It allows users to easily let an app act on their behalf, but at any point in time, they can revoke this permission.

The lack of a simple, user-friendly app that allows users to revoke a signer without deleting all activity performed using it, is definitely a pain-point looking for solutions: Right now, using a signer means that you are stuck with it, since revoking access will delete any casts, likes, recasts and follows you have performed using it. (Unless you are one of the few users who understand the technical details of Signers, and have the skills to use something like fario or put together a script by yourself.)

Looking forward to try the first apps that will give a user-friendly solution to this!

So here are some of my favorite Farcaster-related links.

casthose.xyz: a nice little tool that shows every new cast in real time.

Fresh blood: a sub-page of marble, showing new user signups. (marble allows users to do a "cast-storm")

vasco.wtf: Gives you an x-ray view of any cast (the "source" of the cast). Just replace the warpcast.com part of a cast on warpcast with vasco.wtf. (I also created a bookmarklet which does this automatically and I use quite often.

fardrop.xyz: Enter a farcaster username and get a list (of a merkle tree) of the addresses of its followers. Ideal if you want to airdrop or create an allow list using the Farcaster social graph.

farcasteruserstats.com: Stats for any user. Here is my page.

later.wtf: Schedule a cast to be posted in the future.

searchcaster.xyz: A search engine for Farcaster.

Farcaster dune dashboards by @pixelhack and @gabrielayuso.eth

buidler.app: A web annotation tool that enables users to collaboratively annotate and discuss any webpage. One of the most exciting features of Farcaster.

farcord.com A Discord-like interface for Farcaster.

gift.fcstr.xyz lets you give the gift of Farcaster to a friend (you can pay for their signup).

If you are worried about your available Farcaster storage, cast @fc1 storage and a bot will respond with your storage usage and limits. Of visit caststorage.com to check and buy additional storage if needed.

Also, make sure you subscribe to outcasters.xyz, a (beautiful!) weekly curation of what happens on Farcaster.

Of course you can always take a look at https://www.farcaster.xyz/apps that lists a growing number of apps built on Farcaster.

On October 11, 2023, Farcaster opened its doors to everyone (a.k.a "went permissionless").
If you want to create an account, go here.

Farcaster is a lot like and a lot unlike other social networks. There's so much to learn and explore, but if you are new, this article will help you find your way around.

Warpcast is to Farcaster, what Firefox is to Web

Farcaster is a protocol, and Warpcast is a Farcaster client, much like Firefox, Chrome, Safari and Edge are clients for the WWW. There are many other clients and applications. You can find an (incomplete!) list of applications that use Farcaster here.

If you don't have a Farcaster account, the simplest way to create one is to install Warpcast.

You own your Farcaster identity.

Everything you do on Farcaster (casts, likes, recasts, follows, etc.) is tied to your Farcaster Identity (fid). No one can take away, suspend or cancel your Farcaster identity: it is controlled by an Ethereum address only you have the keys for. Don't worry, if you loose your keys, there is a way to recover your identity.

Open, Decentralized

Farcaster is an open protocol. This means than anyone can build applications on top of it, without asking permission and without paying fees. Compare this to using Facebook, Twitter/X, or Reddit APIs: Each one of these companies has changed policies, requirements and pricing, often pulling the rug under developers' feet.

Farcaster is decentralized. At the core of Farcaster are the Farcaster hubs. Every hub keeps a complete copy of everything there is on Farcaster. Hubs talk to each other and sync their status to reach consensus. Anyone can run a hub. If you like experimenting, you can run your own hub, even from your home (hardware requirements are minimal, your previous PC or laptop is probably more than adequate).

Why do I have to pay?

Because there is no Twitter or Facebook to pay the costs.

In exchange, you own your Farcaster identity, data and network.

There are two costs to using Farcaster.

Storage space on hubs. For most users, this will be a cost between $0.6/month and $1/month, depending on the payment method. The easiest way to pay is through Warpcast's in-app purchase ($12/year including AppStore fees and USD-to-ETH conversion). But you can also use a service like caststorage.com, pay in ETH and avoid the AppStore tax.

The cost of identity-related transactions (remember, your Farcaster identity "lives" onchain, and onchain transactions have a small cost), such as the initial signup or giving permissions to apps. This cost is small, and in some cases apps may pay it on your behalf to make your life easier, but occasionally you may be asked to pay something like $0.99 (the actual cost is much less, and there will be ways and tools to pay much less in the future).

Where can I learn more?

1. farcaster.xyz, is the home of the Farcaster protocol.

2. thehubble.xyz is Hubble's homepage. Hubble is the software run by Farcaster nodes.

3. Farcaster Overview: short videos explaining the core concepts of Farcaster. (Keep in mind that the videos were created some time ago, and some of the details may have changed through Farcaster Improvement Proposals.)

4. Check out the articles on Purple Submarine.

Welcome to farcaster!

Collect NFT

How it works

Varun has created video that explains everything in a very simple way:

• Every Farcaster account is owned by an Ethereum address (often called "wallet").

• Every Farcaster account can also set a recovery address. The only thing the recovery address can do is to move your Farcaster account to a new address.

Now, moving your account to a new address is quite a power to give to someone. The owner of the recovery address can save you if you lost your "secret phrase" (think of it as your password), by moving your account to a new address you control. But if they go rogue, or get hacked, they can also steal your Farcaster account!

Failsafe, no failsafe

If you watched the above video, you may have noticed that there was a fail-safe: Between the initiation of the account transfer and the actual transfer there was a 5-day delay during which you could cancel it and even change/revoke the recovery address.

I'm writing in the past tense because this fail-safe was removed by FIP-5: Instant Recovery: The recovery address can now instantly move your account to a new address and there's nothing you can do about.

While this may seem a bad thing, it's not that bad, and there's good reasoning behind it:

1. 99% of the users, especially new users that will join once signups are open for everyone, are used to Web2 platforms: I lost my password, I use my email to recover it.

2. When a new user signs up, Warpcast (that most of them will use to signup), sets the recovery address to one Warpcast controls. This way they can hide the complexity from users, and provide them with what most users expect: Being able to instantly help them recover their account.

Where did decentralization go?

If you are here because of the Web3 ethos, decentralization and sovereignty, you're probably disappointed. What I just described is a way for a centralized entity (Warpcast) to take away your decentralized Farcaster identity. If that's the case, what's the point of all the decentralization, web3 and the costs that come with them?

There are a couple of good answers.

First of all, you can set your own recovery address: You can use another address you control, a good friend's address you trust, or your lawyer's Ethereum address (yes, there are some that know what this is).

You could also set it to an M-of-N multisig wallet, controlled by N people you trust.

I can also imagine more exotic implementations of a recovery address.

For example, all Farcaster accounts a company uses can have a recovery address controlled by their IT, which has a dual purpose. 1) Being able to support users who lost their secret phrase and 2) being able to take away a corporate account.

Or a smart contract that implements the time-delay feature removed by FIP-5.

Or even create a valet service that users pay annually and in order to recover their account, users have to do a video call, prove their identity, and then the service helps them recover their account.

Takeaways

1. If you sign up to Farcaster using Warpcast, Warpcast can recover your account if you loose your keys, but they can also take away your account, or compelled to do so. Keep this in mind if you think that someone may want to censor you in the future.

2. If you are an experienced Web3 user, you may want to consider some of the options mentioned above, like setting the recovery address to one controled by your hardware wallet, or a multisig.

3. There is a wide range of services to be built that help users recover their Farcaster accounts. You may want to build one of them.

One of the great misconceptions that goes hand-in-hand with this milestone is that users will have to pay to perform the onchain actions, such as signing up, transferring their Farcaster Id (FID) to a new address, registering/revoking a Signer (see my post about Farcaster Signers) and getting storage units.

This is only partly correct.

First of all, let's agree that we do want the onchain elements of Farcaster. These elements are what make our Farcaster identity permissionless and censor-resistant: No one can suspend/delete your account, because it's registered onchain.

Second, onchain transactions have a cost, "gas". While transactions on Optimism (L2) are much cheaper than transactions on Ethereum (L1), they still cost something.

But here is the misconception:

Each one of these interaction happens onchain, and, yes, there is gas to be paid, but the user does not have to be the one that pays.

Let me explain. Farcaster smart contracts allow each one of these transactions to be executed as follows:

• The user signs the request offchain using their private key.

• A third party ("sponsor") performs the onchain transaction on behalf of the user (using the signed request) and pays for the gas.

For example, an app that allows users to interact with Farcaster, can pay for the signer registration, if they want to make it easier for new users to use the app.

Or an app that wants to aggressively register new accounts and get a significant market share from Warpcast, can pay for the registration of the new FIDs.

It seems that Warpcast will offer a "bundle" that includes signup and one storage unit at $10 as in-app purchases. This price includes an up to 30% cut for the app store. Opportunity! Create your own Web version, use Stripe, charge $7 and probably make a good profit of >$1 per registration.

Side note: We should applaud Warpcast's decision to offer the service at a price that leaves space for easy competition. They have a defacto dominant position in the Farcaster ecosystem and making their price aggressive would leave zero space for competition at this stage. On the contrary, if they actually go with the above pricing, they create a motive for competition.

I can even think of flows that are... a bit shadier: Offer free signup and storage and approve a signer, and then use the signer to follow (on behalf of the user) some specific Farcaster accounts -a.k.a "how to get 20,000 new followers in a few days".

Here is an other one: A service that offers holders of a specific NFT free or discounted signups/storage. It can be used by NFT creators who want to offer some extra value to their collectors. Or maybe it's a POAP, and free registration to Farcaster or one storage unit is a small gift for anyone who attended an event.

The more I look into it, the more I tend to think of Farcaster as an extremely well-thought implementation of an elegant protocol. I find it fascinating that its design, paired with web3 composability, can unlock so many possibilities we never had in web2.

For example you know that web URIs start with http:// or https:// And when you click a "link" (i.e. an HTTP URI) in an application (such as an email client or a PDF viewer), your operating system knows that there is a certaing application that can handle this URI: your browser.

On the other hand, if you click on an ftp:// URI, an other application may open up -or maybe your browser again, depending on your configuration.

Well-defined protocols come with well defined URI "schemes", i.e. a very specific syntax that a URI must follow. For example, after https:// comes the server name or its IP, and then a "path". So, when an application reads https://test.com/demo/1.html it knows that it should connect to the server test_dot_com and use the HTTP protocol to request the page /demo/1.html.

One of the nice things with protocol URIs is that they do not depend on the specific application you use. You can switch your default browser, or install a new ftp client and they will still work -they will just open in a different app.

At the moment, we don't have a well-defined URI scheme for Farcaster.

As a result, when a user wants to link to their Farcaster profile, they use the URI provided by a specific client, usually Warpcast -something like https://warpcast.com/vrypan.eth. When they want to share a link to a cast, they use again the URI provided by a client, like https://warpcast.com/vrypan.eth/0x7fb548. Similarly, if you click on the share button at the end of this post, you will open a link that looks like https://warpcast.com/~/compose?embeds...

All of the above work. But they create an unhealthy ecosystem:

• First of all, the dominant client (Warpcast at the moment) is not only favoured, but also creates a moat around it. If every Farcaster-related interaction points to warpcast.com, most probably, this will be your client.

• We also rely on an infrastructure we (as a community) don't control and we shouldn't have to, like DNS. If Warpcast (or any other client) lost their domain next year, all these links would break.

• We introduce a centralisation vector: If everyone uses a specific web client to point to Farcaster resources (casts, profiles, etc.), if the client is forced to censor some of them, this will affect (in practice) the whole ecosystem.

The solution is to define a farcaster:// URI scheme that any farcaster client can implement. This would allow us to link to farcaster resources using URIs like

• farcaster://user/vrypan.eth

• farcaster://cast/vrypan.eth/0x7fb548

and they would trigger your farcaster client to jump to the specified resource, just like clicking a mailto: URI opens your email client or an http:// URI opens your browser at the specific address.

These URIs don't depend on, or favour any, specific client or site. They don't even need DNS to work. They only require farcaster clients and farcaster hubs.

If you are a developer, please check out the corresponding FIP. It will take some serious brain power and expertise to define something that is both useful and elegant and will be able to withstand the test of time. Your comments are needed.

If you are an end-user, you can advocate for the need of a farcaster: URI scheme.

Note: There is a long, decades-old, discussion about URIs (Uniform Resource Identifiers) vs URLs (Uniform Resource Locators). I decided to use the term URI in this article. If you're into these things, feel free to mentally replace URI with URL wherever you think it's appropriate :-)

If you're not familiar with Farcaster signers, the best place to start is Varun's 5 minute video.

In short: To avoid exposing your private keypair that defines who you are on Farcaster, applications create their own keys, you sign them, and tell the network that this new keypair (the "Signer") is allowed to act on your behalf.

If you open Warpcast mobile and go to Profile > Settings > Advanced > Manage connected apps you will see something like this. In my case, I have approved two Signers, Warpcast and Herocast.

These two signers can do everything on my behalf, except take actions that relate to my identity: For example, they can not add/remove signers, or change my Farcaster name, but they can create new casts, delete old casts, like, recast, etc.

It is important to understand that every message (casts, likes, etc are messages sent from the app to the Farcaster network) a signer sends on my behalf, is signed by the Signer's key and not mine. Which is perfectly fine, since I have sent a message signed by my key letting the network know that this is OK. Plus, at any time, I can revoke a signer by sending a Farcaster message telling the network to remove the specific key from my approved signers.

However, this creates a problem: After I remove a signer, hubs will find messages that are (now) signed by a key that is not approved by me -and they will delete them.

This is why if you click on the trashcan icon next to a signer, you will see something like this.

In addition, you will also see a message that this transaction happens on-chain, and you will be asked to cover the cost of the transaction ($0.99). Which makes sense: Someone has to pay for it, and we don't want to rely on a centralised entity or company to cover these costs.

In this case, the amount is collected by Warpcast to pay for the gas fees, but there's nothing stoping a knowledgeable user from taking the required steps to do it themselves and pay the gas fees in $ETH.

Implication: cost

The concepts and the flows described above are optimised for decentralisation and openness. But when it comes to user experience, especially for users used to centralised social apps that covered all operating costs in exchange for monetising their control over the network, they will probably create a number of issues.

First of all, adding or removing an app (i.e. a Signer), has a monetary cost attached to it. Many users will be reluctant to do so, which means that:

1. The app that onboarded most users to Farcaster (100% Warpcast for now) has a significant advantage compared to other apps.

2. Users will be more reluctant to even try a new app.

Is this bad? Not necessarily.

This cost may also be an opportunity for a Farcaster project/app that has an alternative revenue stream, or enough funds: They can cover the costs and offer these services for free, and in doing so they can grow their user base much faster, and even become the most popular Farcaster client.

I find it very interesting that even if an app pays for these costs, by doing so, they help the network grow. And given the (sufficiently 😀) decentralised nature of Farcaster, if users are happy with Farcaster but dissatisfied with the specific app, the cost of moving to an other app is low enough (<$1) for most to do so. So, in a healthy and large enough Farcaster ecosystem an app cannot rely on their large user share to keep their users. (At least from this point of view.)

Implication: the risk of losing content

The second implication is that removing a Signer will result in loosing all content and activity the user created through it: casts, likes, recasts, follows. How many users will be willing to remove a signer if all the content they created will be lost?

However, this is a limitation of the current implementation in Warpcast and not a technical limitation of the protocol.

As Varun explained in this cast, there is a solution: An application could download all your messages signed by one Signer (and maybe delete them from the network if needed), re-sign them using a new Signer and re-submit them to the network.

I consider this is an opportunity for developers who want to join the Farcaster community: An application to manage Signers.

My ideal Signers Management Tool?

1. It allows me to List/Add/Remove Signers

2. It shows me which messages will be affected if I removed a Signer.

3. It offers me the option to re-sign messages (in bulk) using a new signer. (Even create a new Signer on the fly, to be used just for this operation.)

4. It allows me to pay for gas for these transactions using my own ETH wallet.

As things are today, I'm very reluctant to experiment with Farcaster apps because I know that if I don't like them and I want to remove them, the content I created will be lost. Having such a tool, or integrating this functionality in an other app would eliminate this risk, and I would be more open to trying new apps.

So, if you look "inside" this cast,

you will see something like this:

What makes the above cast part of the Warpcast channel is the specific parent_url, which this case points to this NFT collection. Any cast with parent_url=chain://eip155:7777777/erc721:0x10a77f29a6bbeae936f3f27cd60546072dae4e41 will appear in the Warpcast channel.

So, can anyone create a channel just by setting parent_url to some value?

Yes and no.

Yes, you could do it (the Warpcast client does not allow you to do this at the moment, but other Farcaster clients, like opencast, do.)

No, Warpcast, will not treat any parent_urlas a Channel. Setting for example parent_url=https://paragraph.xyz/@purplesubmarine/ will not be treated as the Purple Submarine channel: Warpcast channels are a curated list of URLs managed by the Warpcast team.

Is it bad, that Channels are controlled by a small team?

I think that there is a lot of value in having a curated list of channels. I consider channels to be a client-controlled feature, not a farcaster protocol-level primitive (the primitive is FIP-2, mentioned above).

Eventually, I would like to see a way for users to "subscribe" to various channel directories.

For example, there could be the Warpcast channel directory, curated by the Warpcast team. And maybe some algorithmically generated directory by a service that keeps track of parent_urls used in casts, and adds them to its directory after they reach a certain size (number of casts, or number of users, or number of reactions). And also some DAO-controlled directory that curates a highly curated kids-friendly channels directory.

One of my favourite ideas is a directory based on a ERC721 contract. The contract allows one NFT to be minted per day, using a nouns-like auction. Each NFT minted becomes a new channel. The owner can set the artwork and description on-chain, which will create in a nice, "curated" (limited supply of 1/day, cost) but permissionless directory of channels available on-chain.

It would also be nice if farcaster clients allowed users to manually add a URL and set it as a channel: If channels are something like RSS feeds, we can have directories (like podcast directories maintained by Apple and others) but also allow users to manually enter a URL to subscribe to.

Most of the above can be implemented by what we already have in place. One limitation of the existing model is hierarchically organised channels that allow users to subscribe to a channel that includes sub-channels (for example, subscribe to Sports and see everything under Sports/Football, Sports/Basketball, etc.) Of course a client could implement something like this, but it will require significantly more resources to do it, because, at the protocol level, farcaster hubs do not provide a way to easily fetch this information.

Also, something that is not being addressed yet (Warpcast is doing some experiments) is if channels will have some kind of moderator/curator/owner and, if they do, if this will be somehow translated to a protocol-level feature, or remain a client-specific one.

Channels are a very interesting thing. Feature? Primitive? It's up to the community and the devs to decide. Are they a Warpcast feature or a Farcaster primitive?

There's a great discussion between @billzh.eth and @dwr.eth where Dan shares a lot of his thoughts on channels. Check it out: