Varun Srinivasan on Warpcast

Content pfp

0 reply

4 recasts

4 reactions

Varun Srinivasan pfp

Varun Srinivasan

Frame Redirect Design: Redirect vs Payload We're considering two different approaches for implementing the redirects. Devs, which do you prefer and why? https://warpcast.notion.site/Frame-Redirect-Response-vs-Payload-da2bb0e4212a4664ade8d38751e416f7?pvs=4

22 replies

22 recasts

90 reactions

Varun Srinivasan pfp

Varun Srinivasan

If it wasn't clear in the above posts, the two options are contrasted here: https://warpcast.notion.site/Frame-Redirect-Response-vs-Payload-da2bb0e4212a4664ade8d38751e416f7

0 reply

0 recast

3 reactions

df pfp

The response option is more flexible to allow changing redirect url paths/domains based on payload - apps may fix this with a client side redirect like many banking 2FA portals do; horrendous urls with massively long query params. But payload allows an app to verify the domain at index time to make sure its safe

0 reply

0 recast

1 reaction

Zinger ↑ pfp

Payload seems more straightforward and as you mentioned should be generally snappier and better UX Best argument I can think of for response is that the payload data can get stale versus the response data which is generated at the time that the action is taken

0 reply

0 recast

1 reaction

Stephan pfp

response more flexible, server can decide to send signature as query params or handle differently

0 reply

0 recast

0 reaction

christopher pfp

ooh, tough choice. i *think* my preference is the first. cleaner UX experience, but we could do more with the second.

0 reply

0 recast

0 reaction

0xpotus (🔵, 🎩) pfp

0xpotus (🔵, 🎩)

Redirect has the potential to be misused - especially once scammers start to lurk around. I prefer payload to contain everything within the confines of Warpcast. It is limiting but I prefer peace of mind.

1 reply

0 recast

0 reaction

bchow pfp

Could you support both? Seems like there are benefits to both options Response: Feels more ergonomic, just works Payload: 1 less round trip It doesn't seem like there is collision between the two approaches although it might be a bit confusing from a developer's perspective

1 reply

0 recast

0 reaction

bark bark pfp

Response strategy seems favorable. With payload there's no room for new features (considering the URL limit) in the future and there's not much control over the action by the Frame host. Response strategy offers both flexibility on the limits and the redirect signature can be handled by the frame.

2 replies

0 recast

0 reaction

Vadim 🎩 @ ETHCC Brussel pfp

Vadim 🎩 @ ETHCC Brussel

Redirect feels more lucrative because you can have code executed before the redirect, that would not be possible if you do payload for external website.

1 reply

0 recast

0 reaction

Tiago pfp

@alvesjtiago.eth

response option due to the url limitations on the payload option

1 reply

0 recast

1 reaction

Joe Petrich 🟪 pfp

Joe Petrich 🟪

Payload for the UX. The pop out to the URL will feel faster even if the webserver has to do its own redirect based on the signature. For multi-step frames, the URL can already be contextual based on a previous button event. Single step frames would need to handle the query parameter to use context. Fine trade-off imo.

0 reply

0 recast

2 reactions

Colin pfp

@v what exactly needs to be returned when a user clicks on a redirect button? A 302 response containing just the URL as plaintext? It's not clear to me from the docs

1 reply

0 recast

1 reaction

borodutch pfp

@warpcastadmin.eth

to achieve some extra growth if you want to cross with tg, you'll need to add ?start={Sig} to t.me links of bots :) so, crafting queries can be a powerful thing

0 reply

0 recast

1 reaction

W1NTΞR pfp

Unpopular opinion: why not both? - for simple use cases where auth doesn't matter, offer a <meta property="fc:frame:button:1:redirect" content="http://…"> - for cases where auth does matter, do POST request roundtrip with 302 redirect The client UI can show the buttons differently

0 reply

0 recast

0 reaction

Stephen Caudill pfp

Stephen Caudill

Viewed strictly from the POV of preserving optionality, the response pattern seems preferable. Payload is inherently limited by space and can become stale sitting on client. Biggest drawback to response IMO is the extra call and TBH I find that an easy optimization to wrangle.

0 reply

0 recast

0 reaction

Sinaver pfp

Why not support both depending on whether you need a signature or not to construct a redirect/action url?

0 reply

0 recast

0 reaction

vrypan |--o--| pfp

Why does the post_redirect option has to be on the same domain and not directly where it has to go? It's then up to the dev to decide if the target URL will show the content, redirect, etc.

1 reply

0 recast

0 reaction

Linda Xie pfp

1 reply

0 recast

0 reaction

frolic pfp

You could do the payload approach with a form target and avoid the query string limit issues: <form method="post" action="{url}" target="_blank"> <input type="hidden" name="signature" value="..." /> <button type="submit">{label}</button> </form>

1 reply

0 recast

0 reaction