Farcaster Devs

Handling all Frame redirects by returning 302s is a bit of a pain. We are considering simplifying the design. If you have feedback or suggestions on simplifying redirects, I'd love to hear them!

One obvious addition is a simple "external link" button with no server round trip. What else could be better?

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

terminally.online

I still don't understand why the post_redirect does not happen in the browser, and you need an intermediate step. (Isn't there a browser equiv of curl -X POST?)

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

Building @warpcast and @farcaster, new dad, like making food

OK, this makes sense. No idea how iOS/Android APIs handle these things, this is what I was missing.

Trivial in browser but not in native environments where you have to use native APIs to open a browser from a an app

probably some way to do it if you open a page that then submits the post but unexplored

My question is: Why should WC do the POST (in post_redirect) and not the browser directly? If the response is a 302 the browser will follow it. If it's a 200 it will show it. It's up to the server that receives the POST to decide what to do.

The biggest benefit is that the server can check for new data in the frame message and determine where to redirect. So if you want a dynamic redirect, use a 302, if you want a static redirect, we'll probably define a separate tag.