[Spike] Farcaster Research: 1) Login with FC 2) Farcaster Channels 3) Frames in Common

[dillchen]

Objective:

To integrate key Farcaster functionalities into Common, focusing on:

• Login with Farcaster to Common
• Synced FC Channel to a Common Topic Integration
• Integration of Frames as Card Types in Common

Timebox (1 day? to be decided by @jnaviask and tagged assignee):

Reference Material:

• Understanding Farcaster's channel concept: Farcaster Channels.
• Developer guide for casts and channels: Farcaster Developer Guides.
• Previous work on syncing threads to Common: Commonwealth GitHub Issue #4693.
• Reference Doc it's basically a signin flow that's similar to Wallet Connect with Deeplinks to their app / wallet

Acceptance Criteria:

Login with Farcaster Button on Common

• Objective: Implement Farcaster's identity layer for user authentication in Common, and display of FID as user name on common
• Challenges: Lack of method for signing arbitrary messages in Farcaster and its integration with Common's authentication process.
• Approach: Investigate using FarcasterID linked to wallet addresses for user login, potentially involving Metamask.

Synced Channel to Topic Integration

• Objective: Sync Farcaster channels with Common topics, similar to Snapshot and Discord integrations.
• Challenges: Bridging the gap between Farcaster's cast-based network and Common's forum-style discussions.
• Approach: Examine Farcaster's channel structure and API capabilities for cast retrieval and posting to develop an integration strategy.

Frames Integration as Card Types

• Objective: Embed Farcaster frames in a Common Thread.
• Challenges: Ensuring seamless, secure frame interactions within Common's platform.
• Approach: Explore Farcaster frame support and design a user-friendly interaction flow for Common's UI/UX. Deliverables:

Deliverable

• T Shirt Estimate of each item with high-level, bullet point implementation plan

• Key Focus on understanding if it does not currently fit into our domain model

• Preparation for an event storming session to discuss and finalize the integration strategy, ensuring comprehensive understanding among all team members.

• Nice to Have: comprehensive document detailing the proposed architecture, including diagrams.

[alexyoung23j]

minimum 13 points and more

Going to need a better understanding of what the actual goal of this feature would be. "Login with FC" is kind of a misnomer- farcaster is just providing an identity layer by maintaining a FarcasterID <-> wallet address registry on chain. Warpcast does not provide any way to sign arbitrary messages using the user's addresses. So if a user has connected a Metamask wallet to their Warpcast, we would just need them to log in with their Metamask wallet on CW.

Also unclear exactly what it would look like to become a Farcaster client. The reference doc basically explains how that would work, by generating a Signer, which then allows the client to post to the Farcaster network on behalf of the user. But unclear how that would actually fit into our existing architecture- how would threads/comments map to Farcaster posts, etc. Implementing an actual Farcaster client that plays nicely with our existing forum setup would be minimum 13 points, probably much more.

So my current recommendation is to not pursue this, because I think there is a fundamental mismatch between a "cast" based social network and the forum based community network we provide. The current farcaster bot implementation will include the farcaster user Ids as part of the thread author, so the identity is preserved across apps, and a link back to the original cast so users can always visit Warpcast and add a cast reply.

Now there are potentially ways to use the identity layer that Farcaster provides to augment identity on common- we could, for instance, check if a user who logs in with a wallet address has an associated farcaster Id, and then automatically add a link to their Warpcast to their CW profile page. Features of that nature make more sense to me than actually enabling writing to Farcaster AND CW simultaneously, or doing some hacky "login with FC" that amounts to a more confusing Metamask login.

Let me know if you had something else in mind for this feature that I am missing.

[dillchen]

Can we better leverage go to market with Farcaster => it's going to Metamask => can just pull in FIDs

• Solution 1: Pull in FIDs + (Lens) for other Namespaces to show on profile (8 points)

[ianrowan]

Some discovery for sign in with farcaster:

Farcaster provides an authkit similar to the wallet connect flow: https://docs.farcaster.xyz/auth-kit/introduction

This would be adequate for our base common user as it produces a SIWE signed message and provides us with access to the FID/Address/profile data: https://docs.farcaster.xyz/auth-kit/hooks/use-profile

The main restriction is that it gives no access to private keys to 1) sign any other type of message 2) create casts interact with farcaster etc

Warpcast has no way to provide access to the users signing key at the moment, but farcaster has a solution for this at the protocol level in the KeyRegistry concept: https://docs.farcaster.xyz/learn/what-is-farcaster/accounts#adding-account-keys In the case of the bi-directional sync we are becoming a farcaster client by definition here, so we would need to prompt the user to issue a new key(req on-chain tx with the keyRegistry contract) and then we store the private key of the pair to sign messages for farcaster hub(ie casts/reactions/etc). From research building this from scratch is no small feat and requires trustworthy private key storage security.

Luckily neynar(all roads continue to lead back to this API) provides an out of the box solution here(Sign in with Neynar). I used their demo and it was pretty clean, they also cover the gas for keyRegistry for the developer and the user meaning we do not need to have a wallet/relay to do this. The process goes as follows

1. scan QR
2. deeplink to warpcast
3. approve connection and new key registry in warpcast
4. wait for on-chain tx
5. neynar API now has the new keypair stored at a signer uuid our API key can access and push messages to farcaster with no user approval(in warpcast) ie its seemless
6. we store a signer_uuid from neynar on the profile/address of our user and this is all we need to make future posts on their behalf

https://docs.neynar.com/docs/how-to-let-users-connect-farcaster-accounts-with-write-access-for-free-using-sign-in-with-neynar-siwn

Easiest thing to do here would be to use their button and customize it for our style I think neynar is $49/mo fwiw https://neynar.com/#get-started

CC @dillchen @jnaviask

[ianrowan]

Not much to add for bi-directional sync as one side of it can basically just refactor the discord bot to use something like the neynar API and then use similar tags, etc on the common side. channels can be linked to topics in similar way discord topics were

But for Farcaster Frames on Common I would like to consult someone more FE expert on the complexity of following these instructions: https://docs.farcaster.xyz/reference/frames/spec#rendering-frames-1

Its a very straightforward process from my understanding but I feel like there is a decent amount of complexity in recreating the farcaster extended meta tags and displaying properly which is purely a rendering task(not sure how this is done in react). One note is that its basically just an extension of openProtocol not an openprotocol app itself, ie tag types are never supposed to be OG OP tags so the rendering is unique to farcaster.

I've been searching but havent been able to find any sort of tool to abstract the render so my conclusion atm is that we'd have to implement everything in the link above

Update/Edit: There's a key point I missed here which increases the complexity alot. Every time a button in a frame is clicked the client must send a frameMessage object that is properly signed by the custody of the FID. This would require us to implement the full farcaster signer flow in the first place which is difficult as mentioned above. A service like neynar doesnt cover this yet

[ianrowan]

Here is a breakdown/timeline of how I would think about timing and breaking up the work for all of this + Frames

1. Implement Sign in with Farcaster(preferably via neynar) 1 eng / 3 points
2. Implement first Frame on Common(polls or smthing??) 1 eng / 5 points
   • server side arch req for first ticket then 3 for rest probably using prior work
   • can be tasked parallel with 1
   • Continue implementing as team capacity allows @ 3 pts/frame
3. Farcaster bridge -> Common 1 eng / 5 pts
4. Common bridge -> Farcaster 1 eng / 3-5 pts
   • Order of list should be followed as 1 required for this
   • 3, 4 comprise the 'channel/topic bi-directional sync' but are two distinctly different systems
   • Can happen in parallel with 2 engs
5. Frames on common 8-13 pts ?

This is all assuming we dont reinvent the wheel and use a service like neynar for middleware. building our own signer creation and storage would add 8-13 pts before (1)

CC @dillchen @jnaviask

[dillchen]

This is all great I think we should basically just do this. for sure to rely on middleware, it fits into overall pattern we have in general.

Also @ianrowan recall @alexyoung23j's work on #4842 so technically we have 3 (but it's not event driven or anything fancy) so technically we are already have that.

[ianrowan]

We can't exactly use #4842 but the arch is there. Main difference is we were searching for mentions with that bot, whereas here we want to sync channels(in a hopefully event driven manner). So would basically be replacing all the farcaster stuff but keeping the rest of the bot

[ianrowan]

5. Frames on common 8-13 pts ?

This is all assuming we dont reinvent the wheel and use a service like neynar for middleware. building our own signer creation and storage would add 8-13 pts before (1)

from conversation and more research we found that neynar can derisk the frameAction/signing and reduce the scope of 5 down to sub 8 points for a POC probably.

Initial POC could use neynar guides https://docs.neynar.com/docs/how-to-embed-farcaster-frames-in-your-app-with-neynar to render and create frame actions. Looks something like: re front end complexity, i think our best approach would be to follow one of the Neymar api/frames and do a POC

1. render in the card
2. register button click (no signing / no worker)
3. and see what we can basically do, including button clicks
4. make notes on difficulty and see what we’d need to do to keep up with the standard

"What I have in mind for a render card is similar to CAT Cards

• We should try to create some kind of isolated handler
  • Handles render logic
  • And then because the input fields should be similar
    • Text Input etc
  • we just need to wire up the form submission and also the state update logic"

And this would be further de-risked and possible point reduced if resources who are familiar with openGraph rendering are available to work along side platform on this to create react components + learnings from 1-4 implementations used and applied