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.

Sign up for GitHub

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

Jump to bottom

MSC4043: Presence Override API #4043

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

MSC4043: Presence Override API #4043

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
4143e2f
Initial Commit
FSG-Cat Aug 10, 2023
82302d7
remove leftover template text from unstable section
FSG-Cat Aug 10, 2023
f880934
Rename MSC and update MSC to use MSC numbers instead of placeholders
FSG-Cat Aug 10, 2023
fda11ae
Add Empty Key to disable override section
FSG-Cat Aug 11, 2023
e622c5b
Fix unstable API path oversight
FSG-Cat Aug 19, 2023
7d1b014
Update reference to MSC4042 to be a link
FSG-Cat Feb 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions proposals/4043-presence-override-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# 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.


In current matrix there exists no mechanism that is reliable to override the supposed to exist totem pole
for presence. Where more important states overrule less important ones. This proposal fixes that.

This proposal proposes a new API that you can call to set a authoritative presence state for your account. This
state is always used negating all other ways to set presence. So if you set your state to `disabled` from
MSC4042 then well then your state would always be `disabled`.
FSG-Cat marked this conversation as resolved.
Show resolved Hide resolved

Using a new API for this instead of recycling some old method does come at the benefit of that this just works.

No existing code can mess up and use this wrong to effectively ruin the whole point of this system because its new.

Being able to set your authoritative presence state is seen as beneficial due to that it allows users to have full
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.


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

}
```
Comment on lines +20 to +27
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.


The `presence_override` key used is whatever you want to force your presence to be.

If you want to ask for what your current override is you simply make a GET request to the same endpoint.

And you will get back a response that is like the example below if your override is `offline`.

```json
{
"presence_override": "offline"
}
```

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.

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

that clients that don't support this feature will not be able to set the override status for the user.

## Alternatives

There are talks about that certain existing presence mechanisms might have this as their intended functionality but
as is addressed at the top of this proposal they have a viability problem in the fact that they are all existing
mechanisms. Existing mechanisms being reused can lead to clients with bad implementations misusing them
causing the mechanism to be rendered useless.

A completely new API comes with the benefit that no legacy implementations can ruin everyone's experience.

## Security considerations

This proposal should not as far as the author is aware have security implications that are negative. The primary
positive effect is privacy related not strictly security in that users can cloak their presence state reliably.

## Unstable prefix

While this proposal is unstable instead of using `/_matrix/client/v1/presence/{userId}/override` you use
`/_matrix/client/unstable/support.feline.msc4043.v1/override`
FSG-Cat marked this conversation as resolved.
Show resolved Hide resolved

And unstable feature flag used is `support.feline.msc4043.v1`

## Dependencies

This MSC has MSC4042 as a soft dependency as its a very useful state to override to.
This MSC has no hard dependencies and can be used on its own and merged on its own.
Loading