Content
@
0 reply
0 recast
0 reaction
df
@df
Gonna re share this because I want to see it happen The interface between the Frame and the client is currently spec'd to be very limited. I think there is an opportunity to open this interface up to also providing "developer legos" by allowing the Frames in v2 to call an action that opens a limited version of Frames v1 (frames v1 without the "POST" action, so it's only 1 step frames). This allows third party programmability at this permissions layer between Frames and Client, enabling Frames to interact with eachother. As it stands, Frames v2 have no way to interface with each other, or any of the existing developer legos via a trusted context. The trickiest part of implementing Frames v1 for clients was the complexity and performance of state transitions between frames. By limiting Frames v1 to "one step Frames", you get the safe composability without adding much complexity. https://github.com/farcasterxyz/protocol/discussions/205#discussioncomment-11498632
3 replies
0 recast
22 reactions
Tony D’Addeo
@deodad
I don't understand, could you give a more concrete example of how the spec changes?
1 reply
0 recast
0 reaction
df
@df
const frameAction = await sdk.actions.promptFramesV1(“https://events.xyz/events/386b41eb”) -> client shows the one step frame to rsvp to an event. *user presses rsvp button* -> client resolves frameAction with a response payload from the events.xyz response similar flow can be used for subscribing to a paragraph blog from any other frames v2. What this unlocks: apps can now expose legos + composability that framesv2 apps can leverage via farcaster signatures
0 reply
0 recast
0 reaction
