Merge 2fca4789ca into e9f219d53b

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

changelogs/client_server/newsfragments/2298.feature

@@ -0,0 +1 @@
+Add support for `m.room.redaction` events at the `PUT /rooms/{roomId}/send/{eventType}/{txnId}` endpoint, as per [MSC4169](https://github.com/matrix-org/matrix-spec-proposals/pull/4169).

content/client-server-api/_index.md

@@ -3315,6 +3315,14 @@ the topic to be removed from the room.
 
 #### Client behaviour
 
+{{% changed-in v="1.18" %}}
+
+If the server advertises support for a spec version that supports it, clients
+MAY use the [`PUT /rooms/{roomId}/send/{eventType}/{txnId}`](#put_matrixclientv3roomsroomidsendeventtypetxnid)
+endpoint to send `m.room.redaction` events in all room versions.
+
+They can also use the following endpoint.
+
 {{% http-api spec="client-server" api="redaction" %}}
 
 ### Forming relationships between events

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

@@ -21,14 +21,15 @@ recommendations.
 
 * Clients SHOULD create new [cross-signing keys](#cross-signing) for users who
   do not yet have cross-signing keys.
-* Users SHOULD have [Secret Storage](#storage) set up to avoid needing to reset
-  their cryptographic identity in case the user does not have an existing device
-  that can [share the secrets](#sharing) with the new device. The user's Secret
-  Storage SHOULD contain the user's cross-signing private keys and the [key
-  backup](#server-side-key-backups) decryption key (if the user is using key
-  backup). The user's Secret Storage SHOULD have a [default key](#key-storage)
-  (a key referred to by `m.secret_storage.default_key`) that encrypts the
-  private cross-signing keys and key backup decryption key (if available).
+* Clients SHOULD encourage users to set up their [Secret Storage](#storage) to
+  avoid needing to reset their cryptographic identity in case the user does not
+  have an existing device that can [share the secrets](#sharing) with the new
+  device. The user's Secret Storage SHOULD contain the user's cross-signing
+  private keys and the [key backup](#server-side-key-backups) decryption key
+  (if the user is using key backup). The user's Secret Storage SHOULD have a
+  [default key](#key-storage) (a key referred to by
+  `m.secret_storage.default_key`) that encrypts the private cross-signing keys
+  and key backup decryption key (if available).
 * Clients SHOULD encourage users to [cross-sign](#cross-signing) their devices.
   This includes both when logging in a new device, and for existing devices.
   Clients MAY even go so  far as to require cross-signing of devices by
@@ -42,7 +43,7 @@ recommendations.
   device keys) is deprecated.
 * Clients SHOULD flag when [cross-signing keys](#cross-signing) change. If
   Alice's cross-signing keys change, Alice's own devices MUST alert her to this
-  fact, and prompt her  to re-cross-sign those devices. If Bob is in an
+  fact, and prompt her to re-cross-sign those devices. If Bob is in an
   encrypted room with Alice,  Bob's devices SHOULD inform him of Alice's key
   change and SHOULD prevent him from sending an encrypted message to Alice
   without acknowledging the change. Bob's clients may behave differently
@@ -59,6 +60,11 @@ recommendations.
   [`m.room_key.withheld`](#mroom_keywithheld) message with a code of
   `m.unverified` to indicate to the non-cross-signed device why it is not
   receiving the room key.
+
+  Note that clients cannot selectively send room events only to cross-signed
+  devices. The only way to exclude non-cross-signed devices from encrypted
+  conversations is to not send the room keys so those devices won't be able to
+  decrypt the messages.
 * Similarly, messages sent from [non-cross-signed](#cross-signing) devices
   cannot be trusted and SHOULD NOT be displayed to the user. Clients have no
   assurance that encrypted messages sent from non-cross-signed devices were sent
@@ -80,7 +86,9 @@ recommendations.
   a different user. Clients MAY accept such messages, provided the session
   creator's device is [cross-signed](#cross-signing). However, the client MUST
   annotate the message with a warning, unless the client has a way to check that
-  the bridge bot is permitted to encrypt messages on behalf of the user.
+  the bridge bot is permitted to encrypt messages on behalf of the user. Future
+  MSCs such as [MSC4350](https://github.com/matrix-org/matrix-spec-proposals/pull/4350)
+  may provide a secure way to allow such impersonation.
 
 #### Key Distribution
 

data/api/client-server/room_send.yaml

@@ -20,6 +20,10 @@ paths:
   "/rooms/{roomId}/send/{eventType}/{txnId}":
     put:
       summary: Send a message event to the given room.
+      x-changedInMatrixVersion:
+        "1.18": |-
+          Homeservers must support sending `m.room.redaction` events with this endpoint
+          for all room versions.
       description: |-
         This endpoint is used to send a message event to a room. Message events
         allow access to historical events and pagination, making them suited
@@ -28,6 +32,11 @@ paths:
         The body of the request should be the content object of the event; the
         fields in this object will vary depending on the type of event. See
         [Room Events](/client-server-api/#room-events) for the m. event specification.
+
+        Homeservers MUST allow clients to send `m.room.redaction` events with this
+        endpoint for all room versions. In rooms with a version older than 11 they
+        MUST move the `redacts` property inside the `content` to the top level of
+        the event.
       operationId: sendMessage
       security:
         - accessTokenQuery: []