Merge fbd30a98ac
into ecf996389f
commit
81588cbc7a
@ -0,0 +1,59 @@
|
||||
MSC3032: Thoughts on updating presence
|
||||
======================================
|
||||
|
||||
This is deliberately a loose-form, draft MSC to note down my current thoughts
|
||||
on how we might improve the presence system and integrate it with
|
||||
profiles-as-rooms (MSC1769).
|
||||
|
||||
## `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`
|
||||
object because it's intended to be updated fairly frequently and we don't need
|
||||
to update the whole profile each time (this would be inefficient and risk data
|
||||
races).
|
||||
|
||||
`presence` stays, with the additional value of `busy` as per MSC3026, but this
|
||||
endpoint is explicitly for the *user* setting their presence manually, eg. selecting
|
||||
'busy' or 'unavailable' from a checkbox in the UI.
|
||||
|
||||
## `set_presence` in `/sync`
|
||||
This is differentiated from `PUT /_matrix/client/r0/presence/{userId}/status`
|
||||
by being explicitly for automatic updates from clients, eg.:
|
||||
* A client supplies `unavailable` if it doesn't believe the user is paying attention
|
||||
(eg. they haven't moved the mouse ina while).
|
||||
* A client supplies `busy` if the user is on a call in that client.
|
||||
|
||||
## Effective presence
|
||||
The homeserver can then combine the multiple sources of presence information from
|
||||
the clients and the user-set value to determine an effective presence for the user.
|
||||
This is a black-box as far as the spec is concerned, but semantics will be along
|
||||
the lines of 'if any status is busy, the user is busy'.
|
||||
|
||||
Question: if a user sets themselves 'busy', what status do they set when they're
|
||||
free again? 'online'?
|
||||
|
||||
## Publishing presence
|
||||
Homeservers take the effective presence and publish it as an `m.presence` state
|
||||
event in the user's profile room. You subscribe to a user's presence by peeking
|
||||
into their profile room.
|
||||
|
||||
m.presence events go away entirely after some deprecation period.
|
||||
|
||||
Question: How would we restrict the set of people allowed to see presence
|
||||
info (ie. assuming we allow a wider set of people to see the user's profile)
|
||||
Question: What happens if a user send an `m.presence`event to their profile room?
|
||||
Should they be allowed to?
|
||||
|
||||
## `GET /_matrix/client/r0/presence/{userId}/status`
|
||||
Also goes away.
|
||||
|
||||
## Presence for the smartphone generation
|
||||
The presence status enum was designed in a time when smartphones were relatively
|
||||
new and it was still assumed that if you weren't at your computer, you were
|
||||
unavailable. This isn't true now we all carry our computers in our pockets.
|
||||
This probably requires only a small change in how we interpret the values though:
|
||||
* `online`: Actively using a client right this moment
|
||||
* `unavailable`: No particular status / default. It's assumed the user may be
|
||||
available and respond if you message them, or maybe not.
|
||||
* `busy`: Unavailable to talk.
|
||||
* `offline`: It should be assumed that messages won't reach the user.
|
Loading…
Reference in New Issue