Content
@
0 reply
0 recast
0 reaction
horsefacts
@horsefacts.eth
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
13 replies
9 recasts
112 reactions
vrypan |--o--|
@vrypan.eth
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? :-)
2 replies
0 recast
2 reactions
treethought
@treethought.eth
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
1 reply
0 recast
1 reaction
vrypan |--o--|
@vrypan.eth
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.
2 replies
0 recast
0 reaction
treethought
@treethought.eth
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
0 reply
0 recast
1 reaction
