From 8fcecdc71caa27459cf46b3004e4e4d84fc7b2ef Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Tue, 23 Feb 2021 18:56:18 +0100 Subject: [PATCH 1/6] MSC3026: "busy" presence state --- proposals/3026-presence-busy.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 proposals/3026-presence-busy.md diff --git a/proposals/3026-presence-busy.md b/proposals/3026-presence-busy.md new file mode 100644 index 00000000000..a2e5dc28a21 --- /dev/null +++ b/proposals/3026-presence-busy.md @@ -0,0 +1,28 @@ +# `busy` presence state + +The current specification for 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 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. + +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. + + +## 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.busy` instead of `busy` as the new presence state. From 69c273cfa67ee9f33288de9d7eca6af6f19ad4f2 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Tue, 23 Feb 2021 19:06:07 +0100 Subject: [PATCH 2/6] Wrap lines --- proposals/3026-presence-busy.md | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/proposals/3026-presence-busy.md b/proposals/3026-presence-busy.md index a2e5dc28a21..6aa0939b912 100644 --- a/proposals/3026-presence-busy.md +++ b/proposals/3026-presence-busy.md @@ -6,23 +6,44 @@ The current specification for presence in Matrix describes three states: * `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). +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 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. +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. -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. +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. -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, 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. ## 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. +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.busy` instead of `busy` as the new presence state. +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. From c03419c0f12ad77d4d0a8d13576375b13c08f324 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Fri, 12 Mar 2021 17:11:56 +0100 Subject: [PATCH 3/6] Mention MSC number in the unstable prefix --- proposals/3026-presence-busy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3026-presence-busy.md b/proposals/3026-presence-busy.md index 6aa0939b912..9426c01b929 100644 --- a/proposals/3026-presence-busy.md +++ b/proposals/3026-presence-busy.md @@ -45,5 +45,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.busy` instead of `busy` as the new presence +implementations must use `org.matrix.msc3026.busy` instead of `busy` as the new presence state. From 2a34e2e14da8ae6f59980f2073a44d4b6f48cbde Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 18 Mar 2021 11:07:30 +0100 Subject: [PATCH 4/6] Incorporate review --- proposals/3026-presence-busy.md | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/proposals/3026-presence-busy.md b/proposals/3026-presence-busy.md index 6aa0939b912..d3781295e6d 100644 --- a/proposals/3026-presence-busy.md +++ b/proposals/3026-presence-busy.md @@ -1,4 +1,4 @@ -# `busy` presence state +# MSC3026: `busy` presence state The current specification for presence in Matrix describes three states: @@ -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 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. - -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. +`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, 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. ## Potential issues From 912de13e4cdaa5705d79475e87314a42be2022a5 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 18 Mar 2021 11:08:16 +0100 Subject: [PATCH 5/6] Wrap lines --- proposals/3026-presence-busy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3026-presence-busy.md b/proposals/3026-presence-busy.md index 9b75dba142d..a90ea717863 100644 --- a/proposals/3026-presence-busy.md +++ b/proposals/3026-presence-busy.md @@ -52,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. From cd3c14f113d89c6c16e953b246e65a6bfa4d9c58 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Tue, 16 Aug 2022 17:57:48 +0200 Subject: [PATCH 6/6] Update proposals/3026-presence-busy.md Co-authored-by: Hubert Chathi --- proposals/3026-presence-busy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3026-presence-busy.md b/proposals/3026-presence-busy.md index a90ea717863..0a135e34f40 100644 --- a/proposals/3026-presence-busy.md +++ b/proposals/3026-presence-busy.md @@ -1,6 +1,6 @@ # MSC3026: `busy` presence state -The current specification for presence in Matrix describes three states: +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