29bd4d45ee
Now that we don't expect there to be duplication betwen the 'timeline' and 'state' results, there's no point in having the state map. (That does mean the events themselves need event_id fields though). Also: - move the contents of the 'unsigned' dictionary into the events themselves - replace the state list with two layers of dictionary keyed on type and state_key - rename the children of the 'rooms' dict from "joined/invited/archived" to "join/invite/leave" to match the membership states
86 lines
2.7 KiB
ReStructuredText
86 lines
2.7 KiB
ReStructuredText
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}}
|
|
|
|
|
|
Differences between /v1 and /v2 events
|
|
--------------------------------------
|
|
|
|
There are a few differences between how events are formatted for sending
|
|
between servers over federation and how they are formatted for sending between
|
|
a server and its clients.
|
|
|
|
Additionally there are a few differences between the format of events in the
|
|
responses to client APIs with a /v1 prefix and responses APIs with a /v2
|
|
prefix.
|
|
|
|
Events in responses for APIs with the /v2 prefix are generated from an event
|
|
formatted for federation by:
|
|
|
|
* Removing the following keys:
|
|
``auth_events``, ``prev_events``, ``hashes``, ``signatures``, ``depth``,
|
|
``origin``, ``prev_state``, ``unsigned``.
|
|
* Adding an ``age`` to the event object which gives the time in
|
|
milliseconds that has elapsed since the event was sent.
|
|
* Adding ``prev_content`` and ``prev_sender`` to the event object if the event
|
|
is a ``state event``, which give the previous content and previous sender of
|
|
that state key
|
|
* Adding a ``redacted_because`` to event object if the event was
|
|
redacted which gives the event that redacted it.
|
|
* Adding a ``txn_id`` if the event was sent by the client requesting it.
|
|
|
|
Events in responses for APIs with the /v1 prefix are generated from an event
|
|
formatted for the /v2 prefix by:
|
|
|
|
* Rename the ``sender`` key to ``user_id``.
|
|
* If the event was an ``m.room.member`` with ``membership`` set to ``invite``
|
|
then adding a ``invite_room_state`` key to the top level event object.
|
|
|
|
|
|
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}}
|
|
|