Closed nakedfool closed 4 months ago
Yeah, looks like Frog uses state
under the hood but we would need it exposed in an API to be able to implement this workaround that was suggested by Farcaster. https://github.com/wevm/frog/blob/3fc8b5c892c7fdf822fb7795063d3da7988046f2/src/frog-base.tsx#L695
Adding relevant updates here as well:
post_url
limit is unlikely, so the path we're going after is to figure out how we can get around thatpreviousState
which is undefined
during the first tx initialization, though on the second initialization it is filledUpdate: we merged frames and got them to work here https://github.com/jk-labs-inc/jokerace/pull/1535, now just have the edge case documented in this comment below - https://github.com/wevm/frog/issues/239#issuecomment-2067767187!
Yeah, looks like Frog uses state under the hood but we would need it exposed in an API to be able to implement this workaround that was suggested by Farcaster.
@seanmc9, correct, and you can set initialState
in frog but not outside of the frog.
Farcaster increasing their post_url limit is unlikely, so the path we're going after is to figure out how we can get around that
@seanmc9, we can ask for this to be changed if we can word the motivation behind it properly!
We received a response that a way to do this is by using state here
@seanmc9, I think there was a little misinterpretation by @horsefacts, the issue is different, fc:frame:state
doesn't really help here.
The main issue is that post_url
has 256 bytes limit, and you sometimes need to set some initial data for the initial frame.
The solution sounds trivial – to add this initial data to path parameters, but as long as parameters are big in size, the end url exceeds 256 bytes limit.
There are two possible solutions with different amount of effort from different teams I see to resolve it:
post_url
limit which would be a temporary solution for this specific issue, but as soon as amount/size of arguments increases, a change would be needed to increase those again. (needs change from fc)What I mean by the latter, is that pasting addresses as path parameters seems trivial but some compressing serialization has to be applied to shorten the size of the data.
Assuming that the frame URL is generated somewhere on your FE when a user clicks on "share on wc" button, you'd have to put those parameters somewhere in the db (let's say redis), and put a single redis key as the path parameter. Then in the frame, you deserialize it by retrieving the value from redis.
that's not cool, but it's the only way I see such to be implemented.
@dalechyn Wow, thank you so much for this through response! This all makes sense and yeah, option 2 would be quite a bit of implementation vs if we could just even get the post_url
size doubled to 512 bytes we would be well in the clear for the forseeable future/the problem that we have isn't one we see scaling at all. We're currently working directly with @horsefacts to see if we can get this bumped!
Also re the initial frame, @nakedfool figured out a workaround in the PR we merged for frames https://github.com/jk-labs-inc/jokerace/pull/1535 where the first frame is effectively a loading one, and then we are able to get the dynamic post_url
to be sufficiently short in the subsequent frame.
We still have an edge case where sometimes for voting frames specifically, if the submission that is being voted on is too long, the url goes just above the limit and so that specific frame doesn't work, which is why we're still looking to get the limit raised. It would also allow us to not have to use the loading workaround with the initial frame and just have the initial frame contain the main logic too!
re asking for it to be bumped, this was the description and examples we gave:
This is an example of our voting frame where the post url is too long and so the frame doesn’t render correctly
https://warpcast.com/seanmc/0xe78b671b
And this is an example of our voting frame that is working correctly
https://warpcast.com/seanmc/0xcf59e8e0
It’s unfortunately a problem that is only happening for specific submissions that are sufficiently long and on chains with names that are longer, thereby pushing the post url just over the limit. But 512 bytes would be more than enough for this to solidly not be a problem.
What if you serialized the id here as hexadecimal number? Should save up some bytes
Yeah, we thought about that but it would either mean we couldn't use the direct link to the contest or proposal for the frame or it would be a pretty major refactor in our front and backend to use hex instead of integer for proposalId
. It also still might not be enough esp for chains that have longer names, like it still leaves us open for edge cases where the limit bump would very solidly cover all cases.
So if we can get a comprehensive fix for the current issue, still make it as easy as possible for people to share the frame, and avoid a major refactor, that's what we're most trying to prioritize with pushing for the limit to be raised.
Converting to discussion.
Describe the bug
Hi,
I'm currently experiencing an issue where i'm trying to deploy a frame with a
post_url
that has a one or more dynamic parameters in the URL. Current issue is, thatpost_url
is expecting it to be less than 256 bytesI was talking on discord today with one of the frog mods and they even casted on warpcast for asking a possible solution ( see here ), which seems to be to use state that allows up to 4096 bytes.
The last point here is, whether or not frog supports states. That is, how can we utilise frog to use dynamic parameters if the current limit for
post_url
is 256 bytes, and is there a plan of implementing this in the near future?Link to Minimal Reproducible Example
No response
Steps To Reproduce
No response
Frog Version
0.8.1
TypeScript Version
5.0.4
Check existing issues
Anything else?
No response