MSC4043: Presence Override API #4043
Conversation
turt2live
added
proposal
| To set a new presence override you call the new `/_matrix/client/v1/presence/{userId}/override` endpoint | ||
| using a PUT request. Using a payload that can look like the example below. | ||
|
|
||
| ```json | ||
| { | ||
| "presence_override": "online" | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Could this be an argument on the current /presence API? Either another body parameter or the keyword parameter. It could default to not-forcing to be backwards compatible.
There was a problem hiding this comment.
Yes that is tbh one possible way to do it. use normal /presence but add a new argument. And ofc yes defaulting to not forcing is logical if we add new functionality since why break backwards compatibility for no reason.
The key problem to solve is some way to get us to a state where we can define a value that is set as the canonical value and therefore skipping the whole Online is more important than offline situation.
And to disable it you send a override that is empty makes sense in this context. Because if the argument is missing that means backwards compatibility mode but argument present but empty means disable override.
| @@ -0,0 +1,81 @@ | |||
| # MSC4043: Presence Override API | |||
There was a problem hiding this comment.
I'm keen for something like this. It would scratch a serious itch with current bridges where we have to repeatedly set the presence every N seconds (where N is a value that Synapse hard codes...) to keep presence "alive".
I don't think this is even what I'd call an override, but an alternative and valid way to update your presence for clients that do not fall under the traditional syncing system (a.k.a, anything that doesn't call /sync).
There was a problem hiding this comment.
Isnt PUT /_matrix/client/v3/presence/{userId}/status the API that you use if you want to set presence in a non Syncing way?
But if you mean that the API mentioned earlier has the problem with every N seconds then yes this would help bridges.
My only concern is for some bridges where they access your own account to make a seamless experience those bridges would not be able to use this at the same time as the user is using it. Tho for those bridges that can easily be a user preference option so that concern is probably in implementation detail land.
The bridges that are not sharing their accounts can use this API in the exact same way as anyone else without conflict concerns.
|
|
||
| ## Potential issues | ||
|
|
||
| Other than this functionality being duplicate the author does not foresee any potential issues other than |
There was a problem hiding this comment.
This is adding additional complexity to an already complex system, so there is definitely a scare here that making presense harder to implement for homeservers might be tricky.
| control over their presence status instead of having to rely on all clients on their account collaborating to not | ||
| ruin the intention of the user. | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
My naive understanding of presence is that whenever a user updates their presence, the presence is then sent round to every interested server and user.
Obviously this API sets a static presence, so wouldn't be sent out more than once. How would this interaction work with other users and homeservers which presumably expect presence to be short lived? Does the homeserver need to repeatedly announce the presence, or does the federation API need extending?
There was a problem hiding this comment.
Sidenote: I think we should really have a key in presence updates that specify a ttl, with 0 being a valid way to say presence is valid until a new updates appears.
There was a problem hiding this comment.
Yes that is indeed a problem how to solve remotes issue if we dont resend every X. A Presence TTL definetively makes sense and 0 being valid until otherwise noted makes sense.
I mean i have a rough draft sitting in the drawer for a solution to this but i think its a bit too radical to move all of presence to be until i say otherwise like that draft is.
For now i will note that a possible solution to the federation problem is to have the homeserver re emit presence for the user every X and leave X as an implementation detail. Because that way this would work over federation in a backwards compatible way. This also makes it so your presence heals from EDUs vanishing into the ether etc.
|
|
||
| ```json | ||
| { | ||
| "presence_override": "online" |
There was a problem hiding this comment.
Is there any reason not to include status_msg, and have that persist too? This would make it compatible with the existing presence system
There was a problem hiding this comment.
Now that you mention it status has the exact same problem as presence it self currently so it makes sense to include. Yes its tbh a oversight and me thinking of a too narrow scope.
|
|
||
| As for error codes this is currently WIP but it follows a similar pattern to the current `/_matrix/client/v3/presence/{userId}/status` | ||
| endpoint. With minor reasonable adaptations like how presence is replaced with presence override where sensible. | ||
|
|
There was a problem hiding this comment.
Unsure if this is relevant in this MSC, but presumably user deactivation voids the presence status?
There was a problem hiding this comment.
I would agree that since Deactivation voids a lot of other data like this its only fair to include that deactivation voids this too.
Co-authored-by: Will Hunt <[email protected]>
Co-authored-by: Hubert Chathi <[email protected]>
Rendered
This MSC adds a new API that lets you force a specific presence state.
Signed-off-by: Catalan Lover [email protected]