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.

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

Allow sending ephemeral data to application services #2018

Merged
merged 4 commits into from
Dec 11, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
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
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Allow to send EDUs to application services, as per [MSC2409](https://github.com/matrix-org/matrix-spec-proposals/pull/2409).
27 changes: 27 additions & 0 deletions content/application-service-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -207,6 +207,33 @@ processed the events.

{{% http-api spec="application-service" api="transactions" %}}

##### Pushing EDUs
richvdh marked this conversation as resolved.
Show resolved Hide resolved

{{% added-in v="1.13" %}}

If the `receive_ephemeral` settings is enabled in the [registration](#registration)
file, homeservers MUST send all EDUs that are relevant to the application
richvdh marked this conversation as resolved.
Show resolved Hide resolved
service via the transaction API, using the `ephemeral` property of the request's
body. This property is an array that is effectively a combination of the
`presence` and `ephemeral` sections of the client-server [`/sync`](/client-server-api/#get_matrixclientv3sync)
API. It means that there are only three event types that can currently occur:
[`m.presence`](/client-server-api/#mpresence), [`m.typing`](/client-server-api/#mtyping),
and [`m.receipt`](/client-server-api/#mreceipt).
richvdh marked this conversation as resolved.
Show resolved Hide resolved

EDUs that can be associated to a particular room (i.e. `m.typing` or `m.receipt`)
MUST also include a `room_id` property to identify the room that they were sent
richvdh marked this conversation as resolved.
Show resolved Hide resolved
in. They should be sent to the application service under the same rules as
regular events, meaning that the application service must have registered
interest in the room itself, or in a user that is in the room.
[Private read receipts](/client-server-api/#private-read-receipts) should only
be sent for users matching one of the application service's namespaces. Normal
read receipts and threaded read receipts are always sent.

EDUs which are not associated with a particular room (i.e. `m.presence`), should
be sent to the application service if the EDU would apply contextually. For
example, a presence update for a user an application service shares a room with,
or matching one of the application service's namespaces.
richvdh marked this conversation as resolved.
Show resolved Hide resolved

#### Pinging

{{% added-in v="1.7" %}}
Expand Down
7 changes: 7 additions & 0 deletions data/api/application-service/definitions/registration.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,13 @@ properties:
description: |-
The localpart of the user associated with the application service. Events will be sent to the AS if this user is the target of the event, or
is a joined member of the room where the event occurred.
receive_ephemeral:
type: boolean
x-addedInMatrixVersion: "1.13"
description: |-
Whether the application service wants to [receive EDUs](/application-service-api/#pushing-edus).

Defaults to `false` if not present.
namespaces:
type: object
title: Namespaces
Expand Down
23 changes: 23 additions & 0 deletions data/api/application-service/transactions.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,15 @@ paths:
schema:
type: object
example: {
"ephemeral": [
{
"$ref": "../../event-schemas/examples/m.receipt.yaml",
"room_id": "!jEsUZKDJdhlrceRyVU:example.org"
},
{
"$ref": "../../event-schemas/examples/m.presence.yaml"
},
],
"events": [
{
"$ref": "../../event-schemas/examples/m.room.member.yaml"
Expand All @@ -61,6 +70,20 @@ paths:
description: A list of events, formatted as per the Client-Server API.
items:
$ref: ../client-server/definitions/client_event.yaml
ephemeral:
type: array
x-addedInMatrixVersion: "1.13"
description: |-
A list of ephemeral events (aka EDUs), if the `receive_ephemeral` setting was
enabled in the [registration](/application-service-api/#registration) file.

There are only three event types that can currently occur: `m.presence`,
richvdh marked this conversation as resolved.
Show resolved Hide resolved
`m.typing`, and `m.receipt`. Room-scoped EDUs (`m.typing` and `m.receipt`) MUST
include a `room_id` property to identify the room that they were sent in.

This property can be omitted if it would be empty.
items:
$ref: ../../event-schemas/schema/core-event-schema/event.yaml
required:
- events
description: Transaction information
Expand Down