Allow sending ephemeral data to application services (#2018)

As per MSC2409.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2024-12-11 23:38:59 +01:00 committed by GitHub
parent 846cc49eb2
commit 96b32f68f9
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 65 additions and 0 deletions

View file

@ -207,6 +207,39 @@ processed the events.
{{% http-api spec="application-service" api="transactions" %}}
##### Pushing ephemeral data
{{% added-in v="1.13" %}}
If the `receive_ephemeral` settings is enabled in the [registration](#registration)
file, homeservers MUST send ephemeral data that is relevant to the application
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.
There are currently three event types that can be delivered to an application
service:
- **[`m.presence`](/client-server-api/#mpresence)**: MUST be sent to the
application service if the data 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.
- **[`m.typing`](/client-server-api/#mtyping)**: MUST 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. The data MUST use the same format as the client-server API, with
the addition of a `room_id` property at the top level to identify the room that
they were sent in.
- **[`m.receipt`](/client-server-api/#mreceipt)**: MUST 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. The data MUST use the same format as the client-server
API, with the addition of a `room_id` property at the top level to identify the
room that they were sent in. [Private read receipts](/client-server-api/#private-read-receipts)
MUST only be sent for users matching one of the application service's
namespaces. Normal read receipts and threaded read receipts are always sent.
#### Pinging
{{% added-in v="1.7" %}}