@v, @deodad, @horsefacts.eth 
Once again, I ask you to allow notifications to link to casts, using a fc://... URI. @buoy could use it to make UX so much better, just like Warpcast does when it notifies me about a cast.

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

I'm eth newbie..just learning
(working on @farcaster)

terminally.online

Building @warpcast and @farcaster / dad / like to read, cook, ski, code

Search Engine for Farcaster. Save your search and get realtime alerts for new results. Download for iOS & Android on buoy.club · web beta.buoy.club

Dad, geek, conversation liquidity provider. vrypan.net (home), @l--o--l (fun). devcoin:$lemon3

IMO would be cool to support a viewCast action in the miniapps sdk and then let notifications specify any sdk action to trigger (ie viewCast, viewProfile, swapToken, etc)

Why would we *have* to open the mini app? It would just be handled in the client app.

Though optionally there could be a param to also open the mini app if needed.

Benefit is the interface is the same between actions and notifications

But this would not solve the actual problem, which is to have a notification link to a cast **without** opening the miniapp.

Use cases:
- apps like buoy, that deal with casts.
- apps that do not want to deal with adhoc content. Any simple miniapp that does one thing well (swap token, let you vote, whatever) does not want to implement special functionality to announce that there is a new version, new reward tiers, new features. They want to post a cast with the content and send a notification linking to this cast.

Also, opening the miniapp to get redirected to a cast, means that if I currently have a miniapp open (streaming video for example), I will have to close it in order to move on with the flow.