vrypan |--o--|
@vrypan.eth
@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.
3 replies
2 recasts
22 reactions
Kartik
@slokh
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)
1 reply
1 recast
3 reactions
vrypan |--o--|
@vrypan.eth
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.
2 replies
0 recast
2 reactions
Kartik
@slokh
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
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
Maybe I did not understand the original suggestion. An sdk.action requires the miniapp to open, right? My ideal view is the other way around: sdk.actions.openUrl() accepts farcaster URIs, and does not have different methods for profiles, casts, etc. I can't find a good reason not to start adopting farcaster URIs. Miniapps, notifications, direct casts, something else someone may want to build, should have a well-defined URI scheme to address far cater resources.
1 reply
0 recast
0 reaction
Kartik
@slokh
I’m suggesting the notification payload supply the action to call and args. I don’t like URIs personally because they aren’t developer friendly and we would need actions anyway to do other stuff like swapToken. Rather have everything run through a single interface that is either called by the miniapp or triggered on notification press (with or without opening the miniapp)
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
The nice thing about URIs is that they can be used everywhere. I can map an iTerm pattern to open farcaster URIs using Fargo for example. Or I can build a browser plugin that bookmarks them in a client-agnostic way. Once the scheme is defined, no more begging for clients to implement this or that (like I'm doing now). URIs are not the solution to everything. You are right, a tokenSwap action will probably need a special method. But for casts, profile attributes or other well-defined Farcaster resources, I strongly believe that a standardized URI scheme is the best approach. How do you refer to my default address? My pfp? My twitter verification? Special sdk.action.methods?
1 reply
0 recast
0 reaction
Kartik
@slokh
Don’t disagree but seems separate to the original mini app notification problem, which again my opinion is it should be standardized in a way that supports fc and non-fc actions without the developer having to think too much about it
1 reply
0 recast
0 reaction