Feature Request: Make Onchainkit work with Hubs directly.

[SamuelLHuber]

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

[SamuelLHuber]

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

1. add the verified addresses
2. cast liked by interactor
3. cast recasted by interactor
4. caster followed by interactor

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:

FrameValidationData.following
FrameValidationData.interactor.custody_address
FrameValidationData.interactor.verified_accounts
FrameValidationData.interactor.verified_addresses
FrameValidationData.interactor.liked
FrameValidationData.interactor.recasted
FrameValidationData.liked
FrameValidationData.recasted

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

{
  "valid": true,
  "message": {
    "data": {
      "type": "MESSAGE_TYPE_FRAME_ACTION",
      "fid": 2,
      "timestamp": 48994466,
      "network": "FARCASTER_NETWORK_MAINNET",
      "frameActionBody": {
        "url": "https://fcpolls.com/polls/1",
        "buttonIndex": 2,
        "inputText": "",
        "castId": {
          "fid": 226,
          "hash": "0xa48dd46161d8e57725f5e26e34ec19c13ff7f3b9"
        }
      }
    },
    "hash": "0xd2b1ddc6c88e865a33cb1a565e0058d757042974",
    "hashScheme": "HASH_SCHEME_BLAKE3",
    "signature": "3msLXzxB4eEYe...dHrY1vkxcPAA==",
    "signatureScheme": "SIGNATURE_SCHEME_ED25519",
    "signer": "0x78ff9a...58c"
  }
}

and is documented here

[fakepixels]

Thanks for the feature request! @SamuelLHuber Your feedback has been acknowledged and we'll revert when there's an update.

[Zizzamia]

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.

[SamuelLHuber]

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:

FrameValidationData.following
FrameValidationData.interactor.custody_address
FrameValidationData.interactor.verified_accounts
FrameValidationData.interactor.verified_addresses
FrameValidationData.interactor.liked
FrameValidationData.interactor.recasted
FrameValidationData.liked
FrameValidationData.recasted

if you know what style you prefer happy to make a PR adding hubs to getFrameMessage

[Zizzamia]

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.

[SamuelLHuber]

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

[Zizzamia]

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.

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 like this.

[SamuelLHuber]

@Zizzamia got it, did some work on types and mapping the PR today. Would love to understand what the default should be.

Assume one neither gives a Neynar API Key NOR a Hub URL.

Should the fallback be Hubs or Neynar? Right now it's easy since it's always neynar so it falls back to use the default key.

With Hubs one could default to the public hub from Merkle Manufactory, which then as default would allow anyone to not need a API Key, though then they don't get Neynar enriched types by default.

It's a tradeoff, would love to learn which way you're leaning.

For pure validation it doesn't matter and if users need the full data they likely bring their own Neynar Key or have to set the Hub options either way.

Not sure if the above is fully understandable, happy to add more context.