matrix-org · richvdh · Nov 8, 2022 · Nov 2, 2022 · Nov 2, 2022 · Nov 2, 2022
@@ -0,0 +1 @@
+Stop rendering the subsections of the Client-Server API and Room Versions specs as their own separate pages.
@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Client Config
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Administration
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Content repository
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Device Management
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Direct Messaging
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### End-to-End Encryption
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Event Context
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Event replacements
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Guest Access
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room History Visibility
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Ignoring Users
 

@@ -0,0 +1,3 @@
+---
+headless: true
+---
@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Instant Messaging
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### User and room mentions
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Moderation policy lists
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### OpenID
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Presence
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Push Notifications
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Fully read markers
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Receipts
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Reference relations
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Reporting Content
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Rich replies
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room Previews
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room Upgrades
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Side Search
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Secrets
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Send-to-Device messaging
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Access Control Lists (ACLs) for rooms
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Server Notices
 

@@ -1,7 +1,4 @@
----
-type: module
 weight: 340
----
 
 ### Spaces
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### SSO client login/authentication
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Sticker Messages
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Room Tagging
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Third party invites
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Third Party Networks
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Threading
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Typing Notifications
 

@@ -1,6 +1,3 @@
----
-type: module
----
 
 ### Voice over IP
 

@@ -0,0 +1,3 @@
+---
+headless: true
+---
@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 The types of state events that affect authorization are:
 

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Servers MUST NOT strictly enforce the JSON format specified in the
 [appendices](/appendices#canonical-json) for the reasons

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events sent into rooms of this version can have formats which are different
 from their normal schema. Those cases are documented here.

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 ##### `m.room.power_levels` events accept values as strings
 

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 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

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{< added-in this=true >}} 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

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{% added-in this=true %}} In room versions 1 and 2, redactions were
 explicitly part of the [authorization rules](/rooms/v1/#authorization-rules)
 under Rule 11. As of room version 3, these conditions no longer exist as

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events in rooms of this version have the following structure:
 

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{% added-in this=true %}} The event ID is the [reference
 hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
 the event encoded using a variation of [Unpadded

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 When validating event signatures, servers MUST enforce the
 `valid_until_ts` property from a key request is at least as large as the

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Servers MUST strictly enforce the JSON format specified in the
 [appendices](/appendices#canonical-json). This translates to a

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events must be signed by the server denoted by the `sender` property.
 

@@ -1,5 +1,4 @@
 ---
-toc_hide: true
 ---
 
 {{% added-in this=true %}} `m.room.member` events now keep `join_authorised_via_users_server`