FIP: Live Activity Manifest

[rishavmukherji]

Abstract

A live activity (audio space, livestream, broadcast event, listening party) is identified in Farcaster by an https:// URL — the audio session URL, served by a third-party provider. The host cryptographically attests to that URL with a JFS signature served at a manifest endpoint linked from the URL; dynamic state (host FID, speakers, participant count, lifecycle, recording) is served as Farcaster-specific OpenGraph meta tags on the same URL.

A cast is also created (by the host's client when the activity starts) referencing the audio URL as an embed. That cast is the chat anchor — chat in the activity is the standard reply tree of the cast. The audio URL points back at the cast via an fc:cast meta tag.

Discoverability via the USER_DATA_TYPE_LIVE_AT slot defined in the companion FIP: Live Activity Status points at the audio URL.

No protocol-level (Snapchain) change is required.

Motivation

USER_DATA_TYPE_LIVE_AT carries an opaque URL. To render that signal as a live activity card, every Farcaster client must resolve the URL and extract metadata. Without a standardized contract, providers expose proprietary APIs (forcing per-provider client integrations) or fall back to OpenGraph (which lacks live-activity-specific fields).

This FIP standardizes:

• The meta tags the audio URL serves (dynamic state).
• A small signed manifest binding the URL to a host FID (host attestation).
• A cast-and-replies convention for chat under the activity.

The cast convention makes space chat behave like normal replies, integrates spaces into existing conversation surfaces (channels, threads), and requires no special-case treatment of "chat under spaces."

Specification

Audio URL

The audio session URL is the canonical identifier for a live activity. Typically a third-party provider URL, e.g. https://broadcast.app/space/abc123. USER_DATA_TYPE_LIVE_AT points at this URL when a user is in the activity — for the host and for every participant (speakers and listeners share the same URL value).

Activity meta tags

The audio URL SHOULD serve Farcaster-specific OpenGraph-style meta tags carrying dynamic state. The presence of fc:live=1 is what identifies a URL as a live activity:

<!-- Required to mark this URL as a live activity session -->
<meta property="fc:live" content="1">
<meta property="fc:live:hostFid" content="<integer>">

<!-- Optional dynamic state -->
<meta property="fc:live:startedAt" content="<ISO 8601 UTC>">
<meta property="fc:live:speakerFids" content="<comma-separated integers>">
<meta property="fc:live:participantCount" content="<integer>">
<meta property="fc:live:expectedDurationSec" content="<integer, 1–86400>">
<meta property="fc:live:endedAt" content="<ISO 8601 UTC; once present, permanent>">
<meta property="fc:live:recordingUrl" content="<absolute URL>">

<!-- Optional cast anchor for chat -->
<meta property="fc:cast" content="<cast hash>">

<!-- Manifest pointer (required) -->
<link rel="farcaster-live-activity-manifest" href="<URL of the manifest endpoint>">

<!-- Standard OpenGraph for title, cover image, description -->
<meta property="og:title" content="...">
<meta property="og:description" content="...">
<meta property="og:image" content="...">

Required: fc:live, fc:live:hostFid, plus the manifest pointer link. All other tags are optional. Multi-valued tags (speakerFids) are comma-separated integers with no spaces.

fc:live:startedAt, fc:live:expectedDurationSec, and fc:live:endedAt are all optional. Activities with no known end time (e.g., an impromptu huddle) simply omit endedAt and expectedDurationSec; lifecycle is then driven by LIVE_AT freshness on the host's slot, plus an explicit endedAt set by the provider when the activity actually ends. Once endedAt is present, it is permanent — providers SHOULD NOT revert an ended page back to live.

fc:cast (when present) carries the hash of the cast that anchors chat for this activity (see Cast and chat below). Speakers and listeners are surfaced in fc:live:speakerFids; the broader participant list is intentionally not enumerated in meta tags (use LIVE_AT cross-checks if needed).

A non-Farcaster client (or one without live activity support) sees standard OpenGraph tags and renders the URL as a regular unfurl. This fallback is the desired behavior.

Manifest (host attestation)

The manifest endpoint linked from the audio URL serves a signed envelope binding the URL to the host's Farcaster identity. The signature is structurally identical to the accountAssociation JFS used by Mini Apps — same header / payload / signature shape, base64url JSON, Ed25519 over ${header}.${payload} — with the payload claiming the audio URL instead of a domain.

type LiveActivityManifest = {
  hostAttestation: {
    header: string;     // base64url JSON: { fid, type: "auth", key }
    payload: string;    // base64url JSON: { url: <audio URL> }
    signature: string;  // base64url Ed25519 over `${header}.${payload}`
  };
};

The manifest contains only the host attestation. All other information lives in meta tags on the audio URL itself. This keeps the manifest small, cacheable, and lets clients verify host identity without parsing dynamic state.

A client verifying the manifest:

1. Base64url-decode hostAttestation.header and hostAttestation.payload.
2. Parse header as JSON. Verify header.type === "auth" and header.fid matches the fc:live:hostFid meta tag served at the audio URL.
3. Parse payload as JSON. Verify payload.url matches the audio URL the client is resolving.
4. Reconstruct the signing input as ${hostAttestation.header}.${hostAttestation.payload} and verify the Ed25519 signature using header.key.
5. Query Snapchain for the active app keys of header.fid. Verify header.key is in that set.

Skipping verification and trusting the meta tags directly is not recommended but is possible if the clients wish to do so, accepting the risk that an audio URL could lie about its host without the JFS check.

The host signs the URL claim once, when the activity is initiated — typically the host's Farcaster client constructs the JFS using the user's active app key (the same delegated key used for casts) and hands it to the audio provider, which serves it back at the manifest endpoint. Subsequent state changes (participant count, ended state, recording URL) update meta tags only — no re-signing.

This signature is what prevents impersonation: if someone copies the audio embed URL into their own cast to share or amplify the activity, they cannot make themselves appear as the host. The host claim is bound to the URL via JFS, not to whoever embedded the URL.

Cast and chat

A cast is created by the host's client when the activity starts. The cast has:

• embeds[0].url — the audio URL.
• parent_cast_hash (optional) — for activities in a thread or conversation context.
• parent_url (optional) — for activities scoped to a Farcaster channel.

Cast text is unstructured user content — the host writes whatever they want. Title and description for the activity itself live in meta tags on the audio URL, not in the cast text.

Chat in the activity is the standard reply tree of this cast — replies use parent_cast_id set to the cast's hash. There is no separate parent_url-anchored chat tree. Replies inherit cast-level moderation, channel context, and reply-tree behaviors (threading, mentions, embeds in chat messages). Replies are not top-level content — they appear in the reply surface, matching how users think about chat.

The audio URL's fc:cast=<hash> meta tag points at this cast, so clients resolving the audio URL can find the chat anchor without scanning Snapchain for casts that embed the URL.

Resolution flow

A client resolving an activity URL <url> (typically discovered via LIVE_AT):

1. Fetches <url> with standard browser-like Accept headers.
2. Parses meta tags. If fc:live is absent or its content is not 1, the URL is not a live activity — render as a plain unfurl (standard OpenGraph) or as the URL itself.
3. Validates required tags (fc:live, fc:live:hostFid) and the manifest pointer. On any required tag missing or malformed, falls back to a plain OpenGraph unfurl.
4. Renders the live card from the meta tags + standard OpenGraph.
5. Optionally (RECOMMENDED for trust-sensitive surfaces) fetches the manifest endpoint and verifies the hostAttestation per the Manifest section. On verification failure, the client MUST un-render or annotate the card to reflect that host identity could not be verified.
6. Optionally queries Snapchain for the cast referenced by the fc:cast meta tag (if present) to render the reply tree as chat.
7. Combines fc:live:endedAt / fc:live:expectedDurationSec lifecycle signals (when present) with the LIVE_AT message-level freshness rule (see the companion FIP) to decide whether to render the activity as currently live.

Discovery via LIVE_AT

See the companion FIP: Live Activity Status (USER_DATA_TYPE_LIVE_AT) for how presence and discovery work. In short: LIVE_AT points at this audio URL; the host's freshness drives "is this still live."

Privacy considerations

Recording URLs

fc:live:recordingUrl is a public link. Providers gating recordings behind paywalls or token gates SHOULD point recordingUrl at a page that handles access checks rather than serving raw audio/video.

References

• FIP: Live Activity Status - companion protocol-level signal that points at the audio URL
• Mini Apps documentation - accountAssociation JFS precedent.
• Discussion #266: Snapchain Signers - FIP authoring conventions.

[CassOnMars]

This proposal is a good idea, but carries a few issues that reduces the practicality of its intent:

• using meta tags to convey session state
• no content negotiation/multiplexing consideration
• no standard path to intrepretability

I'll break each down.

using meta tags to convey session state

meta tags are frequently cached for long durations, as their intention is to be a long-lived signal to applications towards the content itself. If a session is over, the data in its final state is fine, but prior to that (including the existing ingestion pipeline for your backends), this data is cached for a long time, meaning useful status signals like participant count and speaker fids will likely be wrong for the effective duration, most likely the original data set in the first place when casted. This should be surfaced through a different method, e.g. any http method that helps cache bust against aggressive CDNs a lot of service providers wrap around frontends, i.e. POST/PATCH/PUT

no content negotiation/multiplexing consideration

open audio/video streams often follow one of two approaches: WebRTC or RTMP, sometimes together. it would be helpful to align the metadata to the necessary information to connect for this, otherwise you're shifting the burden to the website delivering the stream, to which point, it basically carries no meaningful difference from a miniapp and this FIP itself could be skipped altogether, opting to point to a miniapp as-is for the companion FIP. surfacing this information at the metadata level lets a user know:

• how do i connect to this
• what options do i have for streaming

which is crucial for actually integrating support for this, otherwise it ends up being informal standards that clients will impose, and have to adapt to whenever a popular client decides to set the "standard"

additionally, by not taking on this burden, there is a huge security issue, in that most webrtc implementations do not care in the slightest about revealing user metadata, like IP addresses. as an example, a mini app could set up a webrtc session, and intentionally or not, create the opportunity for a user of the miniapp to collect a mapping of IPs to FIDs, regardless of whether the miniapp intended this. if a client were to embed this directly, it increases the likelihood that this attack could work.

no standard path to interpretability

as mentioned in the previous point, meaningfully integrating this has a wide-open gap for informal "standards" to emerge. if clients are to support this, they inevitably would, if the FIP is taken as-is, do whatever the most popular client does, and when the primary client changes that interpretation, it would break the other clients.

[rishavmukherji]

thanks for the feedback! getting to this post farcon

using meta tags to convey session state

agree meta tags shouldn't convey dynamic state. There's a few kinds of "dynamic" data that we had used as examples and here's how I think they can be treated to start:

• participantCount: doesn't need a field at all, sum up participants by looking through who all have the same live_at value on the protocol
• speakerFids: live_at value should have a query param ?role=speaker and that tells us who the speakers are. role enum right now can be speaker and participant to start
• endedAt, recordingUrl, cohostFids: these are not dynamic and can be put in either meta tags or the manifest alongside the host signature
• expectedDurationSec: not needed tbh, will remove the field at this time
  if there are future fields that emerge and need to be considered, we can consider standardizing additional ways to surface dynamic data.

no content negotiation / multiplexing consideration

this would be a good addition in the next update to this FIP where we can add connection (transport) mechanics without breaking v1 implementations. fc:live:transport:* can be surfaced. In v1, clients throw open a webview for the live_at url if the url isn't from their client and clients writing that url can be responsible for ensuring that the url is functional. this keeps the v1 light and allows users on multiple clients to experience the space without adding to the FIP upfront. To that end, we can reserve the fc:live:transport:* meta tag namespace as part of this FIP for a connection mechanics followup FIP.

no standard path to interpretability

clients open up webviews for non native live events will save interpretation work in v1. Once the connection mechanism FIP is finalized as a followup, interpretability will be standardized. generally on the same page, want to break it up into follow on FIPs.

[CryptoExplor]

@CassOnMars raises valid concerns — the meta tag caching issue and content negotiation gap are real problems. But I think the proposal's core design (opaque URL + manifest pattern) is salvageable with a few targeted fixes.

Addressing the Critiques

1. Meta Tag Caching / Stale Participant Counts

Problem: CDNs cache meta tags; dynamic state (speaker list, participant count) goes stale.

Solution: HTTP cache headers + versioned manifest

The spec should REQUIRE that URLs serving fc:live meta tags set:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

For clients that want aggressive caching (mobile data savings), the manifest could include a cacheUntil timestamp:

{
  "hostAttestation": { ... },
  "cacheHint": {
    "maxAge": 5,  // seconds
    "staleWhileRevalidate": true
  }
}

This makes caching opt-in and provider-controlled, not CDN-imposed.

Alternative: Move dynamic state entirely to the manifest endpoint (not meta tags). Meta tags become static descriptors:

• fc:live=1 (static: "this is a live activity")
• fc:live:hostFid (static: host identity)
• fc:live:manifest (link to dynamic state)

Clients MUST fetch the manifest for real-time data. This separates "what kind of thing is this" (cacheable) from "what's happening right now" (uncacheable).

2. Content Negotiation / Protocol Selection (WebRTC vs RTMP)

Problem: Clients don't know how to connect (WebRTC? RTMP? HLS?) without fetching the page.

Proposal: Add fc:live:protocol meta tag

<meta property="fc:live:protocol" content="webrtc+hls" />

Values: webrtc, rtmp, hls, dash, srt, or comma-separated for multi-stream.

Clients can decide before embedding:

• Native mobile clients can reject WebRTC-only streams (privacy concerns)
• Desktop clients can prefer WebRTC for low-latency

This also solves the IP leakage issue: clients that don't support WebRTC (or choose not to for privacy) can refuse to render WebRTC-only activities.

Manifest extension:

{
  "protocols": [
    {
      "type": "webrtc",
      "sdp": "https://signal.example/offer",
      "privacy": "exposes-ip"  // warning flag
    },
    {
      "type": "hls",
      "playlist": "https://cdn.example/stream.m3u8"
    }
  ]
}

3. Security: IP Address Leakage via WebRTC

Cass is right — this is a real attack vector. Mini-app embeds a "live activity" that's actually a WebRTC signaling page; user's IP leaks to the provider.

Mitigation:

1. Client-side privacy controls: Clients SHOULD allow users to disable WebRTC for live activities (or all embeds). Warpcast, e.g., could have a setting: "Only allow HLS/RTMP streams, block WebRTC."

2. Provider reputation: The manifest signature (JFS) binds the URL to a hostFid. Clients can track which FIDs serve WebRTC vs relay-based streams and surface warnings: "⚠️ This activity uses WebRTC, which may reveal your IP address to @hostFid."

3. Proxy requirement (strong mitigation): The spec could REQUIRE that WebRTC streams go through a TURN relay (no direct peer-to-peer). Clients reject activities that don't declare a turnServer in the manifest.

This should be explicit in the FIP — a "Security Considerations" section documenting the WebRTC IP leakage risk and recommended client mitigations.

4. No Standard Path to Interpretability

Problem: Without content negotiation, clients can't know what they're getting until they fetch.

Proposal: Adopt a typed manifest schema

The manifest (fetched from farcaster-live-activity-manifest link) should return:

{
  "type": "live-audio-space",  // or: live-video, live-event, live-stream
  "version": "2026.1",
  "hostAttestation": { ... },
  "metadata": {
    "title": "...",
    "description": "...",
    "image": "..."
  },
  "state": {
    "startedAt": 1736054400,
    "participantCount": 42,
    "speakerFids": [...]
  },
  "protocols": [...]
}

type field makes activities interpretable before parsing state. Clients can:

• Refuse to render unknown types
• Apply different UI treatments (audio space = pill, video stream = inline player)
• Build type-specific features (e.g., "raise hand" for live-audio-space)

This also future-proofs the spec: new activity types (live-podcast, live-game, live-auction) can be added without protocol changes — just new type strings.

---

On "Informal Standards" Risk

Cass warns that without negotiation/typing, clients will "impose standards" and fragment. This is valid — but the FIP does prevent the worst case by:

1. JFS signature prevents URL spoofing (host attestation ties URL to FID)
2. Manifest contract creates a standardized extension point (not proprietary APIs)

The gap is that the manifest schema is currently too loose ("any JSON that looks like this example"). Tightening it to a versioned, typed schema would address the interpretability concern.

---

Recommended Changes to FIP #269

1. Add Security Considerations section:

   • Document WebRTC IP leakage risk
   • Recommend client-side privacy controls
   • Suggest TURN relay requirement for WebRTC streams

2. Require HTTP cache headers for meta tags:

   • Cache-Control: no-cache for pages serving fc:live tags
   • Or: move dynamic state entirely to manifest (meta tags = static descriptors only)

3. Add protocol selection to manifest schema:

   • fc:live:protocol meta tag for pre-fetch filtering
   • protocols array in manifest with privacy annotations

4. Formalize manifest schema with versioning:

   • Add type field (activity taxonomy)
   • Add version field (schema evolution)
   • Publish JSON schema for validation

---

tl;dr: Cass's critiques are sharp, but fixable. The URL+manifest pattern is sound — it just needs tighter contracts (caching rules, protocol negotiation, security disclosures) and a formal schema to prevent fragmentation. With those additions, this becomes a robust extension point that scales to future activity types without protocol churn.

Strong support for the core design; recommend revisions addressing the above before merging.

[schoolkamsergj]

Hey! I'm a Base L2 game developer working on Base Invaders (Phaser 3 + Base mainnet) and wanted to share a real-world use case for live activity from a game dev perspective.

With the new Farcaster Snaps, I built an example showing how on-chain game devs can:

Embed a "Play Now" button directly inside a Farcaster cast via a Snap endpoint

Pass Farcaster FID to Base MiniKit on Snap load

Trigger a Base mainnet transaction (start game session, mint score NFT) from the cast

Display results back inside the cast

Full working example (PR): builders-garden/base-minikit-starter#1

How this connects to FIP #268 (live activity):
For real-time games we need the cast to stay "alive" — updating scores, reacting to on-chain events. Live activity would allow:

A game session Snap that updates in real-time as players submit scores on-chain

Cross-client support (Warpcast, Juke, etc.) for game tournaments happening on Base

Would love feedback on whether the current proposal covers on-chain game session use cases, or if there are specific fields to consider for transaction-driven live updates.

[vrypan]

I think I would prefer to see an extension to casts, instead of user data.

The ideal way would be a really extensible system for casts, something we have discussed so many times, and each time it looses in favor of a quick and dirty addition here and there (very long casts, location, banners, and so on)

But if we don't want to do the real thing, an alternative is adding TTL to a cast. The TTL will be a soft indicator of validity (i.e. it's up to the clients to use it, it will not be removed from the snapchain).

A client may decide to use this cast as a presence/live activity indicator (show it at the top of the profile? add a border or a dot to the pfp?) if the TTL is still valid (or the last one casted if more than one are valid). But it can also be valuable in casts like "24h more to mint", or "registrations to the event are closing in 3 days".

[rishavmukherji]

This is not really cast data though. This is user data. E.g. imagine displaying just a simple list of active users on the app with a green dot. That has nothing to do with a cast, the user who is marked live in an app may have never casted. Similarly, a receiver in an audio space might never cast.

Whether a user is live on an app is connected to data for the user and not a cast they write. Also maybe this discussion is better on the related FIP instead of here? #268

[vrypan]

Indeed, #268 is the right place. Got confused.