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
29 changes: 18 additions & 11 deletions proposals/3026-presence-busy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# `busy` presence state
# MSC3026: `busy` presence state

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

Expand All @@ -22,17 +22,24 @@ 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
joins a call or a Jitsi group call, etc..

If a user's presence is set to `busy`, it is strongly recommended for
babolivier marked this conversation as resolved.
Show resolved Hide resolved
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.
`online` state). This is because 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, and because such automation while taking the specific
semantics of the `busy` state into account is complex when the user is using
multiple devices.

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.
For backwards compatibility, servers implementing this MSC must expose a flag in
`/_matrix/client/versions` responses, under `unstable_features`, named
`org.matrix.msc3026.busy_presence`, which is set to `true`. Before setting a
user's presence to `busy`, clients must check the presence of this flag and that
it's set to `true`. If it's not, clients should fall back to setting the user's
presence state to `unavailable`, which is the closest state to `busy`
semantically.
Comment on lines +36 to +42
Copy link
Member

Choose a reason for hiding this comment

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

This sort of backwards compatibility would go in the unstable prefix section - clients (now) can use spec versions to detect support otherwise.



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
Expand All @@ -45,5 +52,5 @@ 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.
implementations must use `org.matrix.msc3026.busy` instead of `busy` as the new
presence state.