The Frame Transactions spec is ready for feedback! Please share your thoughts in replies, comments or DMs. Your feedback is very important to help us get the design right. https://www.notion.so/warpcast/Frames-Transactions-Public-Draft-c2e0d3210d684b4cb7803de1810db36d?pm=c
Our goal is to collect feedback over the next 24-48 hours and then finalize a spec before the developer call on Thursday. h/t @horsefacts.eth for the heavy lifting and @deodad @gt and @sanjay for design input.
So on mobile, users need to have the Coinbase Wallet app for it to work?
actually quick question - before going live can y'all make a hidden/dev page in the warpcast mobile app that acts as a playground for testing transactions/how things appear/etc Feels more important now that the stakes are higher than just raw frames
Do you guys have plans to support for ‘eth_sign’ for wallets doing account abstraction?
Can’t wait for wallet connect to die or improve. It misses 7/10 times for me. Horrible UX
Really interesting! Also very well written for anyone to understand the risks that this may present to users. I would like to point out that this notion page allows me (and maybe anyone) to edit it! https://www.notion.so/warpcast/Frame-Domain-Associations-Public-efcb07871f0c42b4ae6ace62acce64e4 It was in your notion
Overall, super cool. Regarding the UX pop up (“trust context”), consider using more mainstream human readable action notes. Most non-technical ppl might not understand “Call mintWithRewards on ZoraMinter”. Can consider having simple normie descriptions and adding a small icon to touch for more tech details.
@v @dwr Is there an easy place to store addresses? Ideal Flow: Cookie Store Frame Select 4 boxes Change Address from Default Buy Confirmation Frame
POV: You're having drinks with the homies at /ethdenver and someone mentions that the Frame Transaction spec just dropped
Will the call from client to transaction intent URL be a GET or POST? Seems like a post makes most sense, including a similar payload to "post" actions.
There is a opportunity here to incorporate community reputation feedback (spam-abuse flagging) on a intent domain basis. In the immediate term, the Warpcast allowlist may make this a moot point, and the "requested by..." element of the trust context is helpful, reputation-wise.
In terms of the Warpcast allowlist, something to consider is "posting a bond" or paying in Warps for consideration, much in the same way that you have to pay 100 Warps to post in the /frames channel -- this may reduce the human vetting required by reducing applicants to serious ones.
I'm betting less than 10% of transactions in frames clients will happen via this method in a 6 months. Too many steps, too slow, too unsafe (still has risk beyond the cost of the current transaction). 95% of transactions will be < $10 and users just want to press a button and pay the $ and get the thing, no risk.
Not a fan of this proposal. It adds a lot complexity to the spec and doesn't meaningfully improve over the current problems of crypto UX: speed, safety, simplicity. The flow has significant friction and low conversion for the most common txs in social: small mints/fees, so those txs will find other ways to convert.
Is it be possible to generate the payment json more dynamic e.g. through an post request including the frame action? So we could integrate user discounts/voucher etc. Into a one click transaction
The trusting mechanism is pretty similar to Ledger's "Clear signing" of contract interaction. The difficulty is to balance scalability (signing more stuff) and security (auditing / trusting the whitelist). People will most probably end up ignoring warnings and get scammed, but I don't really have a better alternative.
my hot take is that transaction urls should not be in the spec. adds a lot of complexity to what should be relatively straightforward tool for frames to use and is a centralizing force only domain attribution and who shared the frame should be presented to the user in client - no tx simulation, wallets already to this
Nice work @horsefacts.eth! Suggesting a visual cue for `tx` actions in the farcaster spec -- like unique colors or icons, to clarify user actions. Especially with new frame transactions, I'm concerned about user hesitation without clear, standardized indicators.
Made some comments in the attribution section. cc /data nerds @ilemi @juicemanjames.eth @chuxin
The moment we all have been waiting for! $A51 Token is now LIVE!🚀🚀🔥🔥 Token is now live on @QuickswapDEX ! Token Address: polygonscan.com/token/0xe9e7c0…