Used **Note** to describe notes around the authorisation rules. Otherwise restored the original state for the consequences from the auth rules.
Moved the clarification regarding default power levels up above the auth rules. Removed third sentence. And followed @turt2live's example, but opted for "for users in that room" because the default user power level is applied to all users.
Added missing added and removed to the rule, because these keys are not required for m.room.power_levels. Also moved the note down to the Note section.
The rules for m.room.power_levels power were somewhat unclear regarding the behaviour towards the always present keys, such as kick and ban. Additionally, it is now also clarified that in the users and events dictionary also added and removed keys are taken into consideration.
The server-server specification describes a "reference hash" of an event
and how to calculate it, but is otherwise not mentioned anywhere else in
the document. This change adds a sentence to explain that they are used
for event identifiers in later room versions, which are described in
other documents.
Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
This clarifies the `.m.rule.room_one_to_one` push rule by adding a condition on
event type. Some parts of the spec already had this info, while others were
missing it. Synapse has had this behaviour since the push rule appeared.
Fixes https://github.com/matrix-org/matrix-doc/issues/2150
* Switch "an SAS" back to "a SAS"
* Remove the `next_method` field from m.key.verification.start$m.sas.v1
but add additional clarification to its description on
m.key.verification.start that it is never present for methods that
verify keys both ways.
Currently the *m.key.verification.start* event appears twice with the
exact same title, in the "Key verification framework" section and the
"Short Authentication (SAS) verification" section. It's not immediately
clear that the first occurrence describes the format of the event in
general terms and that the second occurrence describes the fields when
the *m.sas.v1* verification method is being used. This is a similar
relationship to the *m.room.message* event and its various *msgtype*
variants.
This commit does three things:
* It tweaks the generation of the documentation to change the title
of the second occurrence of *m.key.verification.start* to
distinguish it from the first.
* It updates the language in the description of the two versions of the
event to better describe the relationship between the two.
* It adds the optional `next_method` field to the schema of the
*m.sas.v1* variant, as specified in the general form of
*m.key.verification.start*.
Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
m.room.message msgtypes.
Now that content referenced by the *m.audio*, *m.file*, *m.image*, and
*m.video* message types can be encrypted, the `url` field is required
*only* if the content is unencrypted. The "required" designation in the
event schemas (which prefixes the field description with "Required" in
bold in the generated HTML) is used to indicate fields which must always
be present, and this is no longer the case.
Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
Hubert Chathi