# Who is here. Without asking your API.

Subscribe to a presence channel and the current roster arrives with the subscription, so the room renders populated instead of empty. After that, every client hears the same joins and leaves. Your backend assigns each member their identity when it signs the subscription, which is what makes the list trustworthy.

## A member is a person, not a socket.

## Three tabs are one member.

Presence is part of the Bird Realtime API, and it counts identities rather than sessions. A member joins the list when their first connection subscribes and leaves it when their last one goes; the tabs in between produce nothing, so a roster does not flicker every time somebody opens a duplicate window. If you need the socket count instead, that is a separate app setting and a separate event.

## What presence gives you

The roster, the changes, and the identity to hang both on. All of it signed by your own backend.

## A buddy list is not a room.

Presence answers who is in this room with me. Watchlist events answer whether the people I care about are online anywhere. A member's signed identity can carry up to 100 member ids, and with watchlist events enabled the connection is told when any of them comes online or goes offline, with the whole list's current status delivered right after sign-in. Because the list lives inside the signed identity, your endpoint decides who may watch whom. No channel per relationship, and the people being watched do nothing beyond signing in.

## Go deeper in the docs.

Presence channels covers the roster, member info, and the server-side reads. Authorizing channels is the contract your backend implements, sending events to a member compares member events with private channels, and watchlist events is the follow-list variant.

## Render the room, not a loading state.

Presence, client events, and member-addressed delivery come with every Realtime app. The free plan covers 100 concurrent connections.