ICP·DevICP·Dev
Back to articles
Web3 SocialAugust 3, 20262 min read

A Live Badge That Can Leave the App: Farcaster Finalizes Portable Presence

Farcaster has finalized a small protocol change that lets an identity publish one current live-activity URL. It could make spaces and streams discoverable across clients, but the richer manifest proposal remains under review and live-status sharing is deliberately public.

Key takeaways

  • Farcaster has finalized a small protocol change that lets an identity publish one current live-activity URL
  • It could make spaces and streams discoverable across clients, but the richer manifest proposal remains under review and live-status sharing is deliberately public
Share
A Live Badge That Can Leave the App: Farcaster Finalizes Portable Presence

A small field with a social consequence

On May 3, Farcaster finalized FIP-268, Live Activity Status. The proposal adds a LIVE_AT user-data field: an authorized signer can write one canonical HTTPS URL to a user’s identity when that person joins a live activity, then clear it when they leave. The value is last-write-wins, so it represents one chosen activity rather than a complete record of everything a user is doing.

That restraint is the point. Instead of creating a new streaming network or a provider-specific API, the proposal places a compact presence signal in the same social data layer that Farcaster clients already read. A profile, feed, avatar indicator, or channel page could surface that signal without each client building a separate integration for every audio-room or livestream provider.

Presence, not media hosting

The activity itself remains at its HTTPS URL. Farcaster is standardizing a way to point at it, not moving audio or video into the protocol. That is a useful division of responsibility for Web3 Social builders: the network can carry portable identity and presence, while providers can continue to specialize in real-time media.

Snapchain matters here because it is Farcaster’s decentralized peer-to-peer data network. The finalized status proposal uses the existing user-data path rather than introducing a new message type or a new storage system. In practical terms, a client that understands the field can read it alongside familiar profile data.

The richer layer is still unfinished

FIP-269, the companion Live Activity Manifest, is still in review. Its draft describes how an external activity page could provide Farcaster-specific metadata for details such as the host, speakers, lifecycle, and recording, plus a signed manifest that binds the host’s Farcaster identity to the activity URL. It also proposes using an ordinary cast and its reply tree as the activity’s chat anchor.

That design is promising because it would let clients render a more useful live card while retaining a standard fallback for clients that do not support it. But the signature would verify the host-to-URL association; it does not remove the need to evaluate an external provider or its dynamic metadata.

Important limits for builders and users

The companion Live Activity Manifest remains in review; a finalized status signal does not prove universal client or provider adoption. The next meaningful evidence will be visible client support, provider implementations, and progress of the manifest through review.

LIVE_AT is opt-in but exposes a public HTTPS activity URL, so it is unsuitable for private or token-gated activities without explicit user consent. Apps should make the visibility choice clear, allow users to stop publishing it promptly, and avoid treating a live badge as a private-presence feature.

Farcaster’s new primitive is modest, but that is its strength: it turns being live from a feature trapped inside one app into a piece of social state that other apps can choose to recognize.

Tags

#Farcaster#Snapchain#Web3 Social#Decentralized Social#Interoperability#Live Streaming

What to read next

Enjoyed this? Get the next one

Subscribe to the newsletter and the next playbook lands in your inbox — no spam, unsubscribe anytime.