Malformed response from Lens transactions

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

@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

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

frames.js/packages/frames.js/src/lens/index.ts

Lines 74 to 85 in 4df7a3a

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

Also it is not specified in the type definition

frames.js/packages/frames.js/src/lens/index.ts

Lines 10 to 28 in 4df7a3a

    
           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

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

frames.js/packages/frames.js/src/xmtp/index.ts

Line 2 in 4df7a3a

XmtpOpenFramesRequest,

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.

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

@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.

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.

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

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

	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;
	};
	};