Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

Suggestion for @dwr.eth @v — consider refining the interaction on frame content rendering during its “state transitions”. Feels a lil like a modem internet slideshow right now — how can it be either dramatically faster or more fluid feeling. Maybe speed is the main thing to focus on…

CTO @ OpenSea. Fmr. Co-Founder of Dharma Labs. 

Opinions my own

Agree. We haven’t really experienced fast frames yet. :)

I beg to differ 🙂 

https://frame.quilibrium.com/polls/1

Is speed a frame-implementation constraint or a client-implementation constraint or both?

I imagine it’s a mix and wondering if there are best practices that frame builders can follow for performance in particular.

What can be done about the tx queuing experience, is that handled by transaction requests from frames

So people don’t need to do boosted/free mints anymore with a choke point at the frame?

Many of the frames I’ve used had to have to a reload, it’s only milli to ~1.5 seconds and I have to tap again. Thinking raw data, the reload experience makes sense, the data can only be SO big, or so I’d imagine… so the expectation would be limited to those confines?  ¯\_(ツ)_/¯
Ergo: faster won’t be much?