From c93839ef4722372d429ef9353bb55a7f4d687fbf Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 25 Feb 2021 14:08:57 +0000 Subject: [PATCH 1/5] Very, very draft MSC on how presence could look --- proposals/xxxx-presence-revamp.md | 61 +++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 proposals/xxxx-presence-revamp.md diff --git a/proposals/xxxx-presence-revamp.md b/proposals/xxxx-presence-revamp.md new file mode 100644 index 00000000..4557049b --- /dev/null +++ b/proposals/xxxx-presence-revamp.md @@ -0,0 +1,61 @@ +MSCXXXX: Thoughts on updating presence +====================================== + +This is deliberately a loose-form, draft MSC to note down my current thoughts +on how we might improve the presence system and integrate it with +profiles-as-rooms (MSC1769). + +`PUT /_matrix/client/r0/presence/{userId}/status` +=============================================== +`status_msg` becomes deprecated. In it's place there's a new state event in the +user's MSC1769 profile room, `m.status`. It's not a field in the `m.profile` +object because it's intended to be updated fairly frequently and we don't need +to update the whole profile each time (this would be inefficient and risk data +races). + +`presence` stays, with the additional value of `busy` as per MSC3026, but this +endpoint is explicitly for the *user* setting their presence manually, eg. selecting +'busy' or 'unavailable' from a checkbox in the UI. + +`set_presence` in `/sync` +========================= +This is differentiated from `PUT /_matrix/client/r0/presence/{userId}/status` +by being explicitly for automatic updates from clients, eg.: + * A client supplies `unavailable` if it doesn't believe the user is paying attention + (eg. they haven't moved the mouse ina while). + * A client supplies `busy` if the user is on a call in that client. + +Effective presence +================== +The homeserver can then combine the multiple sources of presence information from +the clients and the user-set value to determine an effective presence for the user. +This is a black-box as far as the spec is concerned, but semantics will be along +the lines of 'if any status is busy, the user is busy`. + +Question: if a user sets themselves 'busy', what status do they set when they're +free again? 'online'? + +Publishing presence +=================== +Homeservers take the effective presence and publish it as an `m.presence` state +event in the user's profile room. You subscribe to a user's presence by peeking +into their profile room. + +m.presence events go away entirely after some deprecation period. + +Question: How would we restrict the set of people allowed to see presence + info (ie. assuming we allow a wider set of people to see the user's profile) +Question: What happens if a user send an `m.presence`event to their profile room? + Should they be allowed to? + +Presence for the smartphone generation +====================================== +The presence status enum was designed in a time when smartphones were relatively +new and it was still assumed that if you weren't at your computer, you were +unavailable. This isn't true now we all carry our computers in our pockets. +This probably requires only a small change in how we interpret the values though: + * `online`: Actively using a client right this moment + * `unavailable`: No particular status / default. It's assumed the user may be + available and respond if you message them, or maybe not. + * `busy`: Unavailable to talk. + * `offline`: It should be assumed that messages won't reach the user. From 5d3e3042d746df4e5655ffc78c760633212b0199 Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 25 Feb 2021 14:10:53 +0000 Subject: [PATCH 2/5] remove another api --- proposals/xxxx-presence-revamp.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposals/xxxx-presence-revamp.md b/proposals/xxxx-presence-revamp.md index 4557049b..4d7083d6 100644 --- a/proposals/xxxx-presence-revamp.md +++ b/proposals/xxxx-presence-revamp.md @@ -6,7 +6,7 @@ on how we might improve the presence system and integrate it with profiles-as-rooms (MSC1769). `PUT /_matrix/client/r0/presence/{userId}/status` -=============================================== +================================================= `status_msg` becomes deprecated. In it's place there's a new state event in the user's MSC1769 profile room, `m.status`. It's not a field in the `m.profile` object because it's intended to be updated fairly frequently and we don't need @@ -48,6 +48,10 @@ Question: How would we restrict the set of people allowed to see presence Question: What happens if a user send an `m.presence`event to their profile room? Should they be allowed to? +`GET /_matrix/client/r0/presence/{userId}/status` +================================================= +Also goes away. + Presence for the smartphone generation ====================================== The presence status enum was designed in a time when smartphones were relatively From 3628fe9b9c829440a312265cb439df296e98e0fb Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 25 Feb 2021 14:13:22 +0000 Subject: [PATCH 3/5] msc number --- proposals/{xxxx-presence-revamp.md => 3032-presence-revamp.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-presence-revamp.md => 3032-presence-revamp.md} (98%) diff --git a/proposals/xxxx-presence-revamp.md b/proposals/3032-presence-revamp.md similarity index 98% rename from proposals/xxxx-presence-revamp.md rename to proposals/3032-presence-revamp.md index 4d7083d6..6715939d 100644 --- a/proposals/xxxx-presence-revamp.md +++ b/proposals/3032-presence-revamp.md @@ -1,4 +1,4 @@ -MSCXXXX: Thoughts on updating presence +MSC3032: Thoughts on updating presence ====================================== This is deliberately a loose-form, draft MSC to note down my current thoughts From 6b50cc1105683c24cc10aaf3ad812f46f3c79e5f Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 25 Feb 2021 14:16:39 +0000 Subject: [PATCH 4/5] Too loud, man --- proposals/3032-presence-revamp.md | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/proposals/3032-presence-revamp.md b/proposals/3032-presence-revamp.md index 6715939d..601da03e 100644 --- a/proposals/3032-presence-revamp.md +++ b/proposals/3032-presence-revamp.md @@ -5,8 +5,7 @@ This is deliberately a loose-form, draft MSC to note down my current thoughts on how we might improve the presence system and integrate it with profiles-as-rooms (MSC1769). -`PUT /_matrix/client/r0/presence/{userId}/status` -================================================= +## `PUT /_matrix/client/r0/presence/{userId}/status` `status_msg` becomes deprecated. In it's place there's a new state event in the user's MSC1769 profile room, `m.status`. It's not a field in the `m.profile` object because it's intended to be updated fairly frequently and we don't need @@ -17,16 +16,14 @@ races). endpoint is explicitly for the *user* setting their presence manually, eg. selecting 'busy' or 'unavailable' from a checkbox in the UI. -`set_presence` in `/sync` -========================= +## `set_presence` in `/sync` This is differentiated from `PUT /_matrix/client/r0/presence/{userId}/status` by being explicitly for automatic updates from clients, eg.: * A client supplies `unavailable` if it doesn't believe the user is paying attention (eg. they haven't moved the mouse ina while). * A client supplies `busy` if the user is on a call in that client. -Effective presence -================== +## Effective presence The homeserver can then combine the multiple sources of presence information from the clients and the user-set value to determine an effective presence for the user. This is a black-box as far as the spec is concerned, but semantics will be along @@ -35,8 +32,7 @@ the lines of 'if any status is busy, the user is busy`. Question: if a user sets themselves 'busy', what status do they set when they're free again? 'online'? -Publishing presence -=================== +## Publishing presence Homeservers take the effective presence and publish it as an `m.presence` state event in the user's profile room. You subscribe to a user's presence by peeking into their profile room. @@ -48,12 +44,10 @@ Question: How would we restrict the set of people allowed to see presence Question: What happens if a user send an `m.presence`event to their profile room? Should they be allowed to? -`GET /_matrix/client/r0/presence/{userId}/status` -================================================= +## `GET /_matrix/client/r0/presence/{userId}/status` Also goes away. -Presence for the smartphone generation -====================================== +## Presence for the smartphone generation The presence status enum was designed in a time when smartphones were relatively new and it was still assumed that if you weren't at your computer, you were unavailable. This isn't true now we all carry our computers in our pockets. From fbd30a98ac162205496dafdd9b96d6b5d1d6173a Mon Sep 17 00:00:00 2001 From: David Baker Date: Fri, 26 Feb 2021 09:56:00 +0000 Subject: [PATCH 5/5] typo Co-authored-by: Sorunome --- proposals/3032-presence-revamp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3032-presence-revamp.md b/proposals/3032-presence-revamp.md index 601da03e..177ba9fb 100644 --- a/proposals/3032-presence-revamp.md +++ b/proposals/3032-presence-revamp.md @@ -27,7 +27,7 @@ by being explicitly for automatic updates from clients, eg.: The homeserver can then combine the multiple sources of presence information from the clients and the user-set value to determine an effective presence for the user. This is a black-box as far as the spec is concerned, but semantics will be along -the lines of 'if any status is busy, the user is busy`. +the lines of 'if any status is busy, the user is busy'. Question: if a user sets themselves 'busy', what status do they set when they're free again? 'online'?