Repository: matrix-org/synapse

Issue:
Support Matrix 1.3
We should finish up implementation of Matrix 1.3, the first thing to do is to make a checklist of remaining tasks from the release notes (https://matrix.org/blog/2022/06/16/matrix-v-1-3-release#the-full-changelog):

----

## Client-Server API

* [x] Deprecate the `sender_key` and `device_id` on `m.megolm.v1.aes-sha2` events, and the `sender_key` on `m.room_key_request` to-device messages, as per MSC3700.
* [x] Make `from` optional on `GET /_matrix/client/v3/messages` to allow requesting events from the start or end of the room history, as per MSC3567.
* [x] Add refresh tokens, per MSC2918. #9450
* [x] Describe a structured system for event relationships, as per MSC2674.
* [x] Describe how relationships between events can be "aggregated", as per MSC2675 and MSC3666.

## Server-Server API

* [x] Add a destination property to the `Authorization` header, as per MSC3383. #11398

## Application Service API

* [x] Add timestamp massaging as per MSC3316. #11866

## Room Versions

* [x] Add room version 10 as per MSC3604. #13220
* [x] Update the default room version to 9 as per MSC3589. #12058

----

Other remaining things from above:

* [x] `/relations` returns an extra `original_event` field: #12930
  * See #14025.
* [x] Refresh tokens can be disabled currently.



Discussion:
I'm unsure if MSC3700 has anything for the server to do or not, but I found some of those keys by grepping the source.
> * Deprecate the `sender_key` and `device_id` on `m.megolm.v1.aes-sha2` events, and the `sender_key` on `m.room_key_request` to-device messages, as per [MSC3700](https://github.com/matrix-org/matrix-spec-proposals/pull/3700)

From a [conversation in `#synapse-dev`](https://matrix.to/#/!vcyiEtMVHIhWXcJAfl:sw1v.org/$u1KwVgcBUZbV7OkHwOwd2e9OHYRh2MCK5ZfwCOxgJvQ?via=matrix.org&via=element.io&via=beeper.com) it seems like there is nothing to do for MSC3700, @erikjohnston's summary:

> Yeah, [the `sender_key` and `device_id`] are only used as a dirty "oh look we don't know about that device and it should be cached whoops lets go and invalidate our cache"

> Refresh tokens can be disabled currently.

I believe this is fine since [the spec](https://spec.matrix.org/v1.3/client-server-api/#refreshing-access-tokens) says:

> Handling of clients that do not support refresh tokens is up to the homeserver; clients indicate their support for refresh tokens by including a refresh_token: true property in the request body of the [/login](https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3login) and [/register](https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3register) endpoints. For example, homeservers may allow the use of non-expiring access tokens, or may expire access tokens anyways and rely on soft logout behaviour on clients that don’t support refreshing.

Resolving patch:
diff --git a/synapse/rest/client/versions.py b/synapse/rest/client/versions.py
--- a/synapse/rest/client/versions.py
+++ b/synapse/rest/client/versions.py
@@ -75,6 +75,7 @@ def on_GET(self, request: Request) -> Tuple[int, JsonDict]:
                     "r0.6.1",
                     "v1.1",
                     "v1.2",
+                    "v1.3",
                 ],
                 # as per MSC1497:
                 "unstable_features": {


Test patch: