4.3 KiB
| title | type | weight |
|---|---|---|
| Room Version 3 | docs | 30 |
This room version builds on version 2 with an improved event format.
Client considerations
This room version changes the format for event IDs sent to clients. Clients should be aware that these event IDs may contain slashes and other potentially problematic characters. Clients should be treating event IDs as opaque identifiers and should not be attempting to parse them into a usable form, just like with other room versions.
Clients should expect to see event IDs changed from the format of
$randomstring:example.org to something like
$acR1l0raoZnm60CBwAVgqbZqoO/mYU81xysh1u7XcJk (note the lack of domain
and the potentially problematic slash).
Though unchanged in this room version, clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview.
Server implementation components
{{% boxes/warning %}} The information contained in this section is strictly for server implementors. Applications which use the Client-Server API are generally unaffected by the intricacies contained here. The section above regarding client considerations is the resource that Client-Server API use cases should reference. {{% /boxes/warning %}}
Room version 3 uses the event format described here in addition to all the remaining behaviour described by room version 2.
Event IDs
{{% boxes/rationale %}} In other room versions (namely version 1 and 2) the event ID is a distinct field from the remainder of the event, which must be tracked as such. This leads to complications where servers receive multiple events with the same ID in either the same or different rooms where the server cannot easily keep track of which event it should be using. By removing the use of a dedicated event ID, servers are required to track the hashes on an event to determine its ID. {{% /boxes/rationale %}}
The event ID is the reference
hash of
the event encoded using Unpadded
Base64, prefixed with $. A
resulting event ID using this approach should look similar to
$CD66HAED5npg6074c6pDtLKalHjVfYb2q4Q3LZgrW6o.
Event IDs should not be sent over federation to servers when the room uses this room version. On the receiving end of an event, the server should compute the relevant event ID for itself.
Additionally, the auth_events and prev_events have had a format
change compared to other room versions to make it easier to handle.
Instead of a tuple of values, they are now plain lists of events.
{{% definition path="api/server-server/definitions/pdu_v3" %}}
Changes to APIs
Due to the event ID being removed from the event, some APIs need to change. All APIs which currently accept an event ID must do so with the new format. Servers must append the calculated event ID to all events sent to clients where an event ID would normally be expected.
Because the format of events has changed, servers must be aware of the room version where the event resides so that the server may parse and handle the event. The federation API has taken this concern into consideration by ensuring that servers are aware of (or can find) the room version during a request.
Authorization rules for events
{{% added-in this=true %}} m.room.redaction events are no longer
explicitly part of the auth rules. They are still subject to the
minimum power level rules, but should always fall into "11. Otherwise,
allow". Instead of being authorized at the time of receipt, they are
authorized at a later stage: see the Handling Redactions
section below for more information.
{{% rver-fragment name="v3-auth-rules" withVersioning=true %}}
Handling redactions
{{% rver-fragment name="v3-handling-redactions" withVersioning=true %}}
Unchanged from v2
The following sections have not been modified since v2, but are included for completeness.
State resolution
{{% rver-fragment name="v2-state-res" %}}
Canonical JSON
{{% rver-fragment name="v1-canonical-json" %}}
Redactions
{{% rver-fragment name="v1-redactions" %}}