matrix-spec-proposals
matrix-spec-proposals copied to clipboard
MSC3026: "busy" presence state
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
~~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 ofonline
orunavailable
/"idle", but is not sent if all clients areoffline
.
presence is then calculated as follows;
- when no client is active or sending one of
[unavailable, online]
, setoffline
- when all client are sending
unavailable
(or offline), and no custom presence is set, setunavailable
- when one or more clients are sending
online
, and no custom presence is set, setonline
- 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.
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)
We are testing this and it's working fine for us on productive systems, when will it be "merged"?
@turt2live was the needs-implementation
label added due to a lack of an open-source client implementation?
@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.
here is the open source implementation on Android: https://github.com/vector-im/element-android/pull/6047
Here is web: https://github.com/matrix-org/matrix-react-sdk/pull/8043
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.
@mscbot fcp merge
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.
Thanks for the comments, I'll try to make some time to address them soon.
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