-
Notifications
You must be signed in to change notification settings - Fork 370
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
MSC3032: Thoughts on updating presence #3032
base: old_master
Are you sure you want to change the base?
Conversation
free again? 'online'? | ||
|
||
## Publishing presence | ||
Homeservers take the effective presence and publish it as an `m.presence` state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like turning presences into PDUs? Something like this has been suggested before and has not left many happy, soru still does not think this is the right approach for presences
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hah, yes - good point. Maybe they could be ephemeral events tied to the user profile room?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDUs can't be peaked, though. Not sure how to tackle this / if this should be tackled at all. Like, an effective presence does make sense, but does its transport method have to be changed? Not sure.
@@ -0,0 +1,59 @@ | |||
MSC3032: Thoughts on updating presence |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One issue AS's face with presences is that when setting presences for ghosts they can't set any timeout. What these thoughts are lacking, in sorus opinion, is adding a timeout
query parameter to the setting presence endpoint
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I hadn't even considered ASes - in fact, ASes probably ought to just be another client and use the same endpoint, except of course that endpoint is /sync
... maybe ASes should get their own presence endpoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for a new endpoint if you can just re-use the /status
one with a timeout parameter that can be up to e.g. 24h, that would actually fix all the AS issues
|
||
## `PUT /_matrix/client/r0/presence/{userId}/status` | ||
`status_msg` becomes deprecated. In it's place there's a new state event in the | ||
user's MSC1769 profile room, `m.status`. It's not a field in the `m.profile` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
publishing statuses as state events means that all servers have a cleartext history of all presences stored permanently. This might not be desirable from a privacy point of view.
Soru really gets the benefits of making this a state event, so she isn't sure how to fix this problem.
IMHO the status message should be decoupled from the user's presence state. E.g. if I set an "I'm away from x till y" status message, it should be valid regardless of my presence state and if I a have any active sessions or not. Why not take it one step further and abstract it to any kind of data, storable at the account level? There is already a |
Rendered