Merge pull request #1817 from matrix-org/neilj/remove_presence_lists

remove references to presence lists
pull/977/head
Travis Ralston 6 years ago committed by GitHub
commit e27c83d9f8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -136,103 +136,3 @@ paths:
"$ref": "definitions/errors/error.yaml" "$ref": "definitions/errors/error.yaml"
tags: tags:
- Presence - Presence
"/presence/list/{userId}":
post:
summary: Add or remove users from this presence list.
description: |-
Adds or removes users from this presence list.
operationId: modifyPresenceList
security:
- accessToken: []
parameters:
- in: path
type: string
name: userId
description: The user whose presence list is being modified.
required: true
x-example: "@alice:example.com"
- in: body
name: presence_diff
description: The modifications to make to this presence list.
required: true
schema:
type: object
example: {
"invite": [
"@bob:matrix.org"
],
"drop": [
"@alice:matrix.org"
]
}
properties:
invite:
type: array
description: A list of user IDs to add to the list.
items:
type: string
description: A list of user IDs.
drop:
type: array
description: A list of user IDs to remove from the list.
items:
type: string
description: A list of user IDs.
responses:
200:
description: The list was updated.
examples:
application/json: {
}
schema:
type: object # empty json object
429:
description: This request was rate-limited.
schema:
"$ref": "definitions/errors/rate_limited.yaml"
tags:
- Presence
get:
summary: Get presence events for this presence list.
description: |-
Retrieve a list of presence events for every user on this list.
operationId: getPresenceForList
parameters:
- in: path
type: string
name: userId
description: The user whose presence list should be retrieved.
required: true
x-example: "@alice:example.com"
responses:
200:
description: A list of presence events for this list.
examples:
application/json: [
{
"content": {
"last_active_ago": 395,
"presence": "offline",
"user_id": "@alice:matrix.org"
},
"type": "m.presence"
},
{
"content": {
"last_active_ago": 16874,
"presence": "online",
"user_id": "@marisa:matrix.org",
"currently_active": true
},
"type": "m.presence"
}
]
schema:
type: array
items:
type: object
title: PresenceEvent
allOf:
- "$ref": "definitions/event-schemas/schema/core-event-schema/event.yaml"
tags:
- Presence

@ -21,7 +21,7 @@ description: |-
# FIXME: It's very unclear why we have this API surface for synchronising # FIXME: It's very unclear why we have this API surface for synchronising
# device lists, rather than just using a room (which could also be used for # device lists, rather than just using a room (which could also be used for
# presence lists, profile info, etc). But documenting what we have for now... # profile info, etc). But documenting what we have for now...
allOf: allOf:
- $ref: ../edu.yaml - $ref: ../edu.yaml

@ -1,46 +0,0 @@
# Copyright 2018 New Vector Ltd
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
type: object
title: m.presence_accept
description: |-
An EDU representing approval for the observing user to subscribe to the
presence of the the observed user.
allOf:
- $ref: ../edu.yaml
- type: object
properties:
edu_type:
type: enum
enum: ['m.presence_accept']
description: The string ``m.presence_accept``
example: "m.presence_accept"
content:
type: object
description: The invite information.
title: Invite Information
properties:
observed_user:
type: string
description: |-
The user ID that has approved the ``observer_user`` to
subscribe to their presence.
example: "@alice:elsewhere.com"
observer_user:
type: string
description: |-
The user ID that requested to subscribe to the presence of
the ``observed_user``.
example: "@john:matrix.org"
required: ['observer_user', 'observed_user']

@ -1,55 +0,0 @@
# Copyright 2018 New Vector Ltd
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
type: object
title: m.presence_deny
description: |-
An EDU representing a declination or revocation for the observing user
to subscribe to the presence of the observed user.
example: {
"origin": "example.org",
"destination": "elsewhere.org",
"edu_type": "m.presence_deny",
"content": {
"observed_user": "@alice:elsewhere.org",
"observer_user": "@john:example.org"
}
}
allOf:
- $ref: ../edu.yaml
- type: object
properties:
edu_type:
type: enum
enum: ['m.presence_deny']
description: The string ``m.presence_deny``
example: "m.presence_deny"
content:
type: object
description: The invite information.
title: Invite Information
properties:
observed_user:
type: string
description: |-
The user ID that has declined or revoked the ``observer_user`` from
subscribing to their presence.
example: "@alice:elsewhere.com"
observer_user:
type: string
description: |-
The user ID that requested to subscribe to the presence of
the ``observed_user``.
example: "@john:matrix.org"
required: ['observer_user', 'observed_user']

@ -1,45 +0,0 @@
# Copyright 2018 New Vector Ltd
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
type: object
title: m.presence_invite
description: |-
An EDU representing a request to subscribe to a user's presence.
allOf:
- $ref: ../edu.yaml
- type: object
properties:
edu_type:
type: enum
enum: ['m.presence_invite']
description: The string ``m.presence_invite``
example: "m.presence_invite"
content:
type: object
description: The invite information.
title: Invite Information
properties:
observed_user:
type: string
description: |-
The user ID the ``observer_user`` would like to subscribe
to the presence of.
example: "@alice:elsewhere.com"
observer_user:
type: string
description: |-
The user ID that is wishing to subscribe to the presence of
the ``observed_user``.
example: "@john:matrix.org"
required: ['observer_user', 'observed_user']

@ -0,0 +1 @@
Remove references to presence lists

@ -26,14 +26,8 @@ Each user has the concept of presence information. This encodes:
This information is collated from both per-device (``online``, ``idle``, This information is collated from both per-device (``online``, ``idle``,
``last_active``) and per-user (status) data, aggregated by the user's homeserver ``last_active``) and per-user (status) data, aggregated by the user's homeserver
and transmitted as an ``m.presence`` event. This is one of the few events which and transmitted as an ``m.presence`` event. Presence events are sent to
are sent *outside the context of a room*. Presence events are sent to all users interested parties where users share a room membership.
who subscribe to this user's presence through a presence list or by sharing
membership of a room.
A presence list is a list of user IDs whose presence the user wants to follow.
To be added to this list, the user being added must be invited by the list owner
who must accept the invitation.
User's presence state is represented by the ``presence`` key, which is an enum User's presence state is represented by the ``presence`` key, which is an enum
of one of the following: of one of the following:
@ -53,17 +47,10 @@ Events
Client behaviour Client behaviour
---------------- ----------------
Clients can manually set/get their presence/presence list using the HTTP APIs Clients can manually set/get their presence using the HTTP APIs listed below.
listed below.
{{presence_cs_http_api}} {{presence_cs_http_api}}
Server behaviour
----------------
Each user's homeserver stores a "presence list" per user. Once a user accepts
a presence list, both user's HSes must track the subscription.
Last active ago Last active ago
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
The server maintains a timestamp of the last time it saw a pro-active event from The server maintains a timestamp of the last time it saw a pro-active event from

@ -907,15 +907,8 @@ The server API for presence is based entirely on exchange of the following
EDUs. There are no PDUs or Federation Queries involved. EDUs. There are no PDUs or Federation Queries involved.
Servers should only send presence updates for users that the receiving server Servers should only send presence updates for users that the receiving server
would be interested in. This can include the receiving server sharing a room would be interested in. Such as the receiving server sharing a room
with a given user, or a user on the receiving server has added one of the with a given user.
sending server's users to their presence list.
Clients may define lists of users that they are interested in via "Presence
Lists" through the `Client-Server API`_. When users are added to a presence
list, a ``m.presence_invite`` EDU is sent to them. The user may then accept
or deny their involvement in the list by sending either an ``m.presence_accept``
or ``m.presence_deny`` EDU back.
.. TODO-doc .. TODO-doc
- Explain the timing-based round-trip reduction mechanism for presence - Explain the timing-based round-trip reduction mechanism for presence
@ -925,13 +918,6 @@ or ``m.presence_deny`` EDU back.
{{definition_ss_event_schemas_m_presence}} {{definition_ss_event_schemas_m_presence}}
{{definition_ss_event_schemas_m_presence_invite}}
{{definition_ss_event_schemas_m_presence_accept}}
{{definition_ss_event_schemas_m_presence_deny}}
Receipts Receipts
-------- --------
@ -1009,7 +995,7 @@ which should be used to correlate with subsequent ``m.device_list_update`` EDUs.
.. TODO: this whole thing desperately feels like it should just be state in a room, .. TODO: this whole thing desperately feels like it should just be state in a room,
rather than inventing a whole different DAG. The same room could be used for rather than inventing a whole different DAG. The same room could be used for
profiles, presence lists, etc. profiles etc.
{{user_devices_ss_http_api}} {{user_devices_ss_http_api}}

Loading…
Cancel
Save