# Making Casts More Flexible

## **Goals**

1. Casts should be “turing-complete” primitives that have enough degrees of freedom to allow developers to create new types of social applications.
2. Casts should not fragment liquidity, and casts created in one application should render in other applications in a useful manner without needing constant work.

These two goals and important to consider carefully because they often conflict with each other. For example, a totally open ended data schema would solve for (1) but violate (2).

## Current Solution

- Public social networks have posts which contains text, media or both. Media in this case is usually an image, video, URL or an audio clip in rarer cases.
- Farcaster has casts which have ≤ 320 characters of text and 2 optional urls. Note that our client today only supports one, but the protocol supports two and this will be fixed

“Turing completeness” is achievable if all image/video/audio content can be folded into a URL which would allow us to approximate most common types of social networks today and have the flexibility to invent new ones. “Liquidity fragmentation” is avoided if all URLs adhere to the OpenGraph specification and have a renderable form which all clients can show as a baseline. Some clients can do better than the default, but there is a baseline that works well for everyone.

There are some degrees of freedom that are intentionally constrained today to make it easy for application developers to render content created by other apps:

- No layout specifications are allowed except spacing and line breaks within the text and none at all for the URLs except for the implicit sizes of the OpenGraph data.
- No specificity around media rendering at the cast level — developers can specify if a URL should be “embedded” by including it in the embed field vs the text field, but cannot define other properties like size, playback, length or other content.

## **What are the problems with this approach?**

1. Rendering clients that explicitly wish to render a subset of content (e.g. only long form text or only short form videos) must unpack and parse each URL to determine if the content is relevant to them.
1. Writing clients must convert media into URLs by hosting it somewhere. Often, this is done via a third-party service and the clients cannot influence the OpenGraph tags or other header data easily to control how the URL previews are rendered.

### Potential Solutions

1. **OpenGraph Tags** — writing clients should ensure that produced URLs under their control have good open graph tags. This can range from simple and static to dynamic and evolving like Github’s image rendering implementation.

2. **Farcaster Specific OpenGraph Tags** — creating clients can use a pre-defined set of headers to annotate even more information about the content. We’re open to adding these as an extension to the default OG properties.

3. **Proxy Redirects** — in cases where the creating client cannot control the destination URL, a proxy URL can be set up with the correct OpenGraph tags and a redirect to the destination URL. Reading clients can scrape this information and use it to render content, and Farcaster clients can agree on some generic schema here. A simple fc-redirect header would be sufficient along with general open graph headers.

4. **Cast Metadata** — we could allow applications to specify freeform metadata of a few bytes with every cast. This is useful for adding static content (e.g. lat/long coordinates) to augment a post. This is not very useful for marking up media content inside urls (see rejected solutions below for explanation)

A common theme amongst these ideas is that we are only able to make the experience better for writing clients, but not for reading clients. Inherently, adding metadata to a URL is not a reliable mechanism to solve the reader problem — there is no guarantee that it was correct at the time of creation, it will become outdated and incorrect if the URL changes and it takes up valuable space on the hubs. Readers must read the url and its metadata to be able to render it correctly and writers should endeavor to keep this up to date, and this is an inherent design constraint because of how the web works today.

### Rejected Solutions

1. **Freeform text annotations:** like old school twitter (e.g. RT, #s) — while we expect people will experiment with them, we don’t believe this is sustainable because it requires constant work on the part of other clients to “keep up” with new annotations. The most likely outcome is that such content gets poor distribution because it looks kludgy.

2. **URL or Cast metadata**: by letting application developers add metadata like “video, wide aspect ratio, short” making the data about the underlying content easier to access without scraping the URL. However, there is no guarantee that such data is accurate or remains accurate when the URL content changes, and realistically most apps would have to do URL scraping anyway to deal with the edge cases.

### Counterpoints

- Why not allow metadata anyway? Even if not 100% accurate it reduces the number of casts that a video client must sort through…
- This is better solved with a centralized indexing service that processes URLs and can offer such annotations freely and there is very little benefit to offer a partially functional, but decentralized solution.