Room Version 4
This room version builds on version 3 using a different encoding for event IDs.
Client considerations
This room version changes the format form event IDs sent to clients. Clients should already be treating event IDs as opaque identifiers, and should not be concerned with the format of them. Clients should still encode the event ID when including it in a request path.
Clients should expect to see event IDs changed from the format of
$randomstring:example.org
to something like
$Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg
(note the lack of
domain).
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
Room version 4 uses the same algorithms defined in room version 3, however using URL-safe base64 to generate the event ID.
Event IDs
/
character
being interpreted differently by some reverse proxy software, and
generally made administration harder.
[New in this version]
The event ID is the reference
hash of
the event encoded using a variation of Unpadded
Base64 which replaces the 62nd and
63rd characters with -
and _
instead of using +
and /
. This
matches RFC4648’s definition of URL-safe
base64.
Event IDs are still prefixed with $
and might result in looking like
$Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg
.
Unchanged from v3
The following sections have not been modified since v3, but are included for completeness.
Redactions
Upon receipt of a redaction event, the server must strip off any keys not in the following list:
event_id
type
room_id
sender
state_key
content
hashes
signatures
depth
prev_events
prev_state
auth_events
origin
origin_server_ts
membership
The content object must also be stripped of all keys, unless it is one of the following event types:
m.room.member
allows keymembership
.m.room.create
allows keycreator
.m.room.join_rules
allows keyjoin_rule
.m.room.power_levels
allows keysban
,events
,events_default
,kick
,redact
,state_default
,users
,users_default
.m.room.aliases
allows keyaliases
.m.room.history_visibility
allows keyhistory_visibility
.
Handling redactions
In room versions 1 and 2, redactions were explicitly part of the authorization rules under Rule 11. As of room version 3, these conditions no longer exist as represented by this version’s authorization rules.
While redactions are always accepted by the authorization rules for events, they should not be sent to clients until both the redaction event and the event the redaction affects have been received, and can be validated. If both events are valid and have been seen by the server, then the server applies the redaction if one of the following conditions is met:
- The power level of the redaction event’s
sender
is greater than or equal to the redact level. - The domain of the redaction event’s
sender
matches that of the original event’ssender
.
If the server would apply a redaction, the redaction event is also sent to clients. Otherwise, the server simply waits for a valid partner event to arrive where it can then re-check the above.
Event format
The event format is the same as room version 3, however the event IDs in the following example are updated to reflect the changes in this room version.
Events in rooms of this version have the following structure:
Persistent Data Unit
Persistent Data Unit
A persistent data unit (event) for room version 4 and beyond.
Name | Type | Description |
---|---|---|
auth_events |
[string] |
Required: Event IDs for the authorization events that would allow this event to be in the room. Must contain less than or equal to 10 events. Note that if the relevant auth event selection rules are used, this restriction should never be encountered. |
content |
object |
Required: The content of the event. |
depth |
integer |
Required: The maximum depth of the prev_events , plus one. Must be less than the
maximum value for an integer (2^63 - 1). If the room’s depth is already at
the limit, the depth must be set to the limit. |
hashes |
Event Hash |
Required: Content hashes of the PDU, following the algorithm specified in Signing Events. |
origin_server_ts |
integer |
Required: Timestamp in milliseconds on origin homeserver when this event was created. |
prev_events |
[string] |
Required: Event IDs for the most recent events in the room that the homeserver was aware of when it made this event. Must contain less than or equal to 20 events. |
redacts |
string |
For redaction events, the ID of the event being redacted. |
room_id |
string |
Required: Room identifier. |
sender |
string |
Required: The ID of the user sending the event. |
signatures |
{string: Server Signatures} |
Required: Signatures for the PDU, following the algorithm specified in Signing Events. |
state_key |
string |
If this key is present, the event is a state event, and it will replace previous events
with the same type and state_key in the room state. |
type |
string |
Required: Event type |
unsigned |
UnsignedData |
Additional data added by the origin server but not covered by the signatures . |
Name | Type | Description |
---|---|---|
sha256 |
string |
Required: The hash. |
Name | Type | Description |
---|---|---|
age |
integer |
The number of milliseconds that have passed since this message was sent. |
Examples
{
"auth_events": [
"$urlsafe_base64_encoded_eventid",
"$a-different-event-id"
],
"content": {
"key": "value"
},
"depth": 12,
"hashes": {
"sha256": "thishashcoversallfieldsincasethisisredacted"
},
"origin": "example.com",
"origin_server_ts": 1404838188000,
"prev_events": [
"$urlsafe_base64_encoded_eventid",
"$a-different-event-id"
],
"redacts": "$some-old_event",
"room_id": "!UcYsUzyxTGDxLBEvLy:example.org",
"sender": "@alice:example.com",
"signatures": {
"example.com": {
"ed25519:key_version:": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
}
},
"type": "m.room.message",
"unsigned": {
"age": 4612
}
}
Deprecated event content schemas
Events sent into rooms of this version can have formats which are different from their normal schema. Those cases are documented here.
m.room.power_levels
events accept values as strings
In order to maintain backwards compatibility with early implementations,
each of the integer-valued properties within
m.room.power_levels
events can
be encoded as strings instead of integers. This includes the nested values
within the events
, notifications
and users
properties.
For example, the following is a valid m.room.power_levels
event in this room version:
{
"content": {
"ban": "50",
"events": {
"m.room.power_levels": "100"
},
"events_default": "0",
"state_default": "50",
"users": {
"@example:localhost": "100"
},
"users_default": "0"
},
"origin_server_ts": 1432735824653,
"room_id": "!jEsUZKDJdhlrceRyVU:example.org",
"sender": "@example:example.org",
"state_key": "",
"type": "m.room.power_levels"
}
When the value is representative of an integer, they must be the following format:
- a single base 10 integer, no float values or decimal points, optionally with
any number of leading zeroes (
"100"
,"000100"
); - optionally prefixed with a single
-
or+
character before the integer ("+100"
,"-100"
). - optionally with any number of leading or trailing whitespace characters (
" 100 "
," 00100 "
," +100 "
," -100 "
);
Authorization rules
In room versions 1 and 2, events need a
signature from the domain of the event_id
in order to be considered
valid. This room version does not include an event_id
over federation
in the same respect, so does not need a signature from that server.
The event must still be signed by the server denoted by the sender
property,
however.
The types of state events that affect authorization are:
sender
’s power level can also refer to
the default power level for users in the room.
The complete list of rules, as of room version 3, is as follows:
- If type is
m.room.create
:- If it has any
prev_events
, reject. - If the domain of the
room_id
does not match the domain of thesender
, reject. - If
content.room_version
is present and is not a recognised version, reject. - If
content
has nocreator
property, reject. - Otherwise, allow.
- If it has any
- Considering the event’s
auth_events
:- If there are duplicate entries for a given
type
andstate_key
pair, reject. - If there are entries whose
type
andstate_key
don’t match those specified by the auth events selection algorithm described in the server specification, reject. - If there are entries which were themselves rejected under the checks performed on receipt of a PDU, reject.
- If there is no
m.room.create
event among the entries, reject.
- If there are duplicate entries for a given
- If the
content
of them.room.create
event in the room state has the propertym.federate
set tofalse
, and thesender
domain of the event does not match thesender
domain of the create event, reject. - If type is
m.room.aliases
:- If event has no
state_key
, reject. - If sender’s domain doesn’t matches
state_key
, reject. - Otherwise, allow.
- If event has no
- If type is
m.room.member
:- If there is no
state_key
property, or nomembership
property incontent
, reject. - If
membership
isjoin
:- If the only previous event is an
m.room.create
and thestate_key
is the creator, allow. - If the
sender
does not matchstate_key
, reject. - If the
sender
is banned, reject. - If the
join_rule
isinvite
then allow if membership state isinvite
orjoin
. - If the
join_rule
ispublic
, allow. - Otherwise, reject.
- If the only previous event is an
- If
membership
isinvite
:- If
content
has athird_party_invite
property:- If target user is banned, reject.
- If
content.third_party_invite
does not have asigned
property, reject. - If
signed
does not havemxid
andtoken
properties, reject. - If
mxid
does not matchstate_key
, reject. - If there is no
m.room.third_party_invite
event in the current room state withstate_key
matchingtoken
, reject. - If
sender
does not matchsender
of them.room.third_party_invite
, reject. - If any signature in
signed
matches any public key in them.room.third_party_invite
event, allow. The public keys are incontent
ofm.room.third_party_invite
as:- A single public key in the
public_key
property. - A list of public keys in the
public_keys
property.
- A single public key in the
- Otherwise, reject.
- If the
sender
’s current membership state is notjoin
, reject. - If target user’s current membership state is
join
orban
, reject. - If the
sender
’s power level is greater than or equal to the invite level, allow. - Otherwise, reject.
- If
- If
membership
isleave
:- If the
sender
matchesstate_key
, allow if and only if that user’s current membership state isinvite
orjoin
. - If the
sender
’s current membership state is notjoin
, reject. - If the target user’s current membership state is
ban
, and thesender
’s power level is less than the ban level, reject. - If the
sender
’s power level is greater than or equal to the kick level, and the target user’s power level is less than thesender
’s power level, allow. - Otherwise, reject.
- If the
- If
membership
isban
:- If the
sender
’s current membership state is notjoin
, reject. - If the
sender
’s power level is greater than or equal to the ban level, and the target user’s power level is less than thesender
’s power level, allow. - Otherwise, reject.
- If the
- Otherwise, the membership is unknown. Reject.
- If there is no
- If the
sender
’s current membership state is notjoin
, reject. - If type is
m.room.third_party_invite
:- Allow if and only if
sender
’s current power level is greater than or equal to the invite level.
- Allow if and only if
- If the event type’s required power level is greater than the
sender
’s power level, reject. - If the event has a
state_key
that starts with an@
and does not match thesender
, reject. - If type is
m.room.power_levels
:- If
users
property incontent
is not an object with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. - If there is no previous
m.room.power_levels
event in the room, allow. - For the properties
users_default
,events_default
,state_default
,ban
,redact
,kick
,invite
check if they were added, changed or removed. For each found alteration:- If the current value is greater than the
sender
’s current power level, reject. - If the new value is greater than the
sender
’s current power level, reject.
- If the current value is greater than the
- For each entry being changed in, or removed from, the
events
property:- If the current value is greater than the
sender
’s current power level, reject.
- If the current value is greater than the
- For each entry being added to, or changed in, the
events
property:- If the new value is greater than the
sender
’s current power level, reject.
- If the new value is greater than the
- For each entry being changed in, or removed from, the
users
property, other than thesender
’s own entry:- If the current value is greater than or equal to the
sender
’s current power level, reject.
- If the current value is greater than or equal to the
- For each entry being added to, or changed in, the
users
property:- If the new value is greater than the
sender
’s current power level, reject.
- If the new value is greater than the
- Otherwise, allow.
- If
- Otherwise, allow.
Some consequences of these rules:
- Unless you are a member of the room, the only permitted operations (apart from the initial create/join) are: joining a public room; accepting or rejecting an invitation to a room.
- To unban somebody, you must have power level greater than or equal to both the kick and ban levels, and greater than the target user’s power level.
State resolution
The room state S′(E) after an event E is defined in terms of the room state S(E) before E, and depends on whether E is a state event or a message event:
- If E is a message event, then S′(E) = S(E).
- If E is a state event, then S′(E) is S(E), except that its
entry corresponding to the
event_type
andstate_key
of E is replaced by theevent_id
of E.
The room state S(E) before E is the resolution of the set of
states {S′(E1), S′(E2), …}
after the prev_event
s {E1, E2, …} of E.
The resolution of a set of states is given in the algorithm below.
Definitions
The state resolution algorithm for version 2 rooms uses the following definitions, given the set of room states {S1, S2, …}:
Power events.
A power event is a state event with type m.room.power_levels
or
m.room.join_rules
, or a state event with type m.room.member
where
the membership
is leave
or ban
and the sender
does not match the
state_key
. The idea behind this is that power events are events that
might remove someone’s ability to do something in the room.
Unconflicted state map and conflicted state set.
The keys of the state maps Si are 2-tuples of strings of the form
K = (event_type, state_key)
. The values V are state events.
The key-value pairs (K, V) across all state maps Si can be
divided into two collections.
If a given key K is present in every Si with the same value V
in each state map, then the pair (K, V) belongs to the unconflicted state map.
Otherwise, V belongs to the conflicted state set.
Note that the unconflicted state map only has one event for each key K, whereas the conflicted state set may contain multiple events with the same key.
Auth chain.
The auth chain of an event E is the set containing all of E’s auth events,
all of their auth events, and so on recursively, stretching back to the
start of the room. Put differently, these are the events reachable by walking
the graph induced by an event’s auth_events
links.
Auth difference. The auth difference is calculated by first calculating the full auth chain for each state Si, that is the union of the auth chains for each event in Si, and then taking every event that doesn’t appear in every auth chain. If Ci is the full auth chain of Si, then the auth difference is ∪ Ci − ∩ Ci.
Full conflicted set. The full conflicted set is the union of the conflicted state set and the auth difference.
Reverse topological power ordering. The reverse topological power ordering of a set of events is the lexicographically smallest topological ordering based on the DAG formed by auth events. The reverse topological power ordering is ordered from earliest event to latest. For comparing two topological orderings to determine which is the lexicographically smallest, the following comparison relation on events is used: for events x and y, x < y if
- x’s sender has greater power level than y’s sender, when
looking at their respective
auth_event
s; or - the senders have the same power level, but x’s
origin_server_ts
is less than y’sorigin_server_ts
; or - the senders have the same power level and the events have the same
origin_server_ts
, but x’sevent_id
is less than y’sevent_id
.
The reverse topological power ordering can be found by sorting the events using Kahn’s algorithm for topological sorting, and at each step selecting, among all the candidate vertices, the smallest vertex using the above comparison relation.
Mainline ordering.
Let P = P0 be an m.room.power_levels
event.
Starting with i = 0, repeatedly fetch Pi+1, the
m.room.power_levels
event in the auth_events
of Pi.
Increment i and repeat until Pi has no m.room.power_levels
event in its auth_events
.
The mainline of P0 is the list of events
[P0 , P1, … , Pn],
fetched in this way.
Let e = e0 be another event (possibly another
m.room.power_levels
event). We can compute a similar list of events
[e1, …, em],
where ej+1 is the m.room.power_levels
event in the
auth_events
of ej and where em has no
m.room.power_levels
event in its auth_events
. (Note that the event we
started with, e0, is not included in this list. Also note that it
may be empty, because e may not cite an m.room.power_levels
event in its
auth_events
at all.)
Now compare these two lists as follows.
- Find the smallest index j ≥ 1 for which ej belongs to the mainline of P.
- If such a j exists, then ej = Pi for some unique index i ≥ 0. Otherwise set i = ∞, where ∞ is a sentinel value greater than any integer.
- In both cases, the mainline position of e is i.
Given mainline positions calculated from P, the mainline ordering based on P of a set of events is the ordering, from smallest to largest, using the following comparison relation on events: for events x and y, x < y if
- the mainline position of x is greater than the mainline position of y (i.e. the auth chain of x is based on an earlier event in the mainline than y); or
- the mainline positions of the events are the same, but x’s
origin_server_ts
is less than y’sorigin_server_ts
; or - the mainline positions of the events are the same and the events have the
same
origin_server_ts
, but x’sevent_id
is less than y’sevent_id
.
Iterative auth checks.
The iterative auth checks algorithm takes as input an initial room
state and a sorted list of state events, and constructs a new room state
by iterating through the event list and applying the state event to the
room state if the state event is allowed by the authorization
rules.
If the state event is not allowed by the authorization rules, then the
event is ignored. If a (event_type, state_key)
key that is required
for checking the authorization rules is not present in the state, then
the appropriate state event from the event’s auth_events
is used if
the auth event is not rejected.
Algorithm
The resolution of a set of states is obtained as follows:
- Select the set X of all power events that appear in the full conflicted set. For each such power event P, enlarge X by adding the events in the auth chain of P which also belong to the full conflicted set. Sort $X$ into a list using the reverse topological power ordering.
- Apply the iterative auth checks algorithm, starting from the unconflicted state map, to the list of events from the previous step to get a partially resolved state.
- Take all remaining events that weren’t picked in step 1 and order them by the mainline ordering based on the power level in the partially resolved state obtained in step 2.
- Apply the iterative auth checks algorithm on the partial resolved state and the list of events from the previous step.
- Update the result by replacing any event with the event with the same key from the unconflicted state map, if such an event exists, to get the final resolved state.
Rejected events
Events that have been rejected due to failing auth based on the state at the event (rather than based on their auth chain) are handled as usual by the algorithm, unless otherwise specified.
Note that no events rejected due to failure to auth against their auth chain should appear in the process, as they should not appear in state (the algorithm only uses events that appear in either the state sets or in the auth chain of the events in the state sets).
This helps ensure that different servers’ view of state is more likely to converge, since rejection state of an event may be different. This can happen if a third server gives an incorrect version of the state when a server joins a room via it (either due to being faulty or malicious). Convergence of state is a desirable property as it ensures that all users in the room have a (mostly) consistent view of the state of the room. If the view of the state on different servers diverges it can lead to bifurcation of the room due to e.g. servers disagreeing on who is in the room.
Intuitively, using rejected events feels dangerous, however:
- Servers cannot arbitrarily make up state, since they still need to pass the auth checks based on the event’s auth chain (e.g. they can’t grant themselves power levels if they didn’t have them before).
- For a previously rejected event to pass auth there must be a set of state that allows said event. A malicious server could therefore produce a fork where it claims the state is that particular set of state, duplicate the rejected event to point to that fork, and send the event. The duplicated event would then pass the auth checks. Ignoring rejected events would therefore not eliminate any potential attack vectors.
Rejected auth events are deliberately excluded from use in the iterative auth checks, as auth events aren’t re-authed (although non-auth events are) during the iterative auth checks.
Canonical JSON
Servers MUST NOT strictly enforce the JSON format specified in the appendices for the reasons described there.