search

ethereum-optimism / ecosystem-contributions

Find ways to contribute to the Optimism Collective
MIT License
310 stars 121 forks source link

Foundation Mission Request - Farcaster Attestations [IDENTITY] #194

Open opjulian opened 5 months ago

opjulian commented 5 months ago

Proposed Foundation Mission Request: Enable easy interoperation between Farcaster accounts and Ethereum Attestation Service, such that Farcaster accounts can effectively ‘issue’ attestations.

S5 Intent: Improve governance accessibility

Proposal Tier Ember

Baseline grant amount: 10k OP per solution for up to 2 solutions

Should this Foundation Mission be fulfilled by one or multiple teams: Up to two teams

*OP Labs or Optimism Foundation Sponsor: @C-Emily-Furlong

Submit by: June 15th 2024

Selection by: June 30th 2024

Start date: June 30th 2024

Completion date: by August 30th 2024

How will this Foundation Mission Request help accomplish the above Intent?

This Mission Request calls for critical infrastructure enabling better compatibility between EAS Attestations and Farcaster accounts. Attestations are a critical piece of governance infrastructure and a core primitive of the OP Stack and will continue to remain a key building block of reputation within the Collective.

This Mission will enable the Collective to leverage Farcaster to improve governance accessibility while maintaining attestation compatibility and composability.

What is required to execute this Foundation Mission Request?

Problem statement

We want Farcaster accounts to more effectively and efficiently ‘issue’ attestations. Farcaster accounts have several connected Ethereum addresses. [Custody and recovery addresses](https://docs.farcaster.xyz/reference/contracts/reference/id-registry) are verifiable on-chain via the Id registry contracts and so-called ‘[verified addresses’ are only verifiable off-chain](https://docs.farcaster.xyz/reference/hubble/httpapi/verification). These address mappings can be changed over time by the user.

The holder of a Farcaster account may issue an attestation from one of the Ethereum addresses connected to their account, but for third parties to be sure that an attestation was issued by the person behind a Farcaster account, the Ethereum address must be connected to that account at the point in time that the attestation was issued. This connection must be verifiable on-chain for resolver contracts to be able to enforce it in the process of issuing attestations. Only custody and recovery addresses are verifiable on-chain, but users rarely have access to them to sign messages like attestations.

Use case

In the [Retroactive Public Goods Funding (Retro Funding) Round 4 sign-up experience](https://retrofunding.optimism.io/), users sign in with their Farcaster accounts, create projects and apply for Retro Funding. Projects are represented onchain as attestations, with the attestation UID acting as the project identifier to be used across future Retro Funding Rounds and Grant applications. The project attestation schema contains a ‘created by’ field, which references the Farcaster account id of the user who created the project.

Currently the attestation is issued by the sign-up app and attestation consumers must trust that the app correctly identified the user by their Farcaster id. The desired outcome is that users themselves are able to issue this project attestation, as well as other attestations about their projects, and third parties can read those attestations and trust that the project was indeed created by the holder of the Farcaster account. Third parties can further reference these attestations to add context to the impact of these projects and much more.

Suggested avenues to explore

In our exploration of this problem space, we have come across two ideas for solution avenues, which we think offer different trade-offs and would both be valuable additions to the EAS <> Farcaster tool set. It is up to the teams applying for this Mission to assess the viability of these ideas and suggest an appropriate technical architecture in their application. Alternative ideas for how to solve this problem are welcome.

Teams can apply to build one or multiple solutions, including suggesting solution ideas that are not listed below. The OP reward will be adjusted depending on the scope of the solution(s) proposed by teams.

Avenue 1

Solution requirements avenue 1

Avenue 2

Solution requirements avenue 2

Definition of done

How should the Foundation measure progress toward this Mission Request?

  1. Develop a plan and document it as an architecture diagram to be shared with the sponsor for feedback (1 week)
  2. Develop a prototype / testable solution (2 weeks)
  3. Release a production-grade solution that complies with the definition of done and applicable solution requirements above (4 weeks)

How should badgeholders measure impact upon completion of this Mission (RFP)?

Application instructions

To apply for this RFP, please complete the form in the expandable section below and leave your response as a comment on this issue thread. Submissions will be open until June 15, at which time the Foundation will review all submissions and select one or two individuals/teams to complete the work defined here.

Submission form _Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary._ ## Foundation Mission (RFP) Application **Please verify that you meet the qualifications for submitting at the above [Tier](https://gov.optimism.io/t/collective-trust-tiers/5877/2)** * **Alliance Lead:** Please specify the best point of contact for your team * **Contact info:** * **L2 recipient address:** * **Please list the members of your Alliance and link to any previous work:** Read more about Alliances [here](https://gov.optimism.io/t/season-4-alliance-guide/5873) --- **What makes your Alliance best-suited to execute this Mission?** - [...] - [...] **Please describe your proposed solution based on the above Solution Criteria (if applicable):** - [...] - [...] **Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:** - [...] - [...] **Please define the [critical milestone(s)](https://gov.optimism.io/t/grant-policies/5833) that should be used to determine whether you’ve executed on this proposal:** - [...] - [...] **Please list any additional support your team would require to execute this mission (financial, technical, etc.):** - [...] - [...] **Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:** _(Note: there is no guarantee that approved Missions will receive up-front cash grants.)_ - [...] --- Please check the following to make sure you understand the terms of the Optimism Foundation RFP program: - [ ] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance. - [ ] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant - [ ] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types) - [ ] I confirm that I have read and understand the [grant policies](https://gov.optimism.io/t/token-house-grant-policies/5833) - [ ] I understand that I will be expected to following the public grant reporting requirements outlined [here](https://gov.optimism.io/t/suggested-public-reporting-requirements-for-grantees/4176) -- end of application --
tambora07 commented 5 months ago

Bravo farcaster

0xprames commented 5 months ago

👀

tambora07 commented 5 months ago

Github connect farcaster

Chomtana commented 5 months ago

Foundation Mission (RFP) Application

Please verify that you meet the qualifications for submitting at the above Tier

This is a collaboration between RetroList and Opti.Domains team

RetroList has received 49k OP in RetroPGF 3

Opti.Domains has received 22k OP in RetroPGF 3

Chomtana Chanjaraswichai - Team Lead, Core Developer

Johnny Phan - Protocol Engineer - Reviewing the feasibility of the solution and developing the backend integration

Poonpetch - UX / UI Designer - Design workflow and user experience

Chinapanda - Frontend Developer

Read more about Alliances here

What makes your Alliance best-suited to execute this Mission?**

We have built RetroList, the first and only Retro Funding 4 Discovery UI available so far. Our platform queries and indexes project data directly from the EAS, while others are still waiting for the Agora API to integrate real data. This showcases our expertise in EAS Attestation and have got retweets from Optimism.

Image

Moreover, we have years of experience in the identity field, demonstrated through the development of Opti.Domains, which integrates social verification with EAS attestation. To date, we have completed over 10,000 attestations related to social and wallet verification linked to domains.

In the domain attestation, we use namehash as the primary identifier, similar to how Farcaster uses Farcaster ID for attestations. We have experience with this non-address-centric attestation system.

Furthermore, as a leading team developing Retro Funding discovery and community voting UI, we already have a high level of understanding of how this Farcaster attestation system can be used. This expertise enables us to cooperate more effectively with the Agora and Gitcoin teams.

Please describe your proposed solution based on the above Solution Criteria (if applicable):**

We are looking to develop Avenue 1 solution

Image

Attesting offchain farcaster wallet verification onchain

We will implement a system that queries off-chain wallet verification from the Hubble API and attests it on-chain through EAS with a resolver that automatically saves and indexes the Farcaster wallet verification status. This enables other contracts, applications, and resolvers to query this data to check if a Farcaster wallet has been verified.

Thanks to the OP Fjord upgrade, which implements "RIP-7212: Precompile for secp256r1 Curve Support," we can verify the Farcaster ED25519 signature on-chain.

We will provide an SDK and Wagmi hook for third-party applications to implement Farcaster attestation. This allows applications to check for wallet verification status and handle wallet verification attestation, so developers do not need to understand the underlying logic and can implement it easily.

Automated wallet verification attestation

We will provide an automated wallet verification attestation. Every time a wallet is verified, we will attest to the Farcaster wallet verification schema. Every time a wallet is revoked, we will revoke the on-chain attestation.

In case the automated wallet verification attestation isn't working, the SDK will automatically handle the situation by letting the user attest the wallet verification manually. The user experience will be similar to token approval, where the user needs to attest to the Farcaster-wallet connection once globally.

Attesting Farcaster Attestation

We will provide core contracts with examples for smart contract developers to easily develop and integrate Farcaster attestation resolvers. These resolvers will verify the Farcaster wallet connection before allowing the attestation to proceed.

Simple attestations that follow our recommended attestation standard can simply set our pre-deployed resolver as the default resolver while creating a schema.

Our SDK allows developers to build Farcaster attestation data with just a few lines of code. Additionally, it supports a Wagmi hook that enables developers to perform attestations with Farcaster in a streamlined manner.

We will also support or collaborate with Agora, Gitcoin, RetroList, and any team working on Farcaster attestations for Retro Funding use cases.

Recommended Attestation Standard

We recommend the following standard for Farcaster attestations to make them more useful and better organized.

NOTE: THIS IS OPTIONAL, OUR SOLUTION CAN WORK WITH ANY SCHEMA

Farcaster Recipient Namespace

Currently, the Retro Funding application attestation is not attested to a recipient. This prevents standard attestation indexers from efficiently indexing the attestation. For example, we can't easily query the EAS GraphQL API to find every project attested by @optidomains. Moreover, integration with guild.xyz is more difficult.

To address this, we introduce the address 0xfa...<Farcaster ID in hex> as a representative of the Farcaster account to be used as the recipient.

However, this is optional, and application developers can choose not to follow it if needed.

Farcaster ID as the First Field

The Farcaster ID should be the first field for seamless integration with our Farcaster attestation resolver SDK and for optimal indexing. However, if the Farcaster ID cannot be the first field, developers can manually decode the Farcaster ID and pass it to our Farcaster attestation resolver SDK during resolver development.

Developer Support Channel

We will host a developer support channel similar to the "Optimism Agora API beta" channel.

We will provide technical resources to TechNerd for answering Farcaster attestation-related questions on the developer forum and Discord. As a fellow TechNerd, I can easily coordinate with the rest of the TechNerd team.

Guild.xyz Support

We will coordinate and collaborate with Guild.xyz to implement support for Farcaster attestation. However, we can't guarantee success in this effort, and it is not a critical requirement, so we don't include it in the critical milestones.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:**

Critical teams are those that work on missions dependent on Farcaster attestation, including but not limited to the Retro Funding application and the voting UI development team.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:**

Please list any additional support your team would require to execute this mission (financial, technical, etc.):**

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:** (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Not a problem

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

-- end of application --

lukema95 commented 5 months ago

Foundation Mission (RFP) Application

Please verify that you meet the qualifications for submitting at the above Tier

What makes your Alliance best-suited to execute this Mission?

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We choose [Solution requirement avenue 1], users can issue Attestations through their own Ethereum account (EOA/ Smart Account)

Here are the main key components：

Some Preliminary Ideas

The main processing flow is as follows:

  1. Farcaster users or applications call the SDK(or HTTP API Service) to register Ethereum address.

    • If users already have a wallet, they can use it to sign transactions and then call the SDK or HTTP service to send the transaction.
    • If users do not have a wallet, they can call the SDK to first generate a wallet, then sign and send the transaction. image

  2. The process for Farcaster users who have already registered an Ethereum wallet to publish Attestations.

    image

Key Design of Smart Contracts:

The following represents a conceptual design for the key contract and does not represent the final solution

Schema In the schema, the fid is used as the first field to identify the Farcaster account, while other fields can be customized according to business scenarios.

// General
schema {
    fid: uint256 // farcaster id
    // others field
    // ...
}

// Retro Funding 4
schema {
    fid: uint256 // farcaster id
    project_name: string
    project_url: string
    parent_project_ref_uid: uint256
}

Resolver Since the user's signature has already been validated in earlier steps, the Resolver only needs to check if the user's Fid matches the wallet's binding relationship.

contract ForcasterResolver is SchemaResolver {
    // ...
    IIdRegistry idRegistry; // farcaster IdRegistry
    function onAttest(Attestation calldata attestation, uint256 value) internal view override returns (bool) {
        uint256 fid = idRegistry.idOf(attestation.attester);
        require(fid != 0, "Fid does not exist");
        // decode fid from data
        uint256 _fid = abi.decode(attestation.data, （uint256）);
          require(fid == _fid, "Does not match fid");
    }
}

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

Week 1: Preparation (30/06/2024 - 06/07/2024)

Weeks 2 - 5: Code development (07/07/2024 - 03/08/2024)

Weeks 6 - 7: Test & Docs (04/08/2024 - 10/08/2024)

Week 8: Acceptance and feedback (11/08/2024 - 17/08/2024)

Please define the [critical milestone(s)](https://gov.optimism.io/t/grant-policies/5833) that should be used to determine whether you’ve executed on this proposal:

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Not required

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

lukema95 commented 5 months ago

Foundation Mission (RFP) Application

Please verify that you meet the qualifications for submitting at the above Tier

What makes your Alliance best-suited to execute this Mission?

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We are looking to develop [Solution requirement avenue 2] which encompasses two key processes:

Key Components

Farcaster Login UI Component

We will develop a UI component for applications to log in to Farcaster accounts, which will be integrated into ReactJS and NextJS. This integration will allow applications to swiftly incorporate it into their frontend interfaces.

Farcaster/EAS Interaction SDK

We will develop a comprehensive TypeScript SDK for both frontend and backend use, which will later be expanded to other languages like Go and Rust. Its primary functionalities include registering application-side keys for Farcaster users, interacting with the EAS contract to issue proofs, creating schemas, and verifying users' proofs.

Schema Template Contract

We plan to develop a set of schema templates and instances suitable for issuing Farcaster proofs. The schema must contain the Farcaster user's fid and essential fields like the Farcaster account's Key. Here is an example:

// Retro Funding 4
schema {
    fid: uint256 // farcaster id
    key: string // key
    project_name: string
    project_url: string
    parent_project_ref_uid: uint256
}

Resolver Verification Contract

The Resolver contract is used to verify the validity of the attestation, ensuring they are authorized by legitimate Farcaster accounts. Since the attestation has already been verified as signed by a specific Farcaster account key, the Resolver only needs to confirm that this key matches the existing Farcaster account. Below is an implementation example.

contract ForcasterResolver is SchemaResolver {
    // ...
    KeyRegistry keyRegistry; // farcaster keyRegistry
    function onAttest(Attestation calldata attestation, uint256 value) internal view override returns (bool) {
        // decode fid from data
        (uint256 _fid, bytes key) = abi.decode(attestation.data, （uint256, bytes）);
        uint256 fid = keyRegister.keyDataOf(_fid, key);
        require(fid == _fid, "Does not match fid");   
    }
}

Comprehensive Developer Documentation

We will provide complete developer documentation and examples to enable developers to quickly integrate the attestation system into their applications. Week 1: Preparation (30/06/2024 - 06/07/2024)

Weeks 2 - 5: Code development (07/07/2024 - 03/08/2024)

Weeks 6 - 7: Test & Docs (04/08/2024 - 10/08/2024)

Week 8: Acceptance and feedback (11/08/2024 - 17/08/2024)

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Not required

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

-- end of application --

Rainbow1nTheDark commented 5 months ago

Foundation Mission (RFP) Application

Please verify that you meet the qualifications for submitting at the above Tier

Marwan Aziz - Core engineer with 30+ years of web2 experience and several years of web3 experience:

Alexander Balandin - Full-Stack Engineer, ex Microsoft engineer with 7 years experience in IT and 2 years in Web3 development:

What makes your Alliance best-suited to execute this Mission?

Our team possesses extensive experience both as creators and consumers in the Web3 space. Our mission is to make Web3 more accessible and user-friendly for newcomers. We believe that enhancing the infrastructure for better compatibility between EAS Attestations and Farcaster accounts will significantly open the protocol for further development, fostering innovation on top of our solution.

As part of our expertise, we have worked extensively with EAS. For our final project in the Expert Solidity course, we built a decentralized application (Dapp) designed for users to rate and review other decentralized applications - Optimist. This project aimed to foster a community-driven reputation system, helping users make informed decisions about which Dapps to trust and use.

We are inspired by Chris Dixon's vision for decentralized social applications and have a deep understanding of Farcaster's mission and we are eager to contribute to its success.

Additionally, we are senior software developers with extensive experience in architecture and development. We believe our skills and dedication make us well-suited to contribute to this project and advance the Web3 ecosystem.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We are looking to develop Avenue 2 solution

Solution Proposal

Our solution involves building an application through which users interact with Farcaster contracts. The following outlines our approach:

User Interaction and Authentication

Fetching Farcaster ID

Account Key Management

Attestation Process

Verification by Third Parties

This approach ensures secure and verifiable attestations, enhancing trust and usability within the Farcaster ecosystem.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Step 1: Preparation (2024-06-30 - 2024-07-05)

Step 2: Development (2024-07-06 - 2024-07-31)

Step 3: Testing and Documentation (2024-08-01 - 2024-08-31)

Step 4: Support (Starting 2024-09-01 and Ongoing)

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

nathansvan commented 5 months ago

Foundation Mission (RFP) Application

Why us? We're already building the solution on the Superchain.

Our team has already shipped tools for Farcaster-native EAS attestations with the goal of benefiting the entire Superchain ecosystem.

Open to the Public (OTTP) is an open collaboration protocol built on Base. It enables any person or organization to attest to any and all collaborations (work) onchain.

Farcaster and EAS:

Farcaster Frames:

OTTP SDK:

Basic Web Client:

Backdrop Build V3 and V4 Finalists:

Gitcoin Grants 20:

Proposed solution:

Key Components:

The RFP goal is to provide assurances that the wallet issuing the EAS attestation for a project page is connected to a given Farcaster ID. We’re doing this and more.

We would like to see a world where a project attestation is not only verifiably linked to social profiles (like Farcaster and Lens) but also grants they have received from Gitcoin, Optimism, hackathons, accelerators, etc.

And even further, we want to enable use of the same project page across multiple clients, such as Gitcoin and Optimism.

ottp-diagram

We are building OTTP for everyone on the Superchain and for many use cases related to collaboration. But in the use case described in the RFP, project attestations created by a user (or an organization) would be linked to their OTTP ID and connected to any social accounts, previous projects or contributions. A project page could be repurposed anywhere and connected to anything else on the open protocol. Anything related to work/collaboration that can be proven onchain, provably connected together through the OTTP ID into a collaboration graph.

For this RFP, we will focus our efforts on strengthening the connection between Farcaster accounts and EAS attestations, including validation at the contract level.

Detailed Flow:

  1. Sign in:
    • The user signs in to the app with their Ethereum address, which is connected to their OTTP ID.
  2. Link Farcaster Account:
    • The user indicates they want to link their Farcaster account with OTTP.
  3. Generate Signature in Farcaster:
    • The app directs the user to a secure location within Farcaster where they can generate a signature using their Farcaster custody address. Note: This can be done through a secure frame within the Farcaster interface.
    • Steps in Farcaster:
      • The user generates a signature using their Farcaster custody address.
      • Farcaster provides a text string containing the signature.
      • The user copies this text string.
  4. Return to the App:
    • The user navigates back to the app.
    • The app prompts the user to input the copied text (signature).
  5. Verification:
    • The app verifies the signature: It checks that the signature was generated by the custody address associated with the Farcaster ID.
    • Once verified, the app creates an onchain attestation linking the Farcaster account to the user's Ethereum address.
  6. Create a Record:
    • The app initiates a transaction to record this attestation onchain.
    • The attestation may include an expiration date, allowing the wallet to continue making attestations using a resolver contract with the linked Farcaster address.
  7. Session and Ongoing Verification:
    • The smart contract creates a session for the user, allowing them to make further calls without needing reverification for a set period.
    • During this session, the contract continuously verifies that the address making calls is still associated with the Farcaster ID.

View overall OTTP user flow

Step-by-step plan and expected deadlines:

Notes:

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None required but would be helpful:

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

None.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

-- end of application --

jmacwhyte commented 5 months ago

@lukema95 @Rainbow1nTheDark @nathansvan @Chomtana

The team at Lighthouse (lighthouse.cx) are very interested in this request as something we would like to implement in our product. We don't have enough resources at the moment to submit our own application for the grant, but we would like to offer to work together with the other teams to build a real-world implementation of their proposed solutions:

C-Emily-Furlong commented 5 months ago

Thank you to all the builders who submitted applications for this project! @Chomtana 's alliance has been selected to carry out this Mission Request.

@Chomtana I will be in touch directly with further instructions

For all the other builders, thanks so much for taking the time to apply 🙏 you can find other ways to get involved via contribute.optimism.io

We also have another open mission request related to attestations here

zacharytyhacz commented 5 months ago

This is lit

Maxservais commented 3 months ago

Hey everyone,

I have spent some time looking at the second solution and here are some of my thoughts:

Goal

First, let me restate the goal as I understood it: allow Connected apps to issue on-chain attestations on behalf of their users, verifiably linking these attestations to their users' Farcaster identities.

When an attestation is issued, it must adhere to the attestation schema. This attestation schema can reference a resolver contract that basically would check if the signature corresponds to a valid account key for the specified Farcaster ID against the Farcaster key registry.

This is basically good because everyone can then trust that an attestation issued by app XXX on behalf of user YYY is actually 'valid' because the app had been granted permission from the user to act on their behalf.

Solution

In terms of Solution (and challenges), this is how I view it:

Step 1: Issuing attestations

A connected app can request an app key from a wallet app (warpcast) - it's called the Farcaster Signer Request process if I am not mistaken.

Each connected app basically generates an Ed25519 key pair which is then approved for use with the user's Farcaster account. This key pair is distinct from the user's main/custody Farcaster wallet.

Theoretically, this key pair could be used for other purposes beyond just posting offchain messages on Farcaster. This flow is described here in the doc: https://docs.farcaster.xyz/reference/warpcast/signer-requests

I believe this was originally designed to allow Connected Apps (e.g. Supercast/Yup/etc) to take offchain actions on Farcaster like writing casts, following accounts and browsing. But I don't think it prevents them from actually doing other stuff (like issuing an attestation, minting an NFT, etc) on behalf of their users. I guess it just needs to be made very clear to the user what the connected app will do on their behalf.

The biggest challenges I see here are:

Step 2: On-chain verification

To verify the link between the attestation and the Farcaster identity of a user, we need a resolver contract.

This contract would need to verify the Farcaster key against the on-chain Key Registry.

The big challenge here is that Querying the Key Registry is extremely gas-intensive. The Farcaster documentation explicitly warns against calling it on-chain from other contracts due to potential block gas limit issues.

Image

Each time the resolver contract is called, it would need to check with the key registry (1) the Farcaster ed25519 signature against the account keys for the farcaster ID of the user on behalf of which the attestation was issued AND (2) the status of the key (whether it's revoked or not).

(1) is apparently possible thanks to the latest OP Fjord upgrade. The challenge is still that the resolver contract needs to interact with the Key Registry for each verification and this might be prohibitively expensive in terms of gas. And moving the check offchain isn't easy because we still need a way for the resolver contract to call that offchain "verification" service.

I'd really appreciate any thoughts or suggestions on how we might address these challenges or explore different approaches.

Cheers, Maxime