Disclaimer: the whole post was translated by chatgpt from its original
Chinese version, I only changed a little. However, I won't defend any mistake. If you find any, then point it out, thanks 😄.
I shared my learnings on the internal technical implementation of the Farcaster Hub in my previous article (in Chinese). Today, I would like to talk about Farcaster development. Why do I think Farcaster development deserves to be known? The reasons are quite simple:
- Regardless of external views on web3, you cannot deny that it is becoming a trend. As a practitioner in the software industry, ignoring this trend can be seen as "ignorant arrogance."
- Farcaster itself can be considered a successful case of a web3 application, with many aspects worth studying, whether in technical design or business model. So, why not learn from a successful example?
- Farcaster is on the rise, which inevitably brings many opportunities. To avoid letting these opportunities slip away, understanding its development is a necessary choice.
So, let's get into today's topic.
Farcaster Application Types
Currently, developers can develop three types of Farcaster applications: frame, action and bot.
Frame
A Frame is an interactive application embedded in the Farcaster information stream. A typical example:
Some might immediately think: Isn't this just another WeChat Mini Programs? My opinion is: similar but not same.
Although it can be categorised as a mini-program since it is runing within a Farcaster client, it still serves the scenario of users reading the information stream without intending to outshine it as a highly interactive mini-app.
For example, if I find a user I follow recommending a good product and want to learn more before deciding to buy it, without a frame, I can only click the product link to read more on the website. Afterward, regardless of whether I intend to buy it, if I want to continue reading the information (which is highly likely since I saw the product while reading), I have to return to the application.
The whole interaction process involves switching between two applications, bring a bad user experience.
With the help of a frame, merchants can create a frame for each product to help users learn and purchase without leaving the reading application, thus not interrupting the original purpose: reading information.
On its implementation, the frame extends the OpenGraph protocol, with the entire UI essentially being an image in OpenGraph, the interactive components are the result of Farcaster extending the protocol. Technical details can be found on its protocol site.
If the above has raised your expectations for frames, I must temper them. If you want to achieve a highly interactive UI like WeChat Mini Programs, the frame does not support this. It is similar to early JSP applications, where the UI is generated by the backend with limited front-end interaction, and overall interaction is restricted by the running environment, i.e., the Farcaster client.
For someone, this might be disappointing, even leading to further criticism. However, I personally think we can learn some goods from Farcaster:
- From a design perspective, by extending current existing standards, it lowers the entry barrier, avoiding the need to create new concepts and quickly attracting developers while utilising existing tools.
- From an interaction perspective, it introduces a new experience. As the saying goes: "A small step for xxx, a giant leap for xxx."
- From a business perspective, it builds a developer ecosystem, helping to consolidate its market position.
Action
An Action is akin to an extension of the Farcaster client that users can install. Once installed, it can be used for each cast, as shown below:
In the image, "Bot or Not" and "Playbot" are installed actions. Clicking them triggers corresponding behaviours. Technical details can be found on here.
Bot
A Bot is simpler and fundamentally similar to other types of bots, such as a twitter bot, listening to messages and responding accordingly. Technically, it involves a webhook and an API call:
- The webhook listens for messages.
- The API call responds to messages from Farcaster users.
Developer Resources
A workman is only as good as his tools. Entering a new development field without systematically exploring the tools in it is unwise.
Currently, mainstream frameworks include:
We're using frog, mainly because it is lightweight and based on hono. It can be used for frame, action and bot development.
Similar to Ethereum development, interacting with a Farcaster hub requires APIs. The main API service providers are:
We currently use neynar, primarily due to its API design, lack of additional requirements and convenient payment which support pay-with-crypto.
For frame UI design, frog has a corresponding UI library: frog-ui, and provides corresponding design specifications: fig.
Other useful auxiliary tools include:
For debugging, you can use either of the following tools to facilitate access to local frames:
Development Considerations
This article does not intend to be a step-by-step tutorial but lists points to note during development.
TX Flow
Since frames are rendered on the backend, some processes that are common in normal frontend development may not be as straightforward, such as completing a transaction. This document explains the entire transaction process in a frame.
In simple terms: the backend renders frame, a user triggers tx, then the backend prepares and returns the tx data, the app redirects tx data to wallet, finally it redirects to the url specified by the backend with tx id. With this context, it is easy to understand the tx section in the frog documentation.
Frame Limitations
- About UI
- Frames can't have any client side js code in the generated HTML. This makes it impossible to achieve a highly interactive front-end UI.
- The UI is essentially an image, so there is little interactivity. The interactivity provided relies on a Farcaster client's built-in interaction definitions for frames, not the HTML markup defined by the developer on the backend.
- Cache Impact
- Pay attention to setting cache-control in the constructor to meet your needs and avoid previous abnormal UI states affecting the current normal UI state.
- State Management
- Although frog simplifies this task, please note that the state is essentially session global across frame URLs. Therefore, careful planning of the state is needed to avoid interference, and reset when necessary.
- Unable to cast or recast on behalf of current Farcaster User in a frame.
- For example, if you want to create a button in a frame that allows users to recast when clicking, and this recast is sent as the current viewer's identity, it is not supported due to the need for user signatures in Farcaster messages.
Indexing
Those familiar with Ethereum development should be familiar with the concept of indexing. In the early Farcaster GitHub repo, a separate replicator was provided to help complete this task, along with a corresponding database schema.
However, this tool has some flaws. Based on our own experience, the main issues are slow (although our local hub has synced already, but the database lags behind) and high resource consumption. Recently, this repo has been removed, and the development team plans to use shuttle as a replacement. But it seems to be in the early stages.
Additionally, if you plan to do indexing, it is recommended not to use a public node but to set up a local node and point the data source to the local node. This is because public nodes usually have rate limits.
Contract
Currently, the chains supported by Farcaster are: mainnet, base, optimism, and base sepolia. This is seen in warpcast; other clients have not been investigated.
If your contract is not fully permissionless and you want to ensure that all contract calls are initiated by the frame app, consider introducing a signature mechanism: the frame server signs and sends the signature to the client, which attaches it when initiating the tx. The only thing to note is the non-reusability of the signature to avoid replay.
Verification
The outside world is dangerous. Unlike normal apps, frame apps do not have a login process. Therefore, to ensure that requests received are from trusted sources, signature verification is necessary in several scenarios:
- In frames, refer to frog's documentation.
- In webhooks, refer to neynar's documentation.
Farcaster and Warpcast
Farcaster is the protocol, while Warpcast is one of the client implementations. If you are not satisfied, you can develop your own client to connect with a Farcaster hub.
With this understanding, you can know why warp can only be seen in Warpcast app but not in the Farcaster GitHub repo.
Conclusion
Now, you should have the big picture of Farcaster development. Finally, let's have a brief discussion of application scenarios.
For embedded applications like this, my personal view is: it must enhance the user's experience in the host application, and the scenarios it serves should follow this principle, otherwise, it is unnecessary.
For frame scenarios, developing frame games is clearly not a good idea. Not only would the experience be poor, but it also goes against the main purpose of users opening a Farcaster client, which is to read information. For example, would you play games while shopping?
However, in a different scenario, if a frame could quickly generate slides about a product, it would be a meaningful attempt. It's similar to browsing window displays while shopping. Moreover, this tool simplifies interaction. For example, previously, to introduce a product in more detail in a host application:
- Either create a video and share the video link, allowing readers to watch the video while browsing the information stream without switching applications.
- Or share an article link, using the OpenGraph metadata.
The former has high production costs, and the latter has limited expressiveness. Now, with frames, this functionality can be easily achieved. And promotional images generally cost less than promotional videos. With the help of related tools, the cost might be further reduced, which is the motivation behind my creation of this frame template.
Everything that needs to be said has been said. Now it's up to your imagination, ;)
Top comments (0)