sRFC 32: Optional Transactions in Action Chaining
Summary
Transactions in Action Chaining are non-optional right now, therefore for each action in the chain the user need to sign completely differnet transactions which works fine for a limited use-cases but for majority of the user-cases and also to create a better UX, the user should only sign the transaction once whenever possible, that would be mostly the last action in the chain.
Same way as any form works, taking information from the user and only showing the submit button at the last. This could open up some interesting design spaces, where a game is getting played on the blink and when game ends, the winner can claim the price, or generating NFT’s with help any AI directly from the blink and deploying the collection, these are just some examples to support.
Implementation:
Currently when the client makes the POST request, then ActionPostResponse is sent with following structure.
/**
* Response body payload returned from the Action POST Request
*/
export interface ActionPostResponse<T extends ActionType = ActionType> {
/** base64 encoded serialized transaction */
transaction: string;
/** describes the nature of the transaction */
message?: string;
links?: {
/**
* The next action in a successive chain of actions to be obtained after
* the previous was successful.
*/
next: NextActionLink;
};
}
If, we modify the ActionPostResponse to keep the transaction as an optional field
/**
* Response body payload returned from the Action POST Request
*/
export interface ActionPostResponse<T extends ActionType = ActionType> {
/** base64 encoded serialized transaction */
transaction?: string;
/** if transaction is present, describes the nature of the transaction */
message?: string;
links?: {
/**
* The next action in a successive chain of actions to be obtained after
* the previous was successful.
*/
next: NextActionLink;
};
}
The client can now skip the pop-up to user to sign the transaction and depending upon the NextActionLink render the blink.
export type NextActionLink = PostNextActionLink | InlineNextActionLink;
/** @see {NextActionPostRequest} */
export interface PostNextActionLink {
/** Indicates the type of the link. */
type: "post";
/** Relative or same origin URL to which the POST request should be made. */
href: string;
}
/**
* Represents an inline next action embedded within the current context.
*/
export interface InlineNextActionLink {
/** Indicates the type of the link. */
type: "inline";
/** The next action to be performed */
action: NextAction;
}
If the NextActionLink is of type InlineNextActionLink then the client can directly render the metadata and no callback would be required.
If the NextActionLink is of type PostNextActionLink then the action server can return metadata depending on the previous inputs by the user address
It should be upto the aciton server to server a InlineNextActionLink or PostNextActionLink type of NextAction to make a better UX for the specific use-case.
This way, the action server can also track informations across a series of actions happening on the client. The idea of JWT also crosses the mind, but imo having each action linked to an address and on client only the given address can sign the transaction removes a lot of concerns.
