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 all 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
56 changes: 56 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,56 @@
# MSC3026: `busy` presence state

The current specification for [presence](https://spec.matrix.org/v1.3/client-server-api/#presence) in Matrix describes three states:

* `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..
Comment on lines +22 to +25
Copy link
Member

Choose a reason for hiding this comment

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

matrix-org/synapse#12213 asserts that only the /presence API can be used to set busy and that subsequent /sync calls after a user is set to busy should not revert a user to online automatically. I don't think this makes sense and it would be a lot clearer for a client to sync with set_presence=busy if it is still busy. This would give /sync?set_presence=? and /presence the same "power" and not different behavior.

I don't think this MSC could be merged without either documenting the Synapse implementation or a clarification of the MSC.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think this probably does make sense - my basic understanding of it was that the presence API is the 'user level' presence and the sync is the 'device level' presence, so previously the user is busy rather than a device, but this would just be switching to say that a device is busy (which perhaps makes more sense: the user is on a call on a specific device).


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). This is because there are some valid use cases for the user not
Comment on lines +28 to +30
Copy link
Member

@anoadragon453 anoadragon453 Nov 7, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

Even though it's obvious, we may also want to explicitly state that homeservers shouldn't update a user's presence state to "online" if activity is detected.

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.
Comment on lines +27 to +34
Copy link
Member

Choose a reason for hiding this comment

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

Synapse (at least) also transitions users to offline in some situations (e.g. if the user stops syncing and enough time has passed). This still seems somewhat valid (e.g. if a device just disappears forever without transition off busy then you at some point want to transition the account to something else).


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

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.