[WIP] Add Open Frames Neynar validator #116
Conversation
package.json
Outdated
| @@ -28,6 +28,7 @@ | |||
| "devDependencies": { | |||
| "@changesets/changelog-github": "^0.4.8", | |||
| "@changesets/cli": "^2.26.2", | |||
| "@open-frames/types": "^0.0.5", | |||
| import { FarcasterOpenFramesRequest, FrameRequest, FrameValidationData } from '../../../core/types'; | ||
| import { NEYNAR_DEFAULT_API_KEY, neynarFrameValidation } from '../frame/neynarFrameFunctions'; | ||
| import { Options } from './types'; | ||
|
|
There was a problem hiding this comment.
Oh side note, we prefer Functional code vs Object Oriented, as it is much lighter in terms of memory and also easier to write test for.
There was a problem hiding this comment.
Fair enough. All I really care about is having something that satisfies a common interface so that developers can build their own request validators and have confidence they will be able to integrate.
Whether the implementation of the interface is a module, an object, or a class is up to the implementer.
| const isTrustedDataValid = typeof payload.trustedData?.messageBytes === 'string'; | ||
|
|
||
| return isCorrectClientProtocol && isTrustedDataValid; | ||
| } |
There was a problem hiding this comment.
So I see, isSupported is where the magic happens.
And ideally we can have as many client as we want.
There are some implementation details that we need to align, but I like where your head is @neekolas
There was a problem hiding this comment.
Exactly. Here is an example of the XMTP RequestValidator that can be safely passed in to getOpenFramesMessage as an argument and will allow for processing of button clicks coming from XMTP.
|
@neekolas I think this can work, after all we are just simply saying, let's see what Client can validate this message, and when there is a match, we let that client connect with a third-party API and take care of it. |
|
Closing this, as it was covered in https://onchainkit.xyz/xmtpkit/get-xmtp-frame-message |
What changed? Why?
This PR adds a proof-of-concept for support of Open Frames. Opening it up for discussion. It shows a path for how
onchainkitcan be extended to support multiple types of Frames client beyond just Farcaster.The PR adds no new runtime dependencies. It just picks up some common types from
@open-frames/types.Notes to reviewers
If we decide this approach is reasonable, I'll add some tests. And we can discuss how we can add some better examples for extensibility.
How has it been tested?
Not at all