Merge 70f6749c92 into 21109b4d5b

Signed-off-by: famfo <famfo@famfo.xyz>

changelogs/client_server/newsfragments/2214.clarification

@@ -0,0 +1 @@
+Push rule IDs are globally unique within their kind.

changelogs/client_server/newsfragments/2215.clarification

@@ -0,0 +1 @@
+Don't advertise `creator` field in description of room creation.

changelogs/server_server/newsfragments/2191.clarification

@@ -0,0 +1 @@
+Clarify what the minimum_valid_until_ts field means when it is set in key queries.

content/client-server-api/_index.md

@@ -3386,10 +3386,10 @@ Unspecified room types are permitted through the use of
 ### Creation
 
 The homeserver will create an `m.room.create` event when a room is
-created, which serves as the root of the event graph for this room. This
+created, which serves as the root of the event graph for this room. The
-event also has a `creator` key which contains the user ID of the room
+event `sender` is the user ID of the room creator. The server will also
-creator. It will also generate several other events in order to manage
+generate several other events in order to manage permissions in this room.
-permissions in this room. This includes:
+This includes:
 
 -   `m.room.power_levels` : Sets the power levels of users and required power
     levels for various actions within the room such as sending events.

content/client-server-api/modules/push.md

@@ -83,7 +83,7 @@ Push Ruleset
 :   A push ruleset *scopes a set of rules according to some criteria*. For
     example, some rules may only be applied for messages from a particular
     sender, a particular room, or by default. The push ruleset contains the
-    entire set of scopes and rules.
+    entire set of rules.
 
 #### Push Rules
 
@@ -91,10 +91,8 @@ A push rule is a single rule that states under what *conditions* an
 event should be passed onto a push gateway and *how* the notification
 should be presented. There are different "kinds" of push rules and each
 rule has an associated priority. Every push rule MUST have a `kind` and
-`rule_id`. The `rule_id` is a unique string within the kind of rule and
+`rule_id`. The `rule_id` is a unique string within the kind of rule.
-its' scope: `rule_ids` do not need to be unique between rules of the
+Rules may have extra keys depending on the value of `kind`.
-same kind on different devices. Rules may have extra keys depending on
-the value of `kind`.
 
 The different `kind`s of rule, in the order that they are checked, are:
 

data/api/server-server/keys_query.yaml

@@ -34,8 +34,8 @@ paths:
         - in: query
           name: minimum_valid_until_ts
           description: |-
-            A millisecond POSIX timestamp in milliseconds indicating when the returned
+            A millisecond POSIX timestamp. The returned keys MUST be valid
-            certificates will need to be valid until to be useful to the requesting server.
+            until at least this timestamp.
 
             If not supplied, the current time as determined by the notary server is used.
           required: false
@@ -98,9 +98,8 @@ paths:
                           type: integer
                           format: int64
                           description: |-
-                            A millisecond POSIX timestamp in milliseconds indicating when
+                            A millisecond POSIX timestamp. The returned keys
-                            the returned certificates will need to be valid until to be
+                            MUST be valid until at least this timestamp.
-                            useful to the requesting server.
 
                             If not supplied, the current time as determined by the notary
                             server is used.