𝓵𝓲𝓿𝓲𝓷𝓰 𝓽𝓱𝓮 𝓮𝓷𝓭𝓵𝓮𝓼𝓼 𝓼𝓾𝓶𝓶𝓮𝓻 • building @buoy 🛟 • pfista.com

@pfista your feedback would be valuable here: https://github.com/farcasterxyz/protocol/discussions/171#discussioncomment-9697526.

Dad, geek, conversation liquidity provider. vrypan.net (home), /weatherxm (work), @l--o--l (fun). Also https://paragraph.xyz/@purplesubmarine

I’m personally not stoked about long casts, primarily because it means we need to index data outside of hubs. This increases complexity for us and also has performance and cost implications we would need to adapt to, especially as FC scales.

Selfishly I think long casts should be a client issue. Clients can choose to display a thread of casts as continuous in their UI. Bringing data off hubs doesn’t make sense to me. It increases developer complexity for anyone building on FC protocol

We’d have to choose to index non-hub data, taking on extra cost + complexity, or having a worse user experience and not index data outside of hubs

Building @warpcast and @farcaster, new dad, like making food

Yes we’ll probably take this approach, waiting to see if they get retentive usage and quality content. 

If it sticks we’ll support it, but don’t plan to from day 1

counter point

if long casts being interesting new content to Farcaster the small marginal cost for developers to index will be 

if they don’t then no need to index and there’s no cost

JSON is more developer friendly for sure 

As long as there’s a way to link a frame to a webpage that isn’t pure json (similar to how if you click a frame image today it brings you to an html version of the frame made by the dev)

It makes sense. But assuming we are going this way because users need them, would you prefer them to be inside OG tags in HTML pages or as stand-alone json?