FIP: (convention) Cast metadata storage

[davidfurlong]

proposed by (@davidfurlong / 🟪) and (@stephancill / 🟪).
The proposed convention below doesn’t require any Farcaster protocol changes, but requires some client consensus, and some people on Farcaster asked for it to be posted as an FIP, and thus is being published here for feedback

The goal is to allow Farcaster clients to innovate on richer content formats in a way that doesn’t require integration from other clients, but also always allows the permissionless integration by any other client to integrate if they choose to. For this to be possible, sometimes data needs to be stored that doesn’t currently fit into the CastAdd message type.

Examples of metadata that apps may want to embed as metadata to a cast in order to innovate on richer Cast content formats

• a poll
• location check-in
• inviting users to an in-app game
• token gated (encrypted) text
• a longcast

Suggested convention

We're suggesting to do this by adding a URL to the cast's embeds that serves JSON Linked-data when the URL is fetched with a GET request. The URL can also serve useful fallbacks in the form of an open-graph og:image tag that serves a fallback image with a (non-interactive) image of what the metadata is intended to represent, as well as potentially a fallback experience for the enriched experience, if the current app doesn't natively support it. In order to natively support an interactive or enriched experience from the metadata, apps would need to fetch the JSON Linked-data from the page if they don’t already, alongside the data they currently fetch, such as the Open graph image and title. We have an open source code example for how to do this that can be run by anyone here and here. The app could then render a special interface for the type of metadata.

Schemas

JSON Linked-data uses schemas that are reusable. You can either use an existing one or publish a new one. This can quickly become “schema hell” if everyone uses a different schema, and there's suddenly 10 different schemas for Polls that serve very similar functionality. There are many existing schemas on schema.org, such as ChooseAction for Polls, that are existing schelling points, and that are in use in over 10 million websites.

Apps are free to ignore schemas without a problem - this is the way JSON Linked-data works on the web today. This includes apps ignoring not just new schemas created for use on Farcaster, but also JSON Linked-data schemas already present on existing websites, such as opensea, which serves “WebPage”, “Organization” and “Product” on NFT pages.

This way there is both the freedom to innovate and experiment, with eventual loose consensus based on apps with distribution integrating certain schemas and not others. With Mod, we want to help apps adopt whichever schemas and rich new interactions they want to, without additional engineering, and entirely open source.

Storage

Apps that serve urls with this JSON Linked-data have the choice whether to store the metadata on their backends or on decentralized storage, a bit like the way in which images and media currently work in the Farcaster ecosystem. At mod, we are storing all the metadata on either Arweave or IPFS, and are exposing this data via a gateway URL accessible over HTTP which contains the Arweave transaction ID or IPFS CID in the URL in a standard format i.e. , which apps can rewrite to serve the content in another manner if they choose to do so. Through irys or ar or other services, storing JSON files on arweave below 100kB is currently free.

Benefits of this design

1. It works with existing open graph previews on the web, without a need for new integrations
2. It uses widely adopted web standards - JSON schema is used by search engines like google to enrich search results with things like Jobs.
3. The degree of decentralization, as well as the choice of storage is flexible and un-opinionated.
4. It supports flexible data schemas and models that can be arbitrarily large
5. Gateways that choose to use this URL pattern can be rewritten by apps, bypassed and all the data needed to retrieve the metadata is in the shared url itself
6. JSON is a dev friendly format
7. JSON Schema allows for the composition of Schemas
8. Doesn’t require strong consensus on metadata schemas

Why not use open graph instead of JSON Linked-data/JSON schema?

Open graph is good for strings, but doesn't natively support JSON (although you could serialize JSON as a set of key value string pairs). Open graph doesn't have a standard for the definition of data models.

A full example up of how we want to do use this convention in Mod

[davidfurlong]

All of the other ways to solve this that we considered

1. Apps can put Cast metadata in a human readable text format in the cast text.

This is the simplest, but it comes with some challenges. False positives, the requirement for human readability, limited space, end users changing the text and mini-apps not detecting the poll. An example of a false positive is in a poll that is formatted 1. 2. 3. this could also just be a list, so as a client, if you want to render Polls as a voting interface, but not lists, you’ll have a hard time. So It’d need to have a bit more structure to it that make it a bit less natural as text. It makes the logic a lot more complex for detecting mini apps.

2. Extend the Farcaster protocol with an arbitrary JSON field in casts

This ossifies the protocol, and places limits on metadata size that may not work for all metadata. It also means more complexity, more work to build a minimum viable client, requires stronger standards and consensus on metadata types, and means unimplemented metadata has no meaningful fallback.

3. They can store the metadata in an NFT, and store a CAIP-19 url to it in the cast embeds. That url can resolve to an open graph preview, with possibly more data provided by the url for clients that want to go beyond open graph.

This is more opinionated than the proposed solution above, and is still a viable way to implement the proposed solution. There’s isn’t a strong reason to prefer storing in an NFT over other mediums.

4. Store the data in a third party service, and generate a (dynamic) image that is stored as a link in the cast. That image request returns metadata as well as the image

Challenge: images on the web typically don’t also serve arbitrary JSON metadata, and images don’t have a way to provide a richer fallback experience if needed. For example there’s no way to play or initiate a game in an image.

5. Serialize the data and store it, encoded as a string in the embeds field, in place of a url, for clients to interpret directly without relying on a third party service.

An example would be to JSON.stringify the metadata or find a suitable key value storage format.

This has the problems that there is no default fallback for apps that haven’t integrated this schema type, it doesn’t work using widely adopted web standards, would require a protocol docs update for handling this special type of embed, and is limited in space by the length of the embeds field.

6. Put some special identifiers in the cast text to uniquely identify the type. For example [Poll], or tagging a special account

This approach is limited by characters that fit in the cast text (320 bytes), and all metadata stored needing to be human friendly, which isn’t always possible.

7. Store data in a third party service, without providing any sort of reference to this service in the cast, instead providing it in the third party service

This allows the feature to work in your client, but not others, without them using your API

[varunsrin]

Closing since a lot of this is solved by frames / mini-apps (which was inspired by this)