Skip to content

Instantly share code, notes, and snippets.

@vrypan
Last active March 12, 2024 04:28
Show Gist options
  • Save vrypan/e5a16042fb4a192a4356303f9680c5cf to your computer and use it in GitHub Desktop.
Save vrypan/e5a16042fb4a192a4356303f9680c5cf to your computer and use it in GitHub Desktop.
Proposal: Farcaster Frame-Domain association

Proposal: Farcaster Frame-Domain association

Goals

  1. Create an association between a Frame domain or URL and an fid that can be lazily verified.
  2. Minimize number of tools and network requests required to verify a domain association.
  3. Allow for future extensions to domain verification.

Proposal (no protocol change)

The idea is to provide a way for an FID to publicly declare that they trust a URL. The simplest way to achieve this is

  1. The FID cast "I trust URL" (embed or parent_url)
  2. The URL may include in its metadata the cast(fid, hash). This way any client that wants to verify that the URL is trusted by the specific FID, can use GetCast(fid, URL) to check that text=TRUST and parent_url=URL.

Proposal (protocol change)

  1. Introduce a new REACTION_TYPE_TRUST = 3
  2. The URL owner will have to submit a message MESSAGE_TYPE_REACTION_ADD with ReactionType=3 and target_url=<URL>.
  3. The URL can embed the FID in their metadata (or HTTP headers for non-html URLs)
  4. The app that wants to verify the relation can use GetReaction(fid, REACTION_TYPE_TRUST, URL).

Additional benefits:

  • An app can use GetReactionsByTarget(ReactionsByTargetRequest) to check if more than one fid trust this URL. This allows multiple FIDs to declare that they trust a URL (for example, a well-trusted FID whose purpose is to verify URLs.
  • It is easy to revoke the trust, by deleting the reaction.

Considerations

The major consideration for both approaches is that we also trust the signer of the messages. Apps may address this in more than one ways:

  • require an additional, well-trusted fid to send a trust declaration.
  • don't require, but leverage additional trust declarations by well-trusted fids, to display a "trust level" indicator.
  • trust a predefined list of signers (in which case, users would have to use one or two trusted clients to cast trust).

Thoughs on implementation

For both proposals: Clients may decide to do a lazy implementation (query hubs every time), but can also listen to hub events and update their local db with trust announcements and revocations.

@vrypan
Copy link
Author

vrypan commented Mar 1, 2024

An important issue with this approach is that casts/reactions may be pruned. Which can be seen as both a problem (trust will be removed) but also as a way to make sure that trust declarations expire.

@vrypan
Copy link
Author

vrypan commented Mar 12, 2024

Worth pointing out that this is a N:1 association (multiple FIDs may declare they trust a domain) compared to the 1:1 association described in https://www.notion.so/warpcast/Frame-Domain-Associations-Public-efcb07871f0c42b4ae6ace62acce64e4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment