MSC: https://github.com/matrix-org/matrix-doc/pull/2209
The changes are slightly difficult to word without dumping the text in and playing a game of spot the difference, so we now use our pre-existing pygments support to render a representation of the difference. The difference is shown in markdown-like format instead of RST for ease of understanding. It's also not rendered HTML for largely complexity reasons.
We stick it in a client section of v1 as the earliest version to define the algorithm is v1, and the client-server spec tells clients to use this algorithm.
I couldn't find any other reference to a state_type within the entire specification. I assume this is supposed to be the event_type? This aligns with the description of changes resulting from a state update.
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.
Original proposal: https://github.com/matrix-org/matrix-doc/pull/1659
Implementation proofs (some traversing of the PR tree may be required to get all of them):
* https://github.com/matrix-org/synapse/pull/4483
* https://github.com/matrix-org/synapse/pull/4499
This doesn't intentionally change anything from the proposal.
**Implementation details**:
The simple part of this is the introduction of a rooms/v3.html document. The somewhat unclear part is the stuff done to the s2s definitions. This pulls `unsigned_pdu` out to `unsigned_pdu_base` (all fields except `event_id`) where it can be reused in `pdu` and `pdu_v3` (for rooms v3). These definitions are further moved into the room version specifications where they can highlight the exact schemas in detail.
Version 1 has been updated to include the pre-existing event format, however the core principles of the room have not been changed. The same applies to room version 2. Room versions have immutable core principles once in the spec, otherwise these format changes would land in a pre-existing version.
The client-server API event formats will need updating, however that is being punted to a different commit to try and keep these changes reviewable.
> Since this is a copy-and-paste of old text, I think the copyright year should match when the original text was written, which according to git was 2017.
Co-Authored-By: turt2live <travpc@gmail.com>
Versions are actually on a scale of recommendations, and are expected to be created as needed. The scale presented here (develop/beta/default/recommended/mandatory) is a more wordy version of what was previously discussed/intended for room versions - the labels aren't final and may be changed.
The "Room Specification" (or "Room Version Specification") is the specification that defines which room versions do what and are intended to be documents which speak the truth about how rooms operate under the hood.
The approach taken here is a bit different than other specifications. For starters, the specification is versioned in this project instead of relying on the matrix.org repository to track compiled HTML. This is done for a couple reasons, the first being we're still developing the v1 specification while concurrently making a v2 spec and the second being trying to reduce the reliance on matrix.org's repository for specifications.
Because the room spec is built into versions, some changes needed to be made. The `targets.yaml` now has a special syntax for indicating what version something is at, and the changelog generator can handle rendering different versions of the same changelog (as parsed from the RST). Some additional work has been put in to the changelog parsing to allow us to reference the v1 room spec as "v1" without having to sacrifice clarity in the changelog headings.
Finally, this moves the state resolution algorithms into the versioned
spec as a result of MSC1759 (https://github.com/matrix-org/matrix-doc/pull/1759).
Note: this does not introduce the concept of versioned schemas (tabs) that I was previously working with. There's currently no use for them, so they are shelved elsewhere.
Travis Ralston