# FIP: External cast data

Source: https://github.com/farcasterxyz/protocol/discussions/171
Kiwi News: https://news.kiwistand.com/stories/FIP-External-cast-data?index=0x6654f03c62444040ef41c7054bf798b270a3cca236dc5b5629467ab5e147d42046f39fda
Submitted by macbudkowski.eth on 2024-05-27 UTC, 3 upvotes, 0 comments

## Summary

FIP "External cast data" by @vrypan and @davidfurlong proposes enabling long casts by storing their content at an external URI rather than on Farcaster hubs, and embedding it using Embed.url. The proposal supports only plain text long casts and is designed to be extended later to other data types such as location, audio and events without hub changes. Long-cast JSON-LD payloads can be embedded in an HTML page or hosted stand-alone under an fc: URI scheme, and the payload must be less than 32kb. The authors state that the 32kb limit allows content publishable as a 25,000-character long tweet, and hub requirements and storage requirements are unchanged.

## Article

Title: External cast data (long casts) Type: Standards FIP Authors: @vrypan, @davidfurlong

Abstract

This is a proposal to enable long casts. The long cast content is stored at an external URI. The proposal is designed to be easily extendable to support more features in the future, without hub modifications.

Problem

This FIP was triggered by the discussion on long casts (see https://warpcast.com/v/0xa9456e70).

In addition, a look at FIP ideas and Farcaster discussions indicates that many developers are interested in embedding a number of data types in casts: location, audio, events, etc. This FIP defines long casts in a way that will allow embedding various data types in the future with minimal changes.

Specification

Long casts are stored in external storage (not hubs) and are embedded to casts using Embed.url.

Only plain text long casts are supported by this FIP.

Data Format

The content of a long cast is stored in JSON Linked Data format:

{ "@context": "https://farcaster.xyz", "@type": "Longcast", "description": "The long cast content..." }

Embedding the payload

There are two ways to link to a long cast.

1. json-ld payload embedded in an HTML page.

The json-ld payload can be embedded in an HTML page:

<script type="application/ld+json"> { "@context": "https://farcaster.xyz", "@type": "Longcast", "description": "The Cast..." } </script>

and applications can use Embed.url to point to the HTML page URL.

In this case, clients will have to fetch the HTML, parse it and check for a json-ld longcast payload, in the same way they check for Open Graph tags to display frames and page previews.

This is a backwards compatible way that will work nicely with web content shared on Farcaster (for example, blog posts can provide a longcast json-ld payload and clients can show the whole blog post as a long cast).

The disadvantage of this method is that clients have to load an HTML page without knowing in advance what to expect, and check for OG tags, then check for json-ld, and decide what to do depending on what the results.

2. Stand-alone json-ld payload

The json payload can also be hosted at a URL and Embed.url can link directly to it. Linking directly to the json payload is more efficient than embedding it in HTML.

In this case, the url must be in the format fc:<url> that indicates to clients that the URL points to a json-ld payload.

Examples:

fc:http://www.test.com/longcast.json

fc:ipfs://QmWMo7MrnpSAH2dMKNhcrvLeKdyyqjyrAdy9vUfEdyqcwU

Why use the fc: URI schema?

It works with protocols (like ipfs) that do not support resource metadata (contrary to HTTP, IPFS does not provide headers like Content-Type). An fc: URL will always point to json-ld data.

The json is useless to any client that does not support this FIP, anyway: Without fc:, they would show a “no preview available” because they are not aware of the payload structure, now they will show the same because they do not know how to deal with the fc: URI schema.

For clients that support this FIP, it is easy to check the URL schema (any library that parses URL parts will return schema=fc, path=http://....), and then treat the path as the new URL.

Indexers that want to index cast content can have a clear indication that this URL contains content to be indexed (and it’s not a link to an image or a video) as part of the cast, before fetching it. They also know that they should expect get a json-ld payload.

Supported protocols

This FIP does not explicitly limit the transfer protocols clients are expected to support.

However, clients are encouraged to support at least HTTP, HTTPS and IPFS.

Presentation

If a cast includes both a body and a long cast, clients are expected to render both and I provide a visual indicator (for example a separator) that lets users know which part corresponds to each one. The cast body (if present) is expected to be rendered before any long cast content.

Size Limit

The JSON payload (either embedded or stand-alone) size must be less than 32kb.

This limit is set to help clients allocate resources and protect them from malicious payloads that could allocate an arbitrary memory size.

The limit also allows any content that could be published as a long tweet (limit 25,000 characters) to be posted as a long cast. (When using unicode characters this may not always be the case, but this feels like a good approximation.)

Wherever possible, clients are advised to reject the json data structure when its size is more than 32kb.

Compatibility

Long casts embedded in an HTML page provide multiple ways (OG tags, HTML tags) that allow clients that do not support this FIP to show an alternative representation of the long cast (for example, a frame or an abstract).

Long casts directly embedded as stand-alone json will appear as unsupported link types in clients that do not support this FIP. Given the early stage of the Farcaster ecosystem, this is considered an acceptable tradeoff to provide a future-proof, clean and efficient way to embed rich data in casts.

Extensibility

Clients that implement this FIP, can easily support additional json-ld payload schemas if they decide to do so in the future.

schema.org has a number of schemas (including events, places, products, reviews and other) already supported by major services like Google, but new ones can also be defined.

JSON-LD is available in a number of popular programming environments. A comprehensive list can be found at json-ld.org.

Hub requirements

No changes.

Storage requirements

No change in storage requirements.

Additional thoughts

The combination of long casts stored in decentralized storage, combined with permissionless channels can provide a truly decentralized content publishing platform that requires NO web servers: the web3 version of the web2 blog.

Revisions:

2024-06-04: Clarified that only plain text long casts are supported by this FIP.

2024-06-03: Refactored the FIP: JSON-LD payloads, embedding payloads in HTML, payload limit set to 32kb, fc: schema to link directly to payloads.

2024-05-25: Dropped mentions support inside the long cast.

2024-05-25: Added 25KB limit for the JSON payload.

2024-05-26: Renamed structured+ to fc+. The term feels more natural given the context, and easier to use.

2024-05-26: Supported transfer protocols are http, https and ipfs. Arweave and other p2p protocols are left for future versions.

text/pre is also part of the spec. It indicates pre-formatted text such as code or ASCII art.