Presence
Each user has the concept of presence information. This encodes:
- Whether the user is currently online
- How recently the user was last active (as seen by the server)
- Whether a given client considers the user to be currently idle
- Arbitrary information about the user’s current status (e.g. “in a meeting”).
This information is collated from both per-device (online
, idle
,
last_active
) and per-user (status) data, aggregated by the user’s
homeserver and transmitted as an m.presence
event. Presence events are
sent to interested parties where users share a room membership.
User’s presence state is represented by the presence
key, which is an
enum of one of the following:
online
: The default state when the user is connected to an event stream.unavailable
: The user is not reachable at this time e.g. they are idle.offline
: The user is not connected to an event stream or is explicitly suppressing their profile information from being sent.
Events
m.presence
Informs the client of a user’s presence state change.
Event type: | Message event |
---|
Content
Name | Type | Description |
---|---|---|
avatar_url |
string |
The current avatar URL for this user, if any. |
currently_active |
boolean |
Whether the user is currently active |
displayname |
string |
The current display name for this user, if any. |
last_active_ago |
number |
The last time since this used performed some action, in milliseconds. |
presence |
enum |
Required: The presence state for this user. One of: |
status_msg |
string |
An optional description to accompany the presence. |
Examples
{
"content": {
"avatar_url": "mxc://localhost:wefuiwegh8742w",
"currently_active": false,
"last_active_ago": 2478593,
"presence": "online",
"status_msg": "Making cupcakes"
},
"sender": "@example:localhost",
"type": "m.presence"
}
Client behaviour
Clients can manually set/get their presence using the HTTP APIs listed below.
GET /_matrix/client/r0/presence/{userId}/status
Get the given user’s presence state.
Rate-limited: | No |
---|---|
Requires authentication: | Yes |
Request
Request parameters
Name | Type | Description |
---|---|---|
userId |
string |
Required: The user whose presence state to get. |
Responses
Status | Description |
---|---|
200 |
The presence state for this user. |
403 |
You are not allowed to see this user’s presence status. |
404 |
There is no presence state for this user. This user may not exist or isn’t exposing presence information to you. |
200 response
Name | Type | Description |
---|---|---|
currently_active |
boolean |
Whether the user is currently active |
last_active_ago |
integer |
The length of time in milliseconds since an action was performed by this user. |
presence |
enum |
Required: This user’s presence. One of: |
status_msg |
[string null] |
The state message for this user if one was set. |
{
"last_active_ago": 420845,
"presence": "unavailable"
}
403 response
Name | Type | Description |
---|---|---|
errcode |
string |
Required: An error code. |
error |
string |
A human-readable error message. |
{
"errcode": "M_FORBIDDEN",
"error": "You are not allowed to see their presence"
}
404 response
Name | Type | Description |
---|---|---|
errcode |
string |
Required: An error code. |
error |
string |
A human-readable error message. |
{
"errcode": "M_UNKNOWN",
"error": "An unknown error occurred"
}
PUT /_matrix/client/r0/presence/{userId}/status
This API sets the given user’s presence state. When setting the status,
the activity time is updated to reflect that activity; the client does
not need to specify the last_active_ago
field. You cannot set the
presence state of another user.
last_active_ago
field. You cannot set the
presence state of another user.Rate-limited: | Yes |
---|---|
Requires authentication: | Yes |
Request
Request parameters
Name | Type | Description |
---|---|---|
userId |
string |
Required: The user whose presence state to update. |
Request body
Name | Type | Description |
---|---|---|
presence |
enum |
Required: The new presence state. One of: |
status_msg |
string |
The status message to attach to this state. |
Request body example
{
"presence": "online",
"status_msg": "I am here."
}
Responses
Status | Description |
---|---|
200 |
The new presence state was set. |
429 |
This request was rate-limited. |
429 response
Name | Type | Description |
---|---|---|
errcode |
string |
Required: The M_LIMIT_EXCEEDED error code |
error |
string |
A human-readable error message. |
retry_after_ms |
integer |
The amount of time in milliseconds the client should wait before trying the request again. |
{
"errcode": "M_LIMIT_EXCEEDED",
"error": "Too many requests",
"retry_after_ms": 2000
}
Last active ago
The server maintains a timestamp of the last time it saw a pro-active
event from the user. A pro-active event may be sending a message to a
room or changing presence state to online
. This timestamp is presented
via a key called last_active_ago
which gives the relative number of
milliseconds since the pro-active event.
To reduce the number of presence updates sent to clients the server may
include a currently_active
boolean field when the presence state is
online
. When true, the server will not send further updates to the
last active time until an update is sent to the client with either a)
currently_active
set to false or b) a presence state other than
online
. During this period clients must consider the user to be
currently active, irrespective of the last active time.
The last active time must be up to date whenever the server gives a
presence event to the client. The currently_active
mechanism should
purely be used by servers to stop sending continuous presence updates,
as opposed to disabling last active tracking entirely. Thus clients can
fetch up to date last active times by explicitly requesting the presence
for a given user.
Idle timeout
The server will automatically set a user’s presence to unavailable
if
their last active time was over a threshold value (e.g. 5 minutes).
Clients can manually set a user’s presence to unavailable
. Any
activity that bumps the last active time on any of the user’s clients
will cause the server to automatically set their presence to online
.
Security considerations
Presence information is shared with all users who share a room with the target user. In large public rooms this could be undesirable.