Proposal: Farcaster Frame-Domain association

fc-frame-domain-association-proposal.md

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.

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.

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