We are looking forward to add CTA before or after somebody sends a transaction. For example, someone could add a “Learn more” button that sends the user to some website, or “Manage your asset” after a minting transaction has been sent that redirects them to a website we host.
Right now the way to external link the user, is to make them click on the image of the blink. Which is not a good UX for a CTA, and is limited to only link.
Implementation:
Adding a type to the LinkedAction, that denotes if the button should call an action or send the user to the defined website
export interface LinkedAction {
/** URL endpoint for an action or the URL to redirect the user */
href: string;
/** button text rendered to the user */
label: string;
/** parameters used to accept user input within an action */
parameters?: ActionParameter[];
/** whether is an external|action link, defaults to action */
type?: string;
}
I think adding some sort of CTA “action type” is a good idea. There is a decent amount of overlap in this post: sRFC 32: Optional Transactions in Action Chaining for the implementation of something like this.
What type of CTAs do you think would be useful? The only one I can really think of is a link that should open a new tab for the user.
For user safety, should there be any restrictions on what websites can be linked to? Or would be displaying the domain below the button be sufficient enough
Will think about which other CTAs could be useful. In the post you linked, @0xaryan mentions: post, sign-message, external-link and tx of course.
About the security issue: I think it would be the same security issue than already trusting the action’s entity with the transaction building, so I believe there’s the same level of trust for these links? Unless they are user-generated.
Taking that in consideration maybe we can have some type of “cors policy” in the host’s /actions.json defining which hosts are trusted.
The proposal makes sense to me, I’ve seen several requests and questions for supporting this.
This can work, as an idea we can visually indicate external link by a special icon and/or may be even show a warning before opening external link. I personally think we should ask for recommendations from UX/UI experts during client implementation and polish this.
In cases that the links are user-generated. It would be a way for all to agree that an entity would only and only allow X domains.
NFTs have an external url field where creators can put a website there, a Blink could add a button that links to this website. The server’s entity could filter malicious ones, but wanted to extend an idea to have a public list that anyone could read, regarding the security concern.
Does it make sense? Could also be too extra and not worth the maintenance of it on the long term, exhausting protocols with too much stuff is not cool.
I would personally love to see this. There’s a lot of use cases where action buttons which link to external sites would be useful.
Farcaster frames had this since the beginning and a lot of the frame actions were actually linking to external sites, most of them were ones which required some other external authorization/signup before executing a transaction, therefore it had to be done on the third-party website instead of directly through the Frame.
Other use cases were already mentioned and also come in very handy, such as having a link to a page where users are presented with additional information (think “Learn more” button).
The implementation makes sense, I think for now it’s enough to have a LinkedAction which can either be one that triggers an endpoint call (action) or is just a link that opens a new tab in the browser.
to progress the proposal along, I want to vocalize that I am for this proposal.
for the specific implementation, I think it can and should be easily included into the same implementation effort as SRFC 32
effectively making “external links” a different type of action. some actions will be transactions, some will be external links, etc.
the one caveat I think the spec update SHOULD include is that blink clients should at least display the domain of the link to the user somehow. eg: under the button or something. the design specifics can be up to each blink client
I support this proposal as well and agree that it can be easily integrated into the same implementation effort as SRFC 32. I think we are ready to move forward with the implementation, and any additional details can be addressed as they arise during the process.
