Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-26 13:04:10 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

put canonical list of ephemeral events into /sync documentation

Browse source
This commit is contained in:
Hubert Chathi 2022-10-18 11:22:52 -04:00
parent 4967b394ca
commit 809adf2811
3 changed files with 10 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
content/client-server-api/_index.md
View file

@ -1521,7 +1521,7 @@ any given point in time:
### Types of room events ### Types of room events
Room events are split into three categories: Room events are split into two categories:
* **State events**: These are events which update the metadata state of the room (e.g. room * **State events**: These are events which update the metadata state of the room (e.g. room
topic, room membership etc). State is keyed by a tuple of event `type` topic, room membership etc). State is keyed by a tuple of event `type`
@ -1532,12 +1532,6 @@ overwritten.
typically communication such as sending an instant message or setting up typically communication such as sending an instant message or setting up
a VoIP call. a VoIP call.
* **Ephemeral events**: These are events which are not persisted in the room's
timeline. In this version of the spec, these are [typing
notification](#typing-notifications) and [read receipt](#receipts) events. Note
that, unlike state events and message events, there is currently no way of
defining custom ephemeral events.
This specification outlines several events, all with the event type This specification outlines several events, all with the event type
prefix `m.`. (See [Room Events](#room-events) for the m. event prefix `m.`. (See [Room Events](#room-events) for the m. event
specification.) However, applications may wish to add their own type of specification.) However, applications may wish to add their own type of
@ -1565,9 +1559,7 @@ in [room version 1](/rooms/v1#event-format) and [room version
However, it is unusual that a Matrix client would encounter this event However, it is unusual that a Matrix client would encounter this event
format. Instead, homeservers are responsible for converting events into the format. Instead, homeservers are responsible for converting events into the
format shown below so that they can be easily parsed by clients. Note that the format shown below so that they can be easily parsed by clients.
format below only applies to state and message events; ephemeral events will
only have the `type` and `content` properties.
{{% boxes/warning %}} {{% boxes/warning %}}
Event bodies are considered untrusted data. This means that any application using Event bodies are considered untrusted data. This means that any application using

4
data/api/client-server/definitions/sync_filter.yaml
View file

@ -62,7 +62,9 @@ properties:
ephemeral: ephemeral:
allOf: allOf:
- $ref: room_event_filter.yaml - $ref: room_event_filter.yaml
description: The ephemeral events to include for rooms. description: The ephemeral events to include for rooms. These are the
events that appear in the `ephemeral` property in the `/sync`
response.
include_leave: include_leave:
description: Include rooms that the user has left in the sync, default false description: Include rooms that the user has left in the sync, default false
type: boolean type: boolean

6
data/api/client-server/sync.yaml
View file

@ -219,7 +219,11 @@ paths:
title: Ephemeral title: Ephemeral
type: object type: object
description: |- description: |-
The new ephemeral events in the room. The new ephemeral events in the room (events that
aren't recorded in the timeline or state of the
room). In this version of the spec, these are
[typing notification](#typing-notifications) and
[read receipt](#receipts) events.
allOf: allOf:
- $ref: "definitions/event_batch.yaml" - $ref: "definitions/event_batch.yaml"
account_data: account_data: