Skip to content
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

Malformed response from Lens transactions #469

Open
lusorio opened this issue Aug 5, 2024 · 7 comments
Open

Malformed response from Lens transactions #469

lusorio opened this issue Aug 5, 2024 · 7 comments

Comments

@lusorio
Copy link

lusorio commented Aug 5, 2024

Hello,

While porting the Quidli frame for FC into Lens, I've found that once a transaction is performed properly, I don't receive a TxHash in the response. Actually, the response seems to be malformed in some way and the target frame of the post action can't load at all.

Quidli/debug-frames-lens#1

@defispartan made a fix in this demo code that works fine when the frame is anonymous. In that case, the response looks good and I find a TxHash in it, but setting Lens as the client automatically makes it fail.

As he suggested, there might be some issue in the framesjs debugger. I can't be more specific as I have no idea where the issue could be, but would be nice to have some information and eventually a fix.

Thanks

@michalkvasnicak
Copy link
Collaborator

@lusorio I don't see also open frames support for lens here https://github.com/Quidli/debug-frames-lens/blob/366ca0043f2167545257023183f90359ebb08638/app/frames/frames.ts#L16-L32 have you tried setting up the middleware to handle Lens? See https://framesjs.org/guides/lens#create-your-frames-app

@michalkvasnicak
Copy link
Collaborator

Another issue I found is in Lens support @defispartan implemented. I don't see any mention of transactionId there so that could probably be the culprit.

Here transactionId is missing

const {
url,
inputText,
state,
buttonIndex,
actionResponse,
profileId,
pubId,
specVersion,
deadline,
identityToken,
} = frameActionPayload.untrustedData;

Also it is not specified in the type definition

export type LensFrameRequest = {
clientProtocol: string;
untrustedData: {
specVersion: string;
profileId: string;
pubId: string;
url: string;
buttonIndex: number;
unixTimestamp: number;
deadline: number;
inputText: string;
state: string;
actionResponse: string;
identityToken: string;
};
trustedData: {
messageBytes: string;
};
};

I thought that maybe it is just a matter of adding few lines, but then I noticed that @lens-protocol/client doesn't have transactionId specified in FrameEip712Request type. See the screenshot

image

I tried to upgrade the @lens-protocol/client to 2.3.1 but with no help.

@defispartan:

  • is transactionId a part of the message?
  • Is there any type definition in @lens-protocol/client that can be imported instead of LensFrameRequest so we can be sure it comes from source of truth? For example XMTP is exporting the type from validator, see
    XmtpOpenFramesRequest,

@michalkvasnicak
Copy link
Collaborator

michalkvasnicak commented Aug 7, 2024

There is no mention of transactionId in Lens spec https://lensframes.xyz/#frame-requests but see Open Frames.

Normally it would be just a matter of adding transactionId and use that in the middleware, but @lens-protocol/client doesn't have transactionId property support in createTypedData(). Lens use actionResponse instead which breaks the compatibility with open frames.

@lusorio
Copy link
Author

lusorio commented Aug 7, 2024

Hey @michalkvasnicak

Yes, you're right. The link I provided is the code @defispartan proposed to showcase the fix. Actually, when using an anonymous client I can fetch the tx hash (but then I'm missing the user's profileId). In the original code, I was using lens:1.0.0 or lens:vNext as a client as you can see here (with opposite result: profileId, but no tx hash)

Quidli/debug-frames-lens@fcb6b15#diff-b85d4cfafcd6e8f7267c4cfe49d28d8667f5965cf337f7d8d867c0404ad6fc25

@michalkvasnicak
Copy link
Collaborator

@lusorio It is unfortunate but the issue is caused by lens not being 100% compatible with Open Frames spec. The difference is in tx button flow, when it is explicitly mentioned that transactionId should be the part of the message payload, but Lens uses actionResponse instead.

@defispartan
Copy link
Contributor

defispartan commented Aug 8, 2024

This was done with the intention that actionResponse could be a more general field that supports transaction, signature, or relayer (Lens API) responses, but based on this thread, Open Frames plans to use transactionId for signature responses as well, so we're going to update the Lens Frames spec to deprecate actionResponse and exclusively use transactionId.

After this change is made to the Lens spec and API/SDK, I can open a PR here to fix this.

@lusorio
Copy link
Author

lusorio commented Aug 9, 2024

Thank you both, I'll be waiting for it.

@davidfurlong davidfurlong added the Frames.js label Sep 13, 2024 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants