Skip to content

Commit 8fcecdc

Browse files
committed
MSC3026: "busy" presence state
1 parent e30a717 commit 8fcecdc

File tree

1 file changed

+28
-0
lines changed

1 file changed

+28
-0
lines changed

Diff for: proposals/3026-presence-busy.md

+28
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
# `busy` presence state
2+
3+
The current specification for presence in Matrix describes three states:
4+
5+
* `online` if the user is online and active
6+
* `unavailable` (aka idle or away) if the user is online but inactive
7+
* `offline` if the user is offline
8+
9+
There is currently no presence state to express that the user is online and active, but busy, i.e. in a state that would prevent them from giving their full focus to solicitations from other users. A practical example would be a user that's on a call with another user (or on a group call).
10+
11+
12+
## Proposal
13+
14+
A new presence state is added, `busy`, which describes a state where the user is online and active but is performing an activity that would prevent them from giving their full attention to an external solicitation, i.e. the user is online and active but not available.
15+
16+
It is left to the implementation to decide how to update a user's presence to the `busy` state (and from this state to another); suggestions would include allowing the user to set it manually, setting it automatically when the user joins a call or a Jitsi group call, etc.. It is strongly recommended for implementations to not implement a timer that would trigger an update to the `unavailable` state (like most implementations do when the user is in the `online` state), as there are some valid use cases for the user not triggering any event in the client but still being online and active, e.g. if they're on a call.
17+
18+
For backwards compatibility, if a client fails to update a user's presence state to `busy` because the homeserver doesn't implement this MSC (which would likely translate into a `400 Bad Request` response), it should set the user's presence to `unavailable`, which is the closest state semantically.
19+
20+
21+
## Potential issues
22+
23+
It is unclear whether introducing a new presence state will break some clients that don't implement this MSC yet. If this happens, the mitigation is unclear and open to discussion.
24+
25+
26+
## Unstable prefix
27+
28+
Until this proposal is merged into a stable version of the Matrix specification, implementations must use `org.matrix.busy` instead of `busy` as the new presence state.

0 commit comments

Comments
 (0)