farcaster-uri HTTP header

[vrypan]

Title: farcaster-uri HTTP header
Type: Standards FIP
Author: @vrypan
Status: Idea

Abstract

This FIP describes how Farcaster clients can add an HTTP header to their HTTP responses. The header will allow other Farcaster clients to identify the Cast or Profile that page refers to.

This is a Standards FIP that has no impact on the core protocol.

Problem

Today, Farcaster content is usually identified by HTTP URLs. If a user wants to mention, share or refer to a piece of Farcaster content (casts, profiles and threads mostly), they use the URL of the webpage they see it, or the URL generated by the client they use.

This means that:

1. The same content is identified by different URLs, depending on the app used: A cast I want to share has a different URL on Warpcast and a different one on Supercast.

2. It is hard to programmatically identify the resource the page corresponds to (for example, CastId) and use it in other apps. (See Appendix I for an example)

Specification

URLs that represent a Farcaster resource can include a farcaster-uri HTTP header.

The structure of the URI is: <resource type>/<identifier>

Formats supported by this FIP (may be extended in the future):

• Casts: the value of the header is set to cast/[fid]/[hash]
• Fid (profile): the value of the header is set to fid/[fid]

fid is always in decimal format and hash is in hex format with an 0x prefix.

Examples:

URL	HTTP Header
https://warpcast.com/vrypan.eth	farcaster-uri: fid/280
https://www.supercast.xyz/c/0x4433a7ed917aaf9526d08593e4b0cbcf8040d687	farcaster-uri: cast/280/0x4433a7ed917aaf9526d08593e4b0cbcf8040d687
https://warpcast.com/vrypan.eth/0x4433a7ed	farcaster-uri: cast/280/0x4433a7ed917aaf9526d08593e4b0cbcf8040d687

Usage

Developers who want to consume the URL in their own programs can use a HTTP HEAD request to fetch the headers, and identify the resource the URL corresponds to.

HTTP headers are easier and less resource-demanding to parse than HTML for the client.

HTTP HEAD requests will usually require significantly fewer resources on the server side too. It is also assumed that implementing this feature does not add significant overhead to developers.

Developers can be agnostic about URLs generated by Farcaster clients. For example, the code to translate a link to a CastEmbed will be the same regardless if the URL a user pasted comes from Warpcast, Supercast or Opencast. Or a command-line client that expands threads like Fargo, will be able to use any URL from any of these clients, or any client that implements this FIP.

The FIP can also enable flows that are not easy today. For example, a browser plugin that allows any “farcaster web page” to be opened in the user’s favorite client.

Limitations

This FIP does not cover how other types of Farcaster resources (for example, reactions and user data) can be described in the farcaster-uri header. Also, popular features that are not part of the protocol, such as channels, are not covered. The FIP may be extended to cover them in the future.

Additional thoughts

Being able to translate a web URL to the corresponding Farcaster resource in an easy and standardized way, could make easier the introduction of a Farcaster URI Specification (farcaster://) in the future.

Appendix I (personal motivation)

Fargo is a great way to expand a long, nested Farcaster thread.

For example, the command
fargo get @cameron/0xa259375e817fdac540286a3239619b56d23243ff -r
will create a nice, nested view of the whole thread. The limitation here is that a user must know the cast hash, and format the command parameters according to Fargo’s expectations.

If Warpcast implemented this FIP, a user could use the URL provided by Warpcast
fargo get https://warpcast.com/cameron/0xa259375e8
Fargo would just have to make an HTTP HEAD request to the URL provided to get the information it needs. And this would work with any Farcaster client, that supports this FIP, without any code change, or knowledge of website-specific APIs.