Content
@
0 reply
20 recasts
20 reactions
christopher
@christopher
Having to wrangle embeds and other content is such a weird experience within Farcaster's ecosystem. It almost feels like URLs don't belong directly within casts. I like the idea of content being separate from messaging but still linked via hash like IPFS (but not IPFS, IPFS a lot of caveats).
2 replies
6 recasts
19 reactions
christopher
@christopher
Embed messages could exist separately. Flip the idea that a cast does not require an embed; Embed messages require at least one hash/URL. E.g. a decentralized YouTube where you would only listen to Embed messages and optionally join on cast hashes. @stevedylandev.eth would love your thoughts on the IPFS era.
1 reply
0 recast
5 reactions
Steve
@stevedylandev.eth
It almost sounds similar to what FIP171 was redirected to https://github.com/farcasterxyz/protocol/discussions/171 def would be nice as resolution would be dependent on the builder/client, similar to how nft marketplaces work right now when given a url like “ipfs://CID”
1 reply
0 recast
3 reactions
christopher
@christopher
Yeah similar in spirit, but different in execution.
1 reply
0 recast
2 reactions
vrypan |--o--|
@vrypan.eth
I think one of the basic problems forecaster embed_urls have is they lack metadata. For example, RSS enclosures have a few more pieces of information that allow clients to be more efficient in treating content-specific "embeds". https://en.wikipedia.org/wiki/RSS_enclosure I would love to see a new type of embed_url added to the protocol, that at least offers a (mime) type field.
1 reply
0 recast
1 reaction
vrypan |--o--|
@vrypan.eth
This is especially important if you intend to use IPFS URLs. Contrary to HTTP, where you could in most cases use a HEAD request to identify the content type, IPFS does not offer metadata, so you will have to download the whole file in order to see if it's an mp3, a jpeg or an HTML page.
2 replies
0 recast
1 reaction
Steve
@stevedylandev.eth
On the flip side gateways generally can pick up the content type when doing a head request, however it would be better to have Farcaster standard for embed metadata
0 reply
0 recast
1 reaction
