Support for Open Frames

[nmalzieu]

Hi
Frog is pretty great, thanks for this!
I was wondering if it would be easy to support Open Frames https://github.com/open-frames/standard ?

It's a lightweight extension to the Frames spec to help other protocols adopt Frames and verified payloads (it would enable developers to have their Frame supported in Farcaster and, say, XMTP for instance).

I know Frames.js has support for it, would be great to see it in frog as well!

Let me know 🔥

[tmm]

Thanks! Our primary focus at the moment is closely following the Farcaster Frames Specification.

Since the Frames Spec is still new (launched on 1/26/24) and hasn't hit a stable v1 yet (current vNext), we don't want to introduce additional standards to Frog that might conflict with or diverge from what the Farcaster team and community has planned. In addition, the vast majority of Frame usage at the moment is via Warpcast (and Farcaster) so we want to make sure Frog serves that main audience first.

As things mature, definitely down to explore other standards. Feel free follow up on this thread in the future or if anything major comes up you think is worth mentioning!

[derekbrown]

Throwing my proverbial hat in the ring of "please support the open frame spec".

We plan on supporting frames via the OF spec.

For context, we have a group chat app with 250k users or so who are not-yet-crypto-natives.

[tmm]

Wouldn't be too difficult to a create a Hono Middleware that transforms the response from Frog and adds any additional meta tags.

https://hono.dev/guides/middleware

[ngmisl]

+1 for of compatibility. Or an option to add additional meta tags at least

[ggomaeng]

@nmalzieu @ngmisl @derekbrown

Here is an example of adding additional specs

[kuririn1]

After the first click, subsequent button navigation doesn’t work for Open Frames. It's because Frog is reading button values from the state and there is no state present for Open Frames. Solution would be to drive button values based on the indexes, not the state.

[kuririn1]

I almost have working solution (middlewares), will share repo in the coming days. I'm waiting till they (xmtp) fix some bugs in their implementation.

[ggomaeng]

looking forward to it :))

[tmm]

@kuririn1 feel free to submit a PR linking it up in the docs

[kuririn1]

I have working code, I need to clean it up a little bit and will do that.

[kuririn1]

For now here github gist (I'm super busy): https://gist.github.com/kuririn1/3d1a9a3e92b03f604e75c434105cbdda

just import and app.use(xmtpSupport); and Frog frame will work in XMTP apps like Converse (including button actions and state).

I also included xmtp validator.

[humanagent]

Hey there!
Wanted to give an update in Open Frames. Here is all the Frames and partners already integrated.
https://github.com/open-frames/awesome-open-frames
Also Lens protocol launched yesterday announcing its compatibility and there is a PR open in Hey

wen open frames? 🐸🤝🖼️

[bradorbradley]

Hi - this is Bradley Freeman from the Stack.so team. I would also like to advocate for Frog compatibility with Open Frames. We just released a new feature, our Claim Frame, that uses Frog. Claim Frames enable users to distribute token rewards via a frame in 1 click.

We have already received interest from teams that want to use Open Frames for this feature, but are blocked by lack of integration with Open Frames and Frog.

[humanagent]

The middleware from @kuririn1 works great and is able to return the xmtp address. Im not able to add the of:accept:xmtp metadata

Is this approach close to it?

export const app = new Frog({
  headers: {
    "of:accepts:xmtp": "vNext",
  },
});

[humanagent]

Hey all! thanks for your contributions and making this possible!. Frog has now added for XMTP and Open Frames thanks to tmm release 0.9.2 that adds support for custom header metadata.

• Middleware Docs
• Quickstart

[dalechyn]

See #51 (comment)