Content
@
https://warpcast.com/~/channel/fc-devs
0 reply
0 recast
0 reaction
horsefacts
@horsefacts.eth
The first few composer actions are live! We made a few changes to the spec, to use postMessage instead of an HTTP callback for form to client communication. If you're interested in building your own composer action, let me know! https://warpcast.notion.site/Draft-Composer-Actions-7f2b8739ee8447cc8a6b518c234b1eeb
9 replies
2 recasts
29 reactions
Vladyslav Dalechyn
@dalechyn.eth
can action: { type: 'form' } be used here to allow an easier separation for cast actions and composer actions for warpcast/other app clients? an action with such type would be only allowed to respond with type: 'form' message. or is there another way to detect if an action is a composer action or a cast action?
1 reply
0 recast
0 reaction
horsefacts
@horsefacts.eth
yeah, need to figure out what metadata should look like. I wasn't convinced "composer actions" should actually be distinct from "cast actions" but I think they probably should be. I can imagine cast actions that use the same form response type, though.
1 reply
0 recast
0 reaction
Vladyslav Dalechyn
@dalechyn.eth
hmmm, something like cast reply pre-fill based on the parent cast? if yes, I think composer action might pass parent cast id in FrameMessage's `castId` to achieve same functionality. posting from the feed? `castId` empty posting as a reply? `castId` = parent cast id. what are other use cases?
1 reply
0 recast
0 reaction
horsefacts
@horsefacts.eth
I'll DM, we should catch up on this. I think Frog doesn't handle undefined castId right now, even though it's technically possible. We're stubbing with an all zero hash and Warpcast FID in a few places, but would be better to remove it.
0 reply
0 recast
0 reaction
