I wrote a SvelteKit starter for farcaster frames V2, now mainly people involved with developing Farcaster/Warpcast tech mainly use Next/React, in fact, many of the official libraries don’t have docs for other stacks.

Now we should talk a bit about version 2 for Frames(rebranded recently as Mini Apps), IMO frames V1 was a bit of a flop, because it used a very inefficient way to communicate, which was through images, at the time I was firmly against that spec, and I suggested using Iframe instead, which is the base for V2 spec that arrived almost a year later.

From this point, I will refer to mini apps as frames V2 as the rebrand is only a few days old.

In a nutshell, Frames V2 spec is based mainly on iframe, which uses the default communication protocol window.postmessage to communicate with the client. The issue is that after 3 years of Farcaster, the client diversification is not great(hoping it will change), things are very one-sided(no real advanced client open-sourced) and this affects all aspects of the Farcaster ecosystem, and that’s true for frames as well.

There are two ways that centralized decisions have affected frames v2, First,t the team was always against allowing arbitrary wallets to interact with their app. And generally against importing custody key into any wallet, but you’re forced to import it on their mobile app in order to work which is a bit ironic.

Now for any application that deals with wallets on mobile and the web, the general approach is to allow any wallet possible because there are 500+ wallets out there, and limiting them to a select few looks as gating, siloing, and centralization. Even people who have their own wallets do allow almost all other wallets to interact with their product even if they show their wallet first.(Uniswap, Magic Eden, UD, cyber etc)

Now on mobile, the only allowed wallets are Rainbow, Coinbase, and their own Warplet/Warpcast wallet (which is just a Privy product under the hood not even an in-home implementation). And again Warpcast mobile app probably under the hood runs two wallets because even before they added the Privy wallet they always had the private key to your custody account.

Now on the Warpcast desktop(website), you can interact with any wallet installed which is considerably more crypto-friendly and a good choice, but even there, the website was not meant to interact with the custody PK, and when it needs that it forces people to use their Warpcast mobile app which is a poor and non-crypto friendly user experience.

Because Frames V2 communication protocol also has wallet actions it means that generally, the experience on mobile and desktop will be very different, where on desktop you could easily select any wallet you want, but you won’t be able to do the same on mobile, and also some actions won’t be available on desktop even tough are possible because for those actions the implementation forces you to mobile, instead of also offer to directly use custody key.

The second decision which is not so toxic as the first and is more probably caused by a rushed release is that the spec as of this moment the context data for the user that’s viewing the frame is sent without a mechanism to certify the data is not spoofed, adding any mechanism would have been an improvement, even a week mechanism as generating a signature from the auth token or something that could be verified would have been great, that would have reduced the cases where the user needs to sign-in and devs could have had pretty good confidence that the data is valid and could have created much better user experience, especially since on desktop sign-in forces you to use mobile.

Now back to the SvelteKit starter, the repo can be used as a starting point to write many Frames v2 easily and it has the following benefits:

- low cost due to prioritizing SPA and prender, you can do server calls too, but is not recommended for simple Frames V2, because the Frames SDK will always be a client library(due to window.postmessage), server calls should only be used when absolutely necessary and not for rendering, because if you don’t need server calls, Nelify or Cloudflare allow basically unlimited requests for static asset code.
- install time, dev time shorter due to low complexity and fewer deps
- allowing the website to be viewed only in frame context, global stores for SDK and wallet to make wallet and SDK interaction easy

The Svelte kit template contains 2 subframes:

- one more complex where you can check and claim your Merkl rewards(Merkl from angle protocol not Merkle from farcaster, is a rather popular word in crypto)

- one simple demo frame for requesting a signature

You can find the repo at this address: https://github.com/andrei0x309/frames.flashsoft.eu

By the way, the blog(blog.flashsoft.eu) also has some support for frames v2, meaning any article URL will show a button, and the feature image of the post, and if the frame opens there’s also a button that only appears in frame context.

So v2 frames can be integrated into any website if you find a good enough use case.

My recommendation is that you have a general website that wants to interact with frames to integrate a Frame V2/Mini-app into your website.

The article is posted also on my blog at https://blog.flashsoft.eu/sveltekit-mini-apps-frames-flashsoft-eu 

I wrote a SvelteKit starter for farcaster frames V2, now mainly people involved with developing Farcaster/Warpcast tech mainly use Next/React, in fact, many of the official libraries don’t have docs for other stacks.

Now we should talk a bit about version 2 for Frames(rebranded recently as Mini Apps), IMO frames V1 was a bit of a flop, because it used a very inefficient way to communicate, which was through images, at the time I was firmly against that spec, and I suggested using Iframe instead, which is the base for V2 spec that arrived almost a year later.

From this point, I will refer to mini apps as frames V2 as the rebrand is only a few days old.

In a nutshell, Frames V2 spec is based mainly on iframe, which uses the default communication protocol window.postmessage to communicate with the client. The issue is that after 3 years of Farcaster, the client diversification is not great(hoping it will change), things are very one-sided(no real advanced client open-sourced) and this affects all aspects of the Farcaster ecosystem, and that’s true for frames as well.

There are two ways that centralized decisions have affected frames v2, First,t the team was always against allowing arbitrary wallets to interact with their app. And generally against importing custody key into any wallet, but you’re forced to import it on their mobile app in order to work which is a bit ironic.

Now for any application that deals with wallets on mobile and the web, the general approach is to allow any wallet possible because there are 500+ wallets out there, and limiting them to a select few looks as gating, siloing, and centralization. Even people who have their own wallets do allow almost all other wallets to interact with their product even if they show their wallet first.(Uniswap, Magic Eden, UD, cyber etc)

Now on mobile, the only allowed wallets are Rainbow, Coinbase, and their own Warplet/Warpcast wallet (which is just a Privy product under the hood not even an in-home implementation). And again Warpcast mobile app probably under the hood runs two wallets because even before they added the Privy wallet they always had the private key to your custody account.

Now on the Warpcast desktop(website), you can interact with any wallet installed which is considerably more crypto-friendly and a good choice, but even there, the website was not meant to interact with the custody PK, and when it needs that it forces people to use their Warpcast mobile app which is a poor and non-crypto friendly user experience.

Because Frames V2 communication protocol also has wallet actions it means that generally, the experience on mobile and desktop will be very different, where on desktop you could easily select any wallet you want, but you won’t be able to do the same on mobile, and also some actions won’t be available on desktop even tough are possible because for those actions the implementation forces you to mobile, instead of also offer to directly use custody key.

The second decision which is not so toxic as the first and is more probably caused by a rushed release is that the spec as of this moment the context data for the user that’s viewing the frame is sent without a mechanism to certify the data is not spoofed, adding any mechanism would have been an improvement, even a week mechanism as generating a signature from the auth token or something that could be verified would have been great, that would have reduced the cases where the user needs to sign-in and devs could have had pretty good confidence that the data is valid and could have created much better user experience, especially since on desktop sign-in forces you to use mobile.

Now back to the SvelteKit starter, the repo can be used as a starting point to write many Frames v2 easily and it has the following benefits:

- low cost due to prioritizing SPA and prender, you can do server calls too, but is not recommended for simple Frames V2, because the Frames SDK will always be a client library(due to window.postmessage), server calls should only be used when absolutely necessary and not for rendering, because if you don’t need server calls, Nelify or Cloudflare allow basically unlimited requests for static asset code.
- install time, dev time shorter due to low complexity and fewer deps
- allowing the website to be viewed only in frame context, global stores for SDK and wallet to make wallet and SDK interaction easy

The Svelte kit template contains 2 subframes:

- one more complex where you can check and claim your Merkl rewards(Merkl from angle protocol not Merkle from farcaster, is a rather popular word in crypto)

- one simple demo frame for requesting a signature

You can find the repo at this address: https://github.com/andrei0x309/frames.flashsoft.eu

By the way, the blog(blog.flashsoft.eu) also has some support for frames v2, meaning any article URL will show a button, and the feature image of the post, and if the frame opens there’s also a button that only appears in frame context.

So v2 frames can be integrated into any website if you find a good enough use case.

My recommendation is that you have a general website that wants to interact with frames to integrate a Frame V2/Mini-app into your website.

The article is posted also on my blog at https://blog.flashsoft.eu/sveltekit-mini-apps-frames-flashsoft-eu