f295e828dc
As "unstable" changes and "latest" becomes no more, these sorts of links should be updated to reference the approximate section they intended to reference at the time of writing. This change tries to link up the relevant bits for the time of the proposal, though it's not a perfect match. Some MSCs were brought into the spec before an API version could be assigned to the "old" text, so github permalinks are used instead.
55 lines
2.3 KiB
Markdown
55 lines
2.3 KiB
Markdown
# Remove references to presence lists
|
|
|
|
[Presence](https://matrix.org/docs/spec/client_server/r0.4.0.html#id107) lists
|
|
allow a given user the ability to subscribe to other users and be alerted to
|
|
their current presence status.
|
|
|
|
While spec'd, no established client has implemented support and the only server
|
|
side implementation raises privacy concerns.
|
|
|
|
The proposal is to simply remove references to presence lists with a view to
|
|
revisiting the same ideas in the future.
|
|
|
|
This MSC addresses
|
|
[#1810](https://github.com/matrix-org/matrix-doc/issues/1810)
|
|
|
|
## Proposal
|
|
|
|
Presence lists seem like a good fit for ['MSC1769: Extensible profiles as
|
|
rooms'](https://github.com/matrix-org/matrix-doc/pull/1769) proposal, meaning
|
|
that the current design will most likely be superceded.
|
|
|
|
Additionally, no major client has implemented the behaviour to date and the
|
|
only server implementation of presence lists (Synapse) auto-accepts invites
|
|
leading to privacy concerns in the wild.
|
|
|
|
With this in mind the most pragmatic solution is to remove presence lists ahead
|
|
of the r0 release.
|
|
|
|
Specifically:-
|
|
|
|
CS API: Remove
|
|
* [POST
|
|
/_matrix/client/r0/presence/list/{userId}](https://matrix.org/docs/spec/client_server/r0.4.0.html#post-matrix-client-r0-presence-list-userid)
|
|
* [GET
|
|
/_matrix/client/r0/presence/list/{userId}](https://matrix.org/docs/spec/client_server/r0.4.0.html#get-matrix-client-r0-presence-list-userid)
|
|
|
|
SS API: Remove
|
|
* [m.presence_invite](https://github.com/matrix-org/matrix-doc/blob/8b65da1cf6fce5f657a2a46b5c6c8bcc24d32ae3/api/server-server/definitions/event-schemas/m.presence_invite.yaml)
|
|
* [m.presence_accept](https://github.com/matrix-org/matrix-doc/blob/8b65da1cf6fce5f657a2a46b5c6c8bcc24d32ae3/api/server-server/definitions/event-schemas/m.presence_accept.yaml)
|
|
* [m.presence_deny](https://github.com/matrix-org/matrix-doc/blob/8b65da1cf6fce5f657a2a46b5c6c8bcc24d32ae3/api/server-server/definitions/event-schemas/m.presence_deny.yaml)
|
|
|
|
|
|
## Tradeoffs
|
|
|
|
Ideally this proposal would also come with an alternative design for this
|
|
functionality. Out of pragmatism the proposal only covers removal of what is
|
|
there today.
|
|
|
|
|
|
## Conclusions
|
|
|
|
This is a common sense attempt to remove unused portions of the spec ahead of
|
|
an r0 release. It does not suggest that the ability to subscribe to the
|
|
presence of others is undesirable and assumes that this behvaiour will return
|
|
again in some form.
|