Presence And Read Receipts Are Chat Metadata

End-to-end encryption protects message content, but it does not automatically hide the behavioral signals around a conversation. Typing indicators, read receipts, delivered markers, last-seen status, custom presence, active or away state, notification counts, and API-accessible status fields can reveal when a person is awake, reachable, avoiding a thread, working late, or coordinating with a group.

That does not make every indicator unsafe. Many teams rely on presence to reduce interruption and many users like read receipts in trusted groups. The practical question is whether the product treats those indicators as metadata with scope, controls, retention, and abuse cases, or as harmless interface polish.

Presence signals are small, but they are not empty. An active marker says a client is connected or recently used. A last-seen value says when a user was reachable. A read receipt says a person opened a conversation up to a specific point. A typing indicator says a user started composing, even if no message was sent. Over time, those signals form a behavioral map.

The risk depends on context. In a small internal engineering workspace, presence may be an ordinary coordination tool. In a survivor support group, labor organizing channel, newsroom tip line, executive incident room, or high-risk political network, the same signals can expose availability, relationships, time zones, attention, and stress.

The Matrix Client-Server API makes the distinction clear. It defines typing notifications as ephemeral room events that list the user IDs currently typing. It also defines read receipts, including a public read receipt and a private read receipt that clears notification state without broadcasting the user's read position to other users. That is a useful design lesson: a client can need local read state without turning that state into shared social telemetry.

Telegram's FAQ shows the product-level version of the same issue. Its check marks distinguish delivery to Telegram's cloud from a message being read, and its last-seen controls replace hidden precise timestamps with approximate values. Those choices acknowledge that status can be useful while still needing ambiguity and user control.

Presence becomes a different security problem when it is exposed through APIs. Slack's presence documentation describes custom status as profile data and its users.getPresence method can return active or away state. For the authenticated user, the response can also include whether a client is online, manual or automatic away state, connection count, and last activity seen by Slack servers.

That API surface is useful for workflows, directories, incident response rotations, and scheduling tools. It is also a reason to treat status data as access-controlled information. Once an app can query presence, the review expands from the user interface to OAuth scopes, bot membership, logs, third-party processors, retention, and what happens when an app is removed.

Signal's sealed-sender work is a useful reference point because it separates content secrecy from service-visible metadata. Signal said the service is designed to minimize retained user data and described sealed sender as an incremental step toward hiding who is messaging whom. The same post also notes that traffic correlation through timing and IP addresses remained an area for ongoing work.

The broader lesson is simple: encryption claims need boundaries. Message bodies, sender identity, recipient identity, device IPs, delivery timing, read state, online status, and typing state are different pieces of data. A product can protect one strongly while exposing another for usability, abuse prevention, federation, delivery, or enterprise governance.

The right default is not universal. Consumer chat often rewards immediacy. Workspace chat often rewards coordination. Private communities often need a quieter posture. Some rooms should have no typing indicators, no public read receipts, no precise last-seen state, and limited presence access for bots. Other rooms may accept those signals because the collaboration value is higher than the exposure.

Administrators should avoid treating this as a personal preference only. In a community, one user's presence setting can reveal group behavior. In a workspace, a bot with user-read scope can observe many people. In a federated or bridged room, one system's privacy setting may not survive the trip into another product. Defaults need to match the riskiest expected use, not the lowest-friction demo.

Start with an inventory. List every presence-like signal the product emits: online state, last active, custom status, typing, delivery, read receipts, thread read state, voice-room activity, profile changes, and mobile push state. For each signal, document who can see it, whether users can disable it, whether admins can force it, whether apps can query it, and whether it appears in exports or logs.

Then test abuse cases. Can a low-trust member track moderator availability? Can an app build a work schedule from active state? Can group read receipts reveal who saw a sensitive report? Can bridges or bots replay typing and receipt events into another platform? If the answer is yes, the product needs clearer controls, narrower scopes, shorter retention, or safer defaults for sensitive rooms.