matrix-spec-proposals icon indicating copy to clipboard operation
matrix-spec-proposals copied to clipboard

MSC3026: "busy" presence state

Open babolivier opened this issue 3 years ago • 12 comments

Rendered

Synapse implementation: https://github.com/matrix-org/synapse/pull/9644 Element Android implementation: https://github.com/vector-im/element-android/pull/6047 Element Web implementation: https://github.com/matrix-org/matrix-react-sdk/pull/8043

FCP proposal: https://github.com/matrix-org/matrix-spec-proposals/pull/3026#issuecomment-1189225918

babolivier avatar Feb 23 '21 17:02 babolivier

~~I dont think this proposal is a good idea, the idea is sound (add a "Do not Disturb" status to matrix), but i think this should be implemented on a different level, because the current status "tag" sent via sync is mostly to signal what the individual client's online / afk / offline ("dont update state") state is.~~

~~How would this exactly change the behaviour of that in such fashion? If a server has 2 clients, one sending "online", another sending "unavailable", the server previously chooses the "best" status, i.e. the "online" state, and sees that as a canonical state.~~

~~But what if there are 3 clients with 3 states, "online", "unavailable", and "busy", which state is canonical? Is busy "above" online, does it mean that one client can keep sending "busy", which changes the presence every time it does a sync, with no way of manually turning off that client's status ("hey, please stop sending busy, i cant set myself to 'just online' again").~~

~~I think this clashes with what the idea of presence has always been, this reminds me of early discord, where early on there was only "online", "idle", and "offline", and no way to set your manual status. I think it's a much better idea to have a separate MSC which properly outlines a way for clients to "put" a "overriding" state, which is then visible to every client, and editable to every client. This would make that state canonical, and the server sends it across federation whenever one of the clients sends a sync with non-"offline" client-status.~~

Edit: hold up, i have made a massive oversight, more edits incoming

Edit 2: i've looked again at the spec, PUT /_matrix/client/r0/presence/{userId}/status exists, which is ideal.

Revised suggestion: I suggest adding or changing 3 things;

  • calling for a clarification for "presence", i.e. that set_presence in /sync only pertains to the client-local presence announcement, which is only for the server to then use when considering if a client is online, and then to send the actual presence.

  • making it clear that this MSC only changes values valid for /client/r0/presence/[...], i.e. that this is an "custom" presence, that this is sent instead of online or unavailable/"idle", but is not sent if all clients are offline.

presence is then calculated as follows;

  • when no client is active or sending one of [unavailable, online], set offline
  • when all client are sending unavailable (or offline), and no custom presence is set, set unavailable
  • when one or more clients are sending online, and no custom presence is set, set online
  • when clients are sending one of [unavailable, online], but a custom presence is set, send custom presence

custom presence then can be a java-dot-notated value, i.e. m.busy, org.example.out_of_office, a free field.

ShadowJonathan avatar Feb 23 '21 19:02 ShadowJonathan

Hi @ShadowJonathan, and thanks for your comment. For context, this is meant to be just a small change to the existing presence semantics we want to make to support work we're doing on improving the user experience around VoIP in Matrix (though as the MSC mentions this addition could serve other purposes). What you seem to have in mind is a greater overall of Matrix's presence feature, which is great, but should probably be its own MSC as it doesn't serve the same purpose or the same scope as this MSC.

(also can you use threads for reviews in the future please, to avoid clobbering up the timeline)

babolivier avatar Feb 24 '21 07:02 babolivier

We are testing this and it's working fine for us on productive systems, when will it be "merged"?

chagai95 avatar Jul 08 '22 14:07 chagai95

@turt2live was the needs-implementation label added due to a lack of an open-source client implementation?

anoadragon453 avatar Jul 08 '22 17:07 anoadragon453

@turt2live was the needs-implementation label added due to a lack of an open-source client implementation?

that seems believable, yes. Ideally we see the demand from clients for a feature like this to better prioritize it.

We are testing this and it's working fine for us on productive systems, when will it be "merged"?

updates on MSCs are best asked in the #sct-office:matrix.org room so we can more easily see what people are concerned about.

turt2live avatar Jul 08 '22 18:07 turt2live

here is the open source implementation on Android: https://github.com/vector-im/element-android/pull/6047

add presence indicator busy and awa

chagai95 avatar Jul 12 '22 09:07 chagai95

Here is web: https://github.com/matrix-org/matrix-react-sdk/pull/8043

chagai95 avatar Jul 12 '22 09:07 chagai95

The author believes this is ready for FCP, and I don't see outstanding blockers for that happening - adding to the pile for the team to consider FCP.

turt2live avatar Jul 12 '22 15:07 turt2live

@mscbot fcp merge

anoadragon453 avatar Jul 19 '22 15:07 anoadragon453

This FCP proposal has been cancelled by https://github.com/matrix-org/matrix-spec-proposals/pull/3026#issuecomment-1234772256.

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

  • [ ] @dbkr
  • [ ] @uhoreg
  • [ ] @turt2live
  • [ ] @ara4n
  • [x] @anoadragon453
  • [ ] @richvdh
  • [ ] @erikjohnston
  • [ ] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

mscbot avatar Jul 19 '22 15:07 mscbot

Thanks for the comments, I'll try to make some time to address them soon.

babolivier avatar Aug 16 '22 15:08 babolivier

After talking to the author, this isn't the author's current priority. It's hard to make progress on this from the SCT side in this state, so removing from FCP for now - we can always restart FCP when someone is able to pick this up :)

@mscbot fcp cancel

turt2live avatar Sep 01 '22 20:09 turt2live