[Spike]: Common Farcaster Frame Prototype

[jnaviask]

Description

Farcaster recently released frame support, which allows for small apps to be embedded within a Farcaster post.

This seems like a great opportunity to enhance support for Common to allow for Farcaster virality that drives mutual growth and engagement. The basic idea will be to have a Common Frame that displays some aspect of the Common site, and uses the metadata from the frame to make interactions with Common easy. The two main pieces that may be worth investigating are (1) Content on Common (i.e. threads and comments), and (2) Communities on Common.

Technical Details

We will make the following assumptions. A Farcaster post with frame has access to:

1. The user's Ethereum address + user metadata.
2. The ability to sign an arbitrary byte string that remote server can verify.
3. Additional user-specific data sent to remote server via the frame.
4. The capacity to send a request to remote server on click.

So the most basic frame that we can conceptualize would involve the following flow:

1. A thread or comment is posted to Farcaster from Common, which creates a Frame containing a view of the thread's body and a button to post a reply (we could also embed a small editor inside the frame, but "reply to thread" link is simpler).
2. The user clicks the reply button and is sent to the thread, with the following actions happening automatically: a. If the user is new, a Profile and Address are created for them + they are signed in. If existing, they are signed in. b. If the user's address is not joined to the specified community, they are joined automatically. c. The reply entry is automatically opened + ready for them to immediately draft a response.

We can also see that a simplified version of this flow could work for a community (i.e. some info about community metadata + a button to auto-join the community).

How can this work? I propose the following flow:

1. Each query of the Farcaster frame produces a verification token with a short expiration window embedded into the frame.
2. The token is embedded into the signed metadata produced by frame actions and passed back to Common's server on button interaction.
3. The signed blob is validated on Common side and appropriate user creation actions are taken as needed. A profile is initialized with their Farcaster metadata if one does not already exist. The creation event replies with a randomized state id identifying the user about to be redirected.
4. The user is redirected with the provided state id, which is sent to the server and used to generate a session immediately = log the user in, and is then consumed (to avoid replays).
5. The user's intent is also provided as part of the redirecting URL (e.g. "action=reply") which triggers the expected frontend state (e.g. the comment box opens and is activated).

Please suggest any modifications or recommendations with a particular eye to security considerations. It may be worth building the "join" flow first, as it's a simpler flow that uses effectively the same logic, but note that we will want to use that same logic for activating content creation actions as well.

Deliverables

1. A basic prototype of a Farcaster frame that allows a user to one-click join + begin engaging with Common.
2. Document outlining architecture (with diagram, ideally) + considerations that arose over development (difficult areas of implementation, security risks, quirks of the API, etc). Architectural considerations should include evaluation of an interaction-consuming microservice vs doing it all via the main Common web app.

Timebox

2 days (minimum; may need extension given scope of project).

[dillchen]

Yes this is great, let's make sure to extend exploration to potential wallet interactions, buy sell stake.

Also question re session key infra @raykyri should / could chime in here. how our address model interacts with theirs

[dillchen]

These are scratch thoughts for frame product surface area:

• @sachben91 wants a poll card
• from @zakhap / @dillchen , it would be great to make a CAT directly embeddable as a frame where buttons trigger tx'es (all done with no code)
• out of scope for sure, but as we have custom theming, very cool to have extend CAT or w/e so that the frame follow's whatever community styling

[zakhap]

Open Q:

• On a Thread with both a Poll and a CAT, what would show up as the Frame?
  • The Thread with Join+Reply+React
  • The Poll
  • The CAT
  • Can we create a button interface for toggling between the above via the Frame?

As we add more actions to threads, we should be mindful of what we (can) make available via the Thread Frame.

[jnaviask]

We should establish a permalink standard for polls/other thread cards. @zakhap

[sachben91]

to add to what @zakhap said, would it be possible for the poll to be such that users can only vote if they are signed in on Common and part of the community that posted the poll? From reading the above seems possible but just confirming

[jnaviask]

to add to what @zakhap said, would it be possible for the poll to be such that users can only vote if they are signed in on Common and part of the community that posted the poll? From reading the above seems possible but just confirming

@sachben91 All polls on Common currently require the user to be signed in and part of the poll's community. There's no way to do otherwise. The idea in my original proposal is we simply create accounts automatically for Farcaster users when they attempt to take action on content from Common.

[dillchen]

What should show up on the frame? In response to @zakhap

1. If we have a form for CAT, basically each frame should be the first form field, include back and forward, and then default options. And then end in completion.
2. Image should be the form state

---

In response to @sachben91 / @jnaviask

We could gate in the backend on the frame, would require it to be checked server side, but technically it's just a POST request, and our TBC / gating mechanism should work as expected on the backend as long as that FC address has the token, and per jake, we've already created that address as use on our side

[dillchen]

Adding another request from @sachben91 here: https://commonxyz.slack.com/archives/C06AE3NB5V1/p1706718139428219

[dillchen]

@jnaviask et all:

https://www.notion.so/buildcommon/Farcaster-Common-Frame-s-cb75c2d5d3784f44a4dbf5cedc965743?pvs=4

please see this, I drafted this!

[ianrowan]

Just want to note some technical discovery here. There are 2 main constraints I think we need to consider/work with here:

1. One input field per frame(not set of frames)
2. The signer of frameMessages is the farcaster custody address, which will be different than users hot wallets in many cases(ie warpcast suggests not to use you hot wallet for custody)

I think for (1) we would need to consider which actions wouldn't be cumbersome to click through cards and wait for a http request to complete for each input.

• Isnt an issue for polls, threads, comments(buttons for all upvoting, voting, etc - single input to comment on thread etc)
• hard to picture create community working here
• actions like buy/sell stake are pretty easy to implement cards that yield a deeplink to the buy stake page based on a single input
  • https://warpcast.com/vadim/0xc294c4cb for example ** but see next section

To expand on (2) more - When I signed up for warpcast I let the app(which is technically considered a wallet in docs) set up a new seed phrase/address for me. warpcast suggests this to all users and sponsors gas if the users follow this path. Also pretty crazy to expect users to import their seed phrase into the app in the first place to use their hot eth address if wanted(this obv is a tech constraint/not their problem to fix)

That said I wonder how many users on warpcast are using the same address they would for example have linked to a common account? Not many new users would be my guess.

Another issue arises here too if we think of having users of warpcast connect their custody address to their existing common account as idt theres any way to push a SIWE request to the warpcast wallet and the only other solution would be to have them import their warpcast key into MM and sign which is unlikely to convert many users.

All that said the frame I linked above is somehow using warpcasts "Connected Accounts" feature to resolve a farcaster custody address(clicker of the frame) to one of their connected accounts. I haven't found how to do this yet but its def not at the frame level so I assume they're using Warpcasts/some API. So I think the best way to enable some of our address dependent features is to:

1. verify frame message signature is valid = resolve to farcaster custody address
2. Check if there's any chance there is a common account for this
3. Hit the warpcaster API/w/e to try to resolve to connected accounts
4. Loop through accounts til account found and act on behalf of this account

Altogether I think creating deeplinks/links to specific places in the app and relying on their current signed in session probably works better long term

[ianrowan]

Using an API like this, probably this one in particular allows us to resolve farcaster addresses to connected hot wallet addresses: https://docs.neynar.com/reference/lookup-user-by-custody-address

From that point as mentioned above only constraint is that the user has connected on farcaster

Also this(https://docs.neynar.com/reference/feed) for bridging

[dillchen]

Do you have point estimates for each potential frame? Or how best to break down the work?

Sent via Superhuman iOS @.***>

On Tue, Feb 6 2024 at 5:40 PM, Ian Rowan @.***> wrote:

Using an API like this, probably this one in particular allows us to resolve farcaster addresses to connected hot wallet addresses: https://docs.neynar.com/reference/lookup-user-by-custody-address

From that point as mentioned above only constraint is that the user has connected on farcaster

— Reply to this email directly, view it on GitHub https://github.com/hicommonwealth/commonwealth/issues/6505#issuecomment-1930891431, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIWMHPQDSBKAYOBB57SHGLYSKWPTAVCNFSM6AAAAABCRZ5COCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQHA4TCNBTGE . You are receiving this because you were mentioned.Message ID: @.***>