Farcaster Devs

Proposal to allow frames to pass small amounts of application defined state to the frame server. (4kb, same as a browser cookie). Will be working on this one this week!

(cc @df, inspired in part by framesJS passing data in frame URLs)

Building FOSS via @frames, /open-frames to help decentralized social win. a16z CSX23. farcasterchannels.com farcaster.id

Proposal to allow frames to pass small amounts of application defined state to the frame server. (4kb, same as a browser cookie). Will be working on this one this week!

(cc @df, inspired in part by framesJS passing data in frame URLs)

https://warpcast.notion.site/Frames-State-Public-f3de69c1d12944e583a37204c98d25d9

I'm eth newbie..just learning
(working on @farcaster)

terminally.online

Here is my concern: The state is sent from the server to the client, so that the client sends it back to the server. So, the server could save the state and just pass a sessionId (which is much simpler for the client). But if this is the case, the sessionId is easy to embed in a URL, so why? :-)

Dad, geek, conversation liquidity provider. vrypan.net (home), /weatherxm (work), @l--o--l (fun). Also https://paragraph.xyz/@purplesubmarine

initially i agree with this. The server would already have this info and can associate with a session id from the url. And the client would not be updating the state aside from the normal payload sent to the server. But I guess this would simplify state/cache handling for frame devs quite a bit

decentralist, turtle stacker, /livecoding cycle carpenter -- building /tofui

definitely think that makes sense. plus the benefits this would provides could just be abstracted away on client side within a frame dev framework using something like session key

Yes, and @horsefacts.eth is on the same page with you. But a farcaster client is already a complex thing to build. Every little bit we add makes it a bit more difficult to have a good second one. I think we should be more conservative to adding spec requirements.