Tony D’Addeo on Warpcast

vrypan |--o--| pfp

@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 pfp

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--| pfp

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 pfp

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--| pfp

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 pfp

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--| pfp

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 pfp

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

vrypan |--o--| pfp

I think you may have a very different setup in mind than I do. My miniapp notifications are sent async by a backend that has no idea of what the sdk is. Can you explain how your solution would work? Say, my miniapp alarm wants to send me an alert tomorrow morning. How will the sdk be used?

1 reply

0 recast

0 reaction

Tony D’Addeo pfp

something like notificationTarget: { type: 'viewCast'; castHash: "0x..."; } | { type: 'openUrl'; url: "https..." } a bit more obvious than forming uris especially if there are multiple options and analogous to the mini apps sdk actions

1 reply

0 recast

0 reaction

vrypan |--o--| pfp

Obv, we have very different approaches to interface design. You live in js/ts world and think that constructing json components and parsing arbitrary json that may have different elements per case is something natural. From my pov, all these payloads that may have structure A or B or C depending on the case are an overhead. Also, this is a local solution, not a global one. The next time we need to reference a Farcaster resource, we will have to reinvent the wheel. (Example: FIP-202).

1 reply

0 recast

0 reaction