@gt I'm curious, why is it that I need to wait for a link to expand to include OG tags before hitting Cast to get an expanded link in the resulting cast? Why wouldn't this hydration take place on the client read side? What additional information is included in the cast when the embed is fetched and expanded in the compose preview, vs when I just yeet a link before the fetch returns? Three ways of asking the same question.

product @seedclub. i host S-TIER @ X Spaces & i interview crypto builders @ web3galaxybrain.com.

Ah, it's a very nice UX touch to be able to remove embeds at cast time that I take advantage of often.

I'll have to look closer at the embeds array to understand what is and is not included in a cast when the user chooses to include them.

There are nuances causing this but none of it is a hard requirement. Other clients can choose to go different routes.

We made to choice to not to just assume which URLs (images and videos included) that are in a cast are automatically deemed as an embed and persisted to network.

This allows users to choose by clicking "X" which embeds they want to actually persist on the network as attachments on the cast vs. just text content that is linkified.

It also allows embeds array to generally represent proper attachments that can be parsed for OG tags as we confirm before persisting it. (This however is not 100% guaranteed)