However, having multiple clients ¹ introduces a new challenge: resource links.

Here are some scenarios:

1. Suppose you use TBA and want to share a link to an interesting cast on X. You tap “Share,” copy the link, and post it on X. Now, I’m using the Zapper app, and when I click that link, I’m taken to a page like:
   https://base.app/post/0x723095057009a6255eca94352e8ea671a7f03439
   — a deep link intended for TBA. Since I don’t have TBA installed, the page is unusable.

2. Even worse, imagine a third user copies that same link and pastes it in a cast, in Recaster. When this link appears inside another Farcaster app, it should ideally render as a cast embed. But because the app doesn’t recognize it as a Farcaster resource, it just shows a plain link. When users click it, they again land on a base.app page where they can’t interact, instead of the client they are using.

This is not a TBA-specific issue. You get the same problem if you change app names, and replace the links with the corresponding app’s links.

This issue isn’t new. For a long time, Warpcast also embedded cast links as plain URLs rather than native embeds. Thankfully, that changed — otherwise, we’d be stuck with thousands of casts opening on the (now, deprecated) warpcast.com domain.

Now, we need a solution that works across all clients and user setups.

There are two main components to such a solution.

1. Standardized Resource Metadata

Any URL representing a Farcaster resource (cast, profile, etc.) must expose a standard way for other apps to identify it. We can’t expect every client to know the URL structure of every other client — and in some cases, extracting this information isn’t even possible.
A good example is the Farcaster app itself, which doesn’t include the full cast hash in its URLs.

A clean, extensible solution is to use HTTP headers — see FIP: HTTP Headers for Farcaster resources.

This approach allows any Farcaster client (or any external app) to perform a lightweight HEAD request to a URL and determine whether it references a Farcaster resource (e.g., a cast). If so, the app can render or embed it natively.

2. A Universal Link Service for Farcaster

The second component is a universal link service: a way to share a single Farcaster link that opens in the user’s preferred client.

For example, if I share a cast from my blog, when you click on it, it should open in your preferred Farcaster client. If you use Zapper, it should open in Zapper; if you use Recaster, it should open in Recaster.

Ideally, this would be handled through a protocol URI scheme, such as:
farcaster://cast/280/0x627b6c301664aea2fe5da8cca0da59d3823f9fc8
However, mobile developers agree that implementing this reliably on mobile (and even desktop) is challenging.

A practical workaround is inspired by SubToMe, which has provided a similar solution for RSS for over a decade.

The idea is simple: agree on a shared domain — for example, link.farcaster.xyz — and have all clients use it when generating shareable links. A cast link will look like this:
link.farcaster.xyz/280/0x627b6c301664aea2fe5da8cca0da59d3823f9fc8
(Yes, shorter or prettier URLs are possible, but they would increase complexity and load for the service hosting this link system, the decision is up to whoever implements it ²).

When a user visits such a link, they’re prompted to select their preferred Farcaster client. The site stores this preference in a cookie, then redirects them to the appropriate deep link.

On subsequent visits, the stored preference automatically redirects them without prompting. This setting is per-browser, allowing users to choose Recaster on mobile and farcaster.xyz on desktop, for example.

You can leave a comment here — good luck finding a way to open the cast in your favorite app, if it's not the "official" Farcaster app.