Post URL 256 bytes limit

[nakedfool]

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, that post_url is expecting it to be less than 256 bytes

I 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

• I checked there isn't already an issue for the bug I encountered.

Anything else?

No response

[siobh9]

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.

frog/src/frog-base.tsx

Line 695 in 3fc8b5c

<meta property="fc:frame:state" content={nextFrameStateMeta} />

[siobh9]

Adding relevant updates here as well:

• 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
• We received a response that a way to do this is by using state here
• We've received differing info on whether state derivation is how one can do this through Frog - on Discord we were told that it wouldn't work but we were linked to Frog documentation here saying that state derivation is how one gets around this limitation with Frog
• We have tried state derivation but are getting nothing back, so for what we've tried so far at least we haven't been able to get it to work
  • Specifically: We're not sure if there is a way to access to the current state, as we can only access previousState which is undefined during the first tx initialization, though on the second initialization it is filled

Update: we merged frames and got them to work here jk-labs-inc/jokerace#1535, now just have the edge case documented in this comment below - #239 (comment)!

[dalechyn]

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:

1. Increase 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)
2. Implement tricky serialization/deserialization techniques.

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.

[siobh9]

@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!

[siobh9]

Also re the initial frame, @nakedfool figured out a workaround in the PR we merged for frames jk-labs-inc/jokerace#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.

---

[dalechyn]

https://warpcast.com/seanmc/0xcf59e8e0

What if you serialized the id here as hexadecimal number? Should save up some bytes

[siobh9]

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.

[tmm]

Converting to discussion.