-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Make Onchainkit work with Hubs directly. #748
Comments
onchainkit types are so tightly coupled to neynar that adding a Hub only version would be a breaking change unless for every frame request you'd make subsequent requests to
These queries may be turnable into one via SQL Queries, but still add overhead which I'd love to avoid. My proposed change would be to offer the current types as FrameValidationDataNeynar and have a generic FrameValidationData type that would be Hub compatible OR adapt the current type to make the following properties optional since they will not be servable with one call to the validateMessage endpoint on Hubs:
One could add a function that pulls all of these from Hubs on choice by the user, though I'd prefer the default to have lowest possible latency the resonse of the Hub validateMessage endpoint for Frame Messages looks like
and is documented here |
Thanks for the feature request! @SamuelLHuber Your feedback has been acknowledged and we'll revert when there's an update. |
Hey @SamuelLHuber, do you want propose a PR that showcase the Types you want us to support. So we can start taking a few steps into the direction you are recommending. |
that depends on the style you want to have. as mentioned above the neynar specific fields can either be made optional or queried from Hubs as well in addition to the message verification. currently the message is being validated in src/frame/utils/getFrameMessage.ts#39 by calling Neynar, this could be done via Hubs as well. The question here is how you want the types to be. My opinion is to make them optional and just do pure verification on Hubs. One could then add a helper to fetch the details or provide the option to pass a long to fetch the following properties from hubs directly:
if you know what style you prefer happy to make a PR adding hubs to getFrameMessage |
yes please :-) Curios to see more, how you would like to use it. |
so you don't have a preferred style? then I'd just recommend one request by default validate, and then load what the user needs if they do. means Neynar -> get everything directly because neynar enriches it Hubs -> get the minimum in one call, and enrich if you want to by opt in to additional queries to the hub besides pure verify Message |
I think in general OnchainKit lost traction over Frame development over the last few months, as we shift resources towards shaping the Design System. But we still want to maintains Frame features, and add what's missing. To do so, I will prefer more leaning towards learning from folks like you, that are experts on what's good Frame development can look like.
I like this. |
Describe the solution you'd like
Instead of a Neynar API Key let me input a Hub address, removing the requirement for every onchainkit user that wants Farcaster Frame related tooling to have a Neynar account.
Describe alternatives you've considered.
Using Frog.fm and Frames.js or writing code directly without Framework
The text was updated successfully, but these errors were encountered: