Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4043: Presence Override API #4043

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

FSG-Cat
Copy link
Contributor

@FSG-Cat FSG-Cat commented Aug 10, 2023

Rendered

This MSC adds a new API that lets you force a specific presence state.

Signed-off-by: Catalan Lover [email protected]

@FSG-Cat FSG-Cat changed the title MSC4043 Presence Override API MSC4043: Presence Override API Aug 10, 2023
@turt2live turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Aug 10, 2023
Comment on lines +20 to +27
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"
}
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@Half-Shot Half-Shot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of thoughts. As stated I have interest in having this for bridges to address our presence issues too, I think this could work but needs fleshing out.

@@ -0,0 +1,81 @@
# MSC4043: Presence Override API
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason not to include status_msg, and have that persist too? This would make it compatible with the existing presence system

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

proposals/4043-presence-override-api.md Outdated Show resolved Hide resolved

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure if this is relevant in this MSC, but presumably user deactivation voids the presence status?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agree that since Deactivation voids a lot of other data like this its only fair to include that deactivation voids this too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants