Real-time feeds within the frame

[adamunchained]

Title: Real-time feeds within the frame
Author: @adam_unchained

Overview

I’m new to Farcaster so be patient with me please. I love what you’re doing, especially with frames and it reminded me of a solution that I’ve built in the past. Since this is still in an idea stage I’ll keep this more high level.

Frame provides a great way to present dynamic data upon user's interaction. It’s great for basic functions but more modern widgets / applications require real-time updates. Stream of new information without user action such as charts, tickers and especially games. This is a significantly limiting factor to deliver the next stage of frames.

Frames being presented as images is smart. It provides necessary security and it’s a key design that should persist even for real time. Add ability for the developer to specify web-socket for real-time updates. Developer feeds new images over the web-socket. Images can be pushed down to one second ideally.

Users will see a new “live” label or similar to indicate this is a real-time frame. User receives a live stream as long as the frame is presented within the visible area of a client.

This coupled with my other proposal #174 would completely change how users are able to interact with frames.

Details

• Introduce new meta property to enable real-time stream with URI
• Meta property defines frequency of updates. Minimal increment one second.
• Meta property with link to image property that’s used in case real time stream fails (this might be optional)
• Meta property with link to image for “skeleton” image before real-time feeds are established. Provide a placeholder while the user waits for content to load or visualize content that doesn't exist yet.
• Transition from the frame to frame should ideally be smooth/quick/instant. I mean, the next image should be preloaded in the DOM before the current image is preloaded.

Challenges

• Determine how long real-time data should be streamed into the frame. Handle situations where users just leave their browser open or change tabs. Of course this is up to the client but it should be standardized. Ideally, in those cases the stream might be paused and the user is informed about it within the frame. If they hover over the frame, it’ll reactivate the stream.
• Proxying websockets might present some challenges when it comes to scaling. Although, it is still a preferred method over Long polling (WebTransport could be ideal for this in the future).
• Protocol needs to handle unstable web-sockets or web-sockets that try to push messages more frequently. Technically if messages are pushed in less then one second frequency those images are just ignored. As this might cause unnecessary demand on the infrastructure, I would consider a penalty system to make sure developers are responsible.

[varunsrin]

I generally agree with this as being the biggest limitation of frames.

@horsefacts is thinking through some ideas around this

[adamunchained]

great! Happy to help where I can even jump on the call to brainstorm further if easier. I'm in PST.

[varunsrin]

This should now be feasible with the new mini-app architecture