matrix-spec-proposals/specification/events.rst

Event Structure
===============

All communication in Matrix is expressed in the form of data objects called
Events. These are the fundamental building blocks common to the client-server,
server-server and application-service APIs, and are described below.

{{common_event_fields}}

{{common_room_event_fields}}

{{common_state_event_fields}}


Size limits
-----------

The total size of any event MUST NOT exceed 65 KB. There are additional
restrictions on sizes per key:

 - ``user_id`` MUST NOT exceed 255 bytes (including domain).
 - ``room_id`` MUST NOT exceed 255 bytes.
 - ``state_key`` MUST NOT exceed 255 bytes.
 - ``type`` MUST NOT exceed 255 bytes.
 - ``event_id`` MUST NOT exceed 255 bytes.

Some event types have additional size restrictions which are specified in
the description of the event. Additional keys have no limit other than that
implied by the total 65 KB limit on events.

Room Events
-----------
.. NOTE::
  This section is a work in progress.

This specification outlines several standard event types, all of which are
prefixed with ``m.``

{{m_room_aliases_event}}

{{m_room_canonical_alias_event}}

{{m_room_create_event}}

{{m_room_join_rules_event}}

{{m_room_member_event}}

{{m_room_power_levels_event}}

{{m_room_redaction_event}}
Move related auth sections together 9 years ago			`Event Structure`
			`===============`
as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago
general editing throughout the overview section; merge in bits of erik's model to overview section and split the original back out into drats 10 years ago			`All communication in Matrix is expressed in the form of data objects called`
add in version, improve AS API a bit, move eventstream to the right place 10 years ago			`Events. These are the fundamental building blocks common to the client-server,`
			`server-server and application-service APIs, and are described below.`
as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago
Template up common event fields from the 'core' json schema file. 10 years ago			`{{common_event_fields}}`
as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago
Template up common event fields from the 'core' json schema file. 10 years ago			`{{common_room_event_fields}}`
as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago
Template up common event fields from the 'core' json schema file. 10 years ago			`{{common_state_event_fields}}`
as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago

Add in size limits as per SPEC-222 9 years ago			`Size limits`
			`-----------`

			`The total size of any event MUST NOT exceed 65 KB. There are additional`
			`restrictions on sizes per key:`

			- ``user_id`` MUST NOT exceed 255 bytes (including domain).
			- ``room_id`` MUST NOT exceed 255 bytes.
			- ``state_key`` MUST NOT exceed 255 bytes.
			- ``type`` MUST NOT exceed 255 bytes.
			- ``event_id`` MUST NOT exceed 255 bytes.

Review comments 9 years ago			`Some event types have additional size restrictions which are specified in`
Add in size limits as per SPEC-222 9 years ago			`the description of the event. Additional keys have no limit other than that`
			`implied by the total 65 KB limit on events.`

as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago			`Room Events`
			`-----------`
			`.. NOTE::`
			`This section is a work in progress.`

			`This specification outlines several standard event types, all of which are`
			prefixed with ``m.``

Add instant_messaging module; modify batesian section rules Previously, all `m.room.*` events were wodged into `{{room_events}}` which isn't great when you want to pull specific ones out. Batesian had a 1:1 mapping of `render_foo()` to a section `{{foo}}`, and having to constantly add functions for new types is a PITA. Batesian now supports returning a `dict` instead of a section `string` where the keys are the `{{foo}}` and the value is what will be inserted. Also add conflicting section key checks to avoid multiple definitions of the same `{{foo}}`. Define dicts for event schemata and swagger HTTP APIs. Using this new feature, split out the instant messaging stuff from the events section, and replace `{{room_events}}` with a list of specific events e.g. `{{m_room_member_event}}`. 9 years ago			`{{m_room_aliases_event}}`

Fix typo 9 years ago			`{{m_room_canonical_alias_event}}`
Add instant_messaging module; modify batesian section rules Previously, all `m.room.*` events were wodged into `{{room_events}}` which isn't great when you want to pull specific ones out. Batesian had a 1:1 mapping of `render_foo()` to a section `{{foo}}`, and having to constantly add functions for new types is a PITA. Batesian now supports returning a `dict` instead of a section `string` where the keys are the `{{foo}}` and the value is what will be inserted. Also add conflicting section key checks to avoid multiple definitions of the same `{{foo}}`. Define dicts for event schemata and swagger HTTP APIs. Using this new feature, split out the instant messaging stuff from the events section, and replace `{{room_events}}` with a list of specific events e.g. `{{m_room_member_event}}`. 9 years ago
			`{{m_room_create_event}}`

			`{{m_room_join_rules_event}}`

			`{{m_room_member_event}}`

			`{{m_room_power_levels_event}}`

			`{{m_room_redaction_event}}`
as per the big spec meeting, split specification.rst into 4 chapters. merge in specification-NOTHAVE and spec-additions.rst whilst at it. 10 years ago