Minor wording changes
This commit is contained in:
parent
5cafcd103f
commit
061f59547a
4 changed files with 10 additions and 11 deletions
|
@ -434,16 +434,16 @@ There is no implicit ordering or hierarchy to room versions, and their principle
|
||||||
are immutable once placed in the specification. Although there is a recommended
|
are immutable once placed in the specification. Although there is a recommended
|
||||||
set of versions, some rooms may benefit from features introduced by other versions.
|
set of versions, some rooms may benefit from features introduced by other versions.
|
||||||
Rooms move between different versions by "upgrading" to the desired version. Due
|
Rooms move between different versions by "upgrading" to the desired version. Due
|
||||||
to versions not being ordered or hierarchical, this means a room can "upgrade" to
|
to versions not being ordered or hierarchical, this means a room can "upgrade"
|
||||||
version 1 from version 2, if it is so desired.
|
from version 2 to version 1, if it is so desired.
|
||||||
|
|
||||||
Room version grammar
|
Room version grammar
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Room versions are used to change properties of rooms that may not be compatible
|
Room versions are used to change properties of rooms that may not be compatible
|
||||||
with other servers. For example, changing the rules for event authorization would
|
with other servers. For example, changing the rules for event authorization would
|
||||||
cause older servers to potentially end up in a split-brain situation due to them
|
cause older servers to potentially end up in a split-brain situation due to not
|
||||||
not understanding the new rules.
|
understanding the new rules.
|
||||||
|
|
||||||
A room version is defined as a string of characters which MUST NOT exceed 32
|
A room version is defined as a string of characters which MUST NOT exceed 32
|
||||||
codepoints in length. Room versions MUST NOT be empty and SHOULD contain only
|
codepoints in length. Room versions MUST NOT be empty and SHOULD contain only
|
||||||
|
|
|
@ -34,8 +34,8 @@ version room they are dealing with prior to executing a given algorithm.
|
||||||
.. WARNING::
|
.. WARNING::
|
||||||
Although room version 1 is the most popular room version, it is known to have
|
Although room version 1 is the most popular room version, it is known to have
|
||||||
undesirable effects. Servers implementing support for room version 1 should be
|
undesirable effects. Servers implementing support for room version 1 should be
|
||||||
aware that restrictions should be generally relaxed and be aware that inconsistencies
|
aware that restrictions should be generally relaxed and that inconsistencies
|
||||||
may occur until room version 2 is ready and adopted.
|
may occur until room version 2 (or later) is ready and adopted.
|
||||||
|
|
||||||
State resolution
|
State resolution
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
|
@ -60,8 +60,8 @@ Power events
|
||||||
A *power event* is a state event with type ``m.room.power_levels`` or
|
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
|
``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
|
``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 have
|
``state_key``. The idea behind this is that power events are events that might
|
||||||
may remove someone's ability to do something in the room.
|
remove someone's ability to do something in the room.
|
||||||
|
|
||||||
Unconflicted state map and conflicted state set
|
Unconflicted state map and conflicted state set
|
||||||
The *unconflicted state map* is the state where the value of each key exists
|
The *unconflicted state map* is the state where the value of each key exists
|
||||||
|
|
|
@ -752,9 +752,8 @@ is at the top)::
|
||||||
Suppose E3 and E4 are both ``m.room.name`` events which set the name of the
|
Suppose E3 and E4 are both ``m.room.name`` events which set the name of the
|
||||||
room. What should the name of the room be at E5?
|
room. What should the name of the room be at E5?
|
||||||
|
|
||||||
Servers must use the appropriate recursively-defined algorithm as required
|
The algorithm to be used for state resolution depends on the room version. For
|
||||||
by the room version. For a description of each room version's algorithm, please
|
a description of each room version's algorithm, please see the `room version specification`_.
|
||||||
see the `room version specification`_ .
|
|
||||||
|
|
||||||
|
|
||||||
Backfilling and retrieving missing events
|
Backfilling and retrieving missing events
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue