@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

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.

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)

Can the warpcast url not be used?
Considering notifications are still on the app level?

We’re linking notifications to right now, but it has to redirect through the mini app first which is a little janky

Having a notification link directly to a cast would be great