wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Minor wording changes

Browse source
This commit is contained in:
Travis Ralston 2019-01-23 09:10:14 -07:00
parent 5cafcd103f
commit 061f59547a
4 changed files with 10 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

8
specification/index.rst
View file

@ -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
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
to versions not being ordered or hierarchical, this means a room can "upgrade" to
version 1 from version 2, if it is so desired.
to versions not being ordered or hierarchical, this means a room can "upgrade"
from version 2 to version 1, if it is so desired.
Room version grammar
~~~~~~~~~~~~~~~~~~~~
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
cause older servers to potentially end up in a split-brain situation due to them
not understanding the new rules.
cause older servers to potentially end up in a split-brain situation due to not
understanding the new rules.
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

4
specification/rooms/v1.rst
View file

@ -34,8 +34,8 @@ version room they are dealing with prior to executing a given algorithm.
.. WARNING::
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
aware that restrictions should be generally relaxed and be aware that inconsistencies
may occur until room version 2 is ready and adopted.
aware that restrictions should be generally relaxed and that inconsistencies
may occur until room version 2 (or later) is ready and adopted.
State resolution
~~~~~~~~~~~~~~~~

4
specification/rooms/v2.rst
View file

@ -60,8 +60,8 @@ 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 have
may remove someone's ability to do something in the room.
``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 *unconflicted state map* is the state where the value of each key exists

5
specification/server_server_api.rst
View file

@ -752,9 +752,8 @@ is at the top)::
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?
Servers must use the appropriate recursively-defined algorithm as required
by the room version. For a description of each room version's algorithm, please
see the `room version specification`_ .
The algorithm to be used for state resolution depends on the room version. For
a description of each room version's algorithm, please see the `room version specification`_.
Backfilling and retrieving missing events