agusti 🐘 on Warpcast

Content pfp

0 reply

4 recasts

4 reactions

agusti 🐘 pfp

i feel sad to know @farcaster is going to basically heavily handicap if not outright kill /frames with the v2 spec. Frames without post buttons are probably as useful as the original OpenGraph metadata. if we strip interactivity from the primitve, what innovation is left worth pereserving in it ?

14 replies

4 recasts

21 reactions

Terry Bain pfp

No more post buttons? Honestly I don't know what they expect this place to be.

1 reply

0 recast

2 reactions

agusti 🐘 pfp

This was a technical commentary, in the context of frames a POST (http action verb) button, sends a call to a server (frames backend) and returns a new frame in response. That feature is going out of the window. new frames will have to either be an external link, a transaction/signature, or a mini-app modal link

3 replies

0 recast

8 reactions

max ↑🎩 pfp

@baseddesigner.eth

So it can still be the same thing only now every step must be a tx/signature Or you can open a mini app with any actions you want Tough one but gonna make it better in the end

1 reply

0 recast

2 reactions

agusti 🐘 pfp

Still not set in stone we’ll see soon hopefully a public discussion around it

1 reply

0 recast

1 reaction

Samuel pfp

@samuellhuber.eth

this is the first thing I see this morning, any idea on how the idea of disabling it came along instead of just asking devs to build more mini apps?

1 reply

0 recast

1 reaction

max ↑🎩 pfp

@baseddesigner.eth

could be in here https://warpcast.com/v/0x9b6f7a25

1 reply

0 recast

0 reaction

Samuel pfp

@samuellhuber.eth

yeah need to read through it still.

1 reply

0 recast

2 reactions

agusti 🐘 pfp

I don't get why they would announce the deprecation intent in 6 months or more. All i know is proxying frames images is a issue at scale and this seems to -fix- it by getting rid of the issue

1 reply

0 recast

1 reaction

agusti 🐘 pfp

I think the -easiest- thing to do would be keep supporting v1 forever, and push people to create v2 frames (because they should be better/easier) forcing it by rendering the work of so many people during almost a year useless, it's kinda not the way

1 reply

0 recast

2 reactions

Samuel pfp

@samuellhuber.eth

I think proxying frame images is good for speed but bad for devX since current frame libraries don't set the image cache control headers it seems to make them dynamic enough. (could be wrong on this, haven't double checked, but talking from project experience) though I agree V1 has value. Need to still properly read and write an opinion.

1 reply

0 recast

2 reactions

agusti 🐘 pfp

I actually do like the v2 spec, I only dislike the warning that v1 might be sunset in 6 months. Seems not based on reality of usage, but on wishes of the masters.

2 replies

0 recast

1 reaction

Samuel pfp

@samuellhuber.eth

my POV on that. as backend / infra guy I like V1. Claude is my UI machine so I am way faster with static images + POST and can enable / do more because of the data rounds on backend, though I enjoy the mix of both the most

1 reply

0 recast

1 reaction

agusti 🐘 pfp

I cannot imagine any react frontend ui mini app being faster than a a good frame 1 image vs thousands of deps bundled on an index.js 😁😭

1 reply

0 recast

1 reaction

Samuel pfp

@samuellhuber.eth

you are discounting network round trip time if the statemanagement on frontend is done well it can be very fast + have background pulling that the frame can't update the image with (not really, on mobile but MJPEG though)

0 reply

0 recast

2 reactions