IMPORTANT: This post contains ideas intended to spark discussion and gather feedback. These are not final concepts and must not be interpreted as implementation details. For official information about how XMTP works, see the XMTP technical documentation. Have questions about this post? We’d love to hear from you—post a reply.
Frames, the new widget-like experience that recently rolled out in the Farcaster ecosystem, has all of web3 buzzing.
Hats off to Dan, Varun, and the Warpcast team for putting together such a simple, yet powerful primitive for developers to run wild with.
We at XMTP Labs think they are super cool and could represent a watershed moment for web3 UX, so it feels natural to explore how to support and extend them in XMTP. Above all, we want to be supportive of Warpcast’s work, and support developers by creating even more surface area for their Frames.
It’s early days right now, and there’s a lot more to do to see Frames as a fully supported, fully-featured thing, but seeing the results of the early prototypes working gives us a lot of energy for the possibilities.
+ 
Relevant links:
- XMTP Improvement Proposal Draft, about bringing Frames to XMTP
- Two open-source libraries
frames-client: Extends an XMTP client to send a POST request to a Frames action, with an XMTP signatureframes-validator: Verify XMTP-signed actions
- [SOON TO COME] Alpha Frames reference implementation in xmtp.chat
Guiding principles in bringing Frames to XMTP:
- Ensure that Frames within XMTP adhere to a privacy-is-a-must-not-a-nice-to-have mindset
- Before we get going too far, I want to call special attention to my colleague Nick’s points on the privacy and security considerations around Frames.
- Specifically that the current implementation in the wild exposes user IP addresses to a Frame’s developer when it’s loaded—something that should be explicitly avoided by using a proxy
- If we’re not careful, adding support for Frames could be a step backwards here, so as this is explored it’s critical that we keep privacy and security top-of-mind.
- Before we get going too far, I want to call special attention to my colleague Nick’s points on the privacy and security considerations around Frames.
- Focused on maximum compatibility, with minimum extra dev work required
- Make is easy for devs to build frames that can take users from public to private spaces
- Make it easy for devs to build frames that extend in-message functionality
Background
What is a Frame?
Frames are little self-contained mini-apps, shared via a URL. They adapt the old Open Graph Prototcol to insert some new Frames-specific metadata into the <head> of a webpage. Webpages can “frame-ify” by adding a few properties that start with this: <meta property="fc:frame".
- Image
- This is the image that will be displayed within the frame, as well as what is used as a fallback for (in this case, Farcaster) clients that don’t know what a frame is
- Button
- Up to four buttons can be included in a frame, each of which can have a short label
- Action
- Buttons can perform actions, like call out to another URL with a POST request, and even re-draw the frame with entirely new options when used
What makes Frames special?
Frames takes interactive elements beyond simple links by associating a cryptographic signature with a user’s click. ”Proof of Button Click” if you will…
And because in the Farcaster context Frames live within an app (Warpcast) that can sign on the button-clicker’s behalf, more information can be sent to the Frame’s URL about the clicker, and what to do next.
As an example, I can put up a frame that says “Anyone who follows me can mint this NFT for free” with one, simple button. If you tap on that button, and happen to follow me, then the frame can get updated with a mint confirmation, and your NFT will be on the way. If you don’t follow me, then you might see the frame change to first follow before continuing.
It doesn’t have the “if you follow me” feature, but Will’s cast here is a great example of a slick experience. Clicking the mint button lets a server somewhere know that you’ve clicked it, and the NFT can be immediately deposited into your account. So cool.
It’s a level of interactivity that previously was only possible within closed social networks such as Twitter, Facebook, etc. But Frames introduce a new promise: developers can add new functionality to existing surfaces where they’re supported (like Farcaster casts), permissionlessly. Developers can dream up wild new interactive experiences, and users can share them with just a simple link.
Will’s cast here features a frame where with one click you can mint an NFT.
Where do Frames go from here?
Right now a lot of the Frames that are being built are just fun. They’re experiments that help us test the boundaries of this new primitive, and just the start for what’s to come. After all, the iOS App Store and Facebook platform got their starts with poker and mafia games, respectively.
At the moment, Frames only live in Farcaster. Much of the primitive, though, is pretty universal, and there is no reason why it couldn’t, or shouldn’t, be adopted across the web3 multiverse.
Frames + XMTP
Bringing Frames to XMTP would dramatically expand the surface area for developers to build on, and enable an infinite amount of new use cases. After all, the “X” in XMTP stands for “extensible” and is a nod to the foundational idea that its messaging experience would evolve.
Historically, new Content Types have been how developers have extended XMTP’s functionality, adding new features like attachments, replies, and reactions to the messaging experience. Frames feels like a great Content Type candidate that could dramatically open up what’s possible within a conversation on XMTP.
Frames that lead to messaging
It feels like use cases where you might want to go from a public forum, such as Farcaster, to a private one, such as within XMTP messages, is a logical place to explore. These would follow a pretty typical formula of a user sharing something from their public profile, with an invitation to connect more intimately. Examples might be a creator looking to connect to fans, a brand looking to build a direct-to-subscriber base, an app exploring re-engagement tactics, etc.
Subscriptions
Shortly after Frames launched on Farcaster, Colin Armstrong published a frame of his own, promoting his publishing platform, Paragraph, with a “Subscribe” button right there. This meant that creators who use Paragraph to publish their content, could get new subscribers from right within Warpcast, and get notifications for new posts right to their XMTP inbox of choice (like Coinbase Wallet or Converse).
Paragraph’s example is awesome, and also isn’t the only way to pull off a Frame → Subscribe flow. This is one area where developers could go wild with different possibilities, and help to build more durable connections in the web3 space.
Granting messaging consent
Let’s face it, spam sucks. And yeah, even on XMTP I’ve gotten more than my fair share. But that’s all changing soon, thanks to some big improvements already rolled out to popular XMTP inboxes, and consent becoming a first-class citizen in the protocol’s featureset. Sorry, not sorry, spammers.
Right now if I fire up my XMTP inbox, there’s likely to be a “Requests” tab (check out Airstack’s API and example), where I can allow certain senders to reach me in my “primary” inbox. But what if I could share an entry code to skip my requests tab, like when I share a QR code in person?
Here I’m imagining a Frame that I send out in a link, where clicking on it would pre-approve someone to send me messages, and skip the filtering altogether. Now, I’d probably want to see some sort of logic built into the button action, such as checking how long their Farcaster account has been open, or if they’re following me, but the many permutations of that can easily be explored later.
From Mint to Message
There are so many creators out there that I’d like to stay in touch with…whether that’s to collect or listen to all of their future productions, or even open a channel for me to talk to them 1:1 (I can dream, right?).
A songwriter could put up a Frame with their impending album, and send follow-up messages about its release to anyone who mints its commemorative NFT. I’d do this a ton.
Frames that exist in messages
Yesterday the prolific 0xdesigner posed the question…
imagine what you could do with frames in direct messages
So far all of the Frames in the world are built with Farcaster in mind, but they could be adapted to work within the XMTP context. And entirely new Frames experiences could be built for an XMTP-enabled purpose, such as those that might send messages, allow for modification of contact preferences, or where Frames being sent to private audiences is required.
This is where we can take Frames to the next level, and expand on the foundation that Farcaster has set up: by bringing frames directly into messages. Let’s imagine what it would be like to have frames in messages.
Ok, but first, how?
The Frames spec is pretty simple, and would translate well to XMTP, such that compatible inboxes could just render Frame URLs in the same way as they might be rendered in the Warpcast context. Now, anything that is specific to the Farcaster network, such as something that would require an fid or knowledge of a user’s social graph, would probably not work without some translation, but that could be explored later too.
It’s worth calling out that as I write this, a whole bunch of Frames have already been tested within XMTP inboxes, and it’s remarkable how well they fit the experience—a testament to the simplicity of the primitive design, but also nature of the format.
The XMTP Labs team, and some of the other teams building inboxes are hard at work to bring Frames to life in their respective interfaces, first as a technical preview, but hopefully soon (if it all goes well), for the long-term.
The earliest experiments have been around taking the existing Farcaster Frames and rendering them in-line in a message. The next is to expand on the Frames spec, to be more generalized, and account for their use in non-Farcaster-exclusive contexts. One example of that would be to allow for actions to be signed by other types of accounts, such as an XMTP account.
If you’d like to read more on the technical nitty gritty, head on over to this XMTP Improvement Proposal Draft by Nick Molnar. It’s chock full of good stuff.
Gaming
Messaging is such a great conduit for turn-based games. We’ve actually already seen examples in the past where developers have built them into an XMTP messaging experience, but Frames changes the …game, pun intended. The previous examples of games-over-XMTP, like this one from a hackathon, had to build an entirely custom front-end wrapper for the experience to the work. Building a game experience within Frames, however, would make it immediately compatible with any XMTP inbox…and be portable no matter where they might be reading the messages.
State-gated messages
Using Frames, it would be possible to send a message with content, or an action, that unlocks based on certain criteria being met. Let’s take an example of an artist holding a secret show, which someone could RSVP for and get the address at the time of the event, all within a messaging context.
In the wireframes below, you’ll see a “Mint VIP Pass” action which would fire off an XMTP-account signed request to the related web service, validate some sort of criteria, and send back a relevant update. I call this kind of thing a “state-gate”.
This kind of idea is interesting because it shows the power of messaging to enable a private, intimate interaction, that gains super powers through Frames.
Conversational Commerce
Making it possible to start from a public interaction, and take it private, opens up a ton of possibility around commercial interactions. Recently I met someone from Kiki.global who is re-thinking what a beauty brand can be through more intimate interactions with its customer base. They also add some extra web3 flare in there with NFT collectibles of the products that you get.
It’s cool to imagine a world where they bring these types of interactions, like voting on the new product lines, right into a messaging context. There’s two things where Frames add something special to the mix here:
- Developing a Frame is permissionless, meaning that Kiki.world could build this, and have it be compatible with all XMTP inboxes, without requiring any involvement or intervention by the inbox builders. That’s a big deal.
- Interactions within the frame can be verified, as they’re signed
What would you build with Frames in XMTP?
While a handful of teams in the XMTP community work to bring Frames into your messaging experience, I’d love to see what kinds of questions, concerns, or ideas you might have.
- If you’re a developer, what’s on your wish list to get the most out of a Frame?
- If you’re a creator, what kind of frames would you want to see to help you reach or build deeper relationships with your fans or collectors?
- If you’re a user, what kinds of frames would you love to see within messages? Sky’s the limit