Content
@
0 reply
0 recast
0 reaction
Tony D’Addeo
@deodad
Frames v2 Highlights: Domain Associations 👷 ↔️ 🌐 problem: trusting a frame context: it's important for users to understand who they're interacting with when using a frame so they can make informed decisions like whether to approve a transaction requested by the frame. v1: the frame was identified by a domain just like how a website is identified when browsing the web. This was ok but not great—for well known sites like zora.co this works but for devs building without an established brand it's fairly useless. v2: an account can create a public association between itself and a domain. This let's frames be presented to users with a clear and strong signal of which Farcaster account built it. It also means the frame can provide a name (in v1 this was a bad idea since it's leads to phishing attacks).
3 replies
16 recasts
50 reactions
rish
@rish
yeah have always wanted a creator fid association! where is this association stored?
2 replies
0 recast
2 reactions
Tony D’Addeo
@deodad
this probably could've been it's own FIP but frames v2 introduces /.well-known/farcaster.json that includes the Domain Account Association https://github.com/farcasterxyz/protocol/discussions/205#domain-account-association
2 replies
0 recast
1 reaction
christopher
@christopher
Would have really preferred we use DNSSEC, but I get why a JSON file is better for growth.
1 reply
0 recast
1 reaction
Tony D’Addeo
@deodad
why?
1 reply
0 recast
0 reaction
christopher
@christopher
The JSON is not proving the domain authority, it’s only proving the app. For example any app deployed to vercel proves it’s a vercel app but is it the authority over vercel.com?
1 reply
0 recast
1 reaction
