Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MSC3026: "busy" presence state #3026

Open
wants to merge 7 commits into
base: old_master
Choose a base branch
from
Open

MSC3026: "busy" presence state #3026

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
8fcecdc
MSC3026: "busy" presence state
babolivier Feb 23, 2021
69c273c
Wrap lines
babolivier Feb 23, 2021
c03419c
Mention MSC number in the unstable prefix
babolivier Mar 12, 2021
2a34e2e
Incorporate review
babolivier Mar 18, 2021
d617090
Merge branch 'babolivier/msc_presence_busy' of github.com:matrix-org/…
babolivier Mar 18, 2021
912de13
Wrap lines
babolivier Mar 18, 2021
cd3c14f
Update proposals/3026-presence-busy.md
babolivier Aug 16, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions proposals/3026-presence-busy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# `busy` presence state

The current specification for presence in Matrix describes three states:
babolivier marked this conversation as resolved.
Show resolved Hide resolved

* `online` if the user is online and active
* `unavailable` (aka idle or away) if the user is online but inactive
* `offline` if the user is offline

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).


## Proposal

A new presence state is added, `busy`, which describes a state where the user is
babolivier marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I don't have an objection to adding busy in particular, this raises the larger question of what presence states we should have. Is it sufficient to just add busy, or do should we be adding more? For example, XMPP defines 6 states (4 states with names, plus a non-specific "online" state when the show element is not present, and a state where the client is offline.) Are we eventually going to want equivalents for XMPP's other states that we're missing? How do we decide where to draw the line?

FWIW, I think that adding a 4th busy state is probably OK. Adding much more than that would be of questionable value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this was basically my feeling too. How is busy different from unavailable? Should we use status messages instead?

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.

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.
babolivier marked this conversation as resolved.
Show resolved Hide resolved

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.
babolivier marked this conversation as resolved.
Show resolved Hide resolved


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec says that the server aggregates presence data across devices, which I assume means that, e.g. if a user has one device that's online and another that's offline, then the user is marked as online. How does busy fit into this? If a user has a device that's online, and one that's busy, what m.presence event should be sent to others? I think that my expectation would be that busy would take precedence over online.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure it does in the current implementation. There seems to be one api end point for presence that was overlooked so we disabled it on our forks but when the online state comes through a sync it is ignored by synapse - matrix-org/synapse#12213

## Potential issues

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.


## Unstable prefix

Until this proposal is merged into a stable version of the Matrix specification,
implementations must use `org.matrix.msc3026.busy` instead of `busy` as the new presence
state.