mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-08-03 22:47:49 +02:00
Compare commits
5 commits
115b4c400e
...
33500357af
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
33500357af | ||
|
|
e2b879d13d | ||
|
|
bf5fbc9945 | ||
|
|
1edf62c3f1 | ||
|
|
97fcfd93d9 |
1
changelogs/client_server/newsfragments/2404.breaking
Normal file
1
changelogs/client_server/newsfragments/2404.breaking
Normal file
|
|
@ -0,0 +1 @@
|
|||
Clients are now supposed to follow 30x redirects from `/.well-known/matrix/client` as per [MSC4402](https://github.com/matrix-org/matrix-spec-proposals/pull/4402).
|
||||
|
|
@ -0,0 +1 @@
|
|||
Use the User ID type in OlmPayload and DeviceKeys.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Wording improvements and spelling fixes. Contributed by @HarHarLinks.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Rename OlmPayload to OlmPlaintext to avoid confusion with Olm message Payload Bytes.
|
||||
|
|
@ -429,6 +429,7 @@ Instead, they can be reached via HTTPS on the [server name](/appendices/#server-
|
|||
|
||||
Servers hosting the `.well-known` JSON file SHOULD offer CORS headers,
|
||||
as per the [CORS](#web-browser-clients) section in this specification.
|
||||
{{% added-in v="1.20" %}} Servers SHOULD also ensure that each 30x redirect, if any, offers such CORS headers.
|
||||
{{% /boxes/note %}}
|
||||
|
||||
The flow for auto-discovery is as follows:
|
||||
|
|
@ -437,6 +438,7 @@ The flow for auto-discovery is as follows:
|
|||
Matrix ID at the first colon.
|
||||
2. Extract the hostname from the server name as described by the [grammar](/appendices/#server-name).
|
||||
3. Make a GET request to `https://hostname/.well-known/matrix/client`.
|
||||
{{% added-in v="1.20" %}} 30x redirects SHOULD be followed, however redirection loops should be avoided.
|
||||
1. If the returned status code is 404, then `IGNORE`.
|
||||
2. If the returned status code is not 200, or the response body is
|
||||
empty, then `FAIL_PROMPT`.
|
||||
|
|
@ -3660,7 +3662,7 @@ The actual aggregation format depends on the `rel_type`.
|
|||
|
||||
When an event is served to the client through the APIs listed below, a
|
||||
`m.relations` property is included under `unsigned` if the event has child
|
||||
events which can be aggregated and point at it. The `m.relations` property is
|
||||
events which can be aggregated. The `m.relations` property is
|
||||
an object keyed by `rel_type` and value being the type-specific aggregated
|
||||
format for that `rel_type`. This `m.relations` property is known as a "bundled
|
||||
aggregation".
|
||||
|
|
|
|||
|
|
@ -1772,12 +1772,9 @@ Messages with type 1 can only be decrypted with an existing session. If
|
|||
there is no matching session, the client must treat this as an invalid
|
||||
message.
|
||||
|
||||
The plaintext payload is of the form:
|
||||
The plaintext corresponding to the "Cipher-Text" in an an [Olm message](/olm-megolm/olm/#normal-messages) is of the form:
|
||||
|
||||
{{% definition path="api/client-server/definitions/olm_payload" %}}
|
||||
|
||||
The type and content of the plaintext message event are given in the
|
||||
payload.
|
||||
{{% definition path="api/client-server/definitions/olm_plaintext" %}}
|
||||
|
||||
If a client has multiple sessions established with another device, it
|
||||
should use the session from which it last received and successfully
|
||||
|
|
@ -1950,7 +1947,7 @@ As of `v1.3`, the `sender_key` and `device_id` keys are **deprecated**. They
|
|||
SHOULD continue to be sent, however they MUST NOT be used to verify the
|
||||
message's source.
|
||||
|
||||
Clients MUST NOT store or lookup sessions using the `sender_key` or `device_id`.
|
||||
Clients MUST NOT store or look up sessions using the `sender_key` or `device_id`.
|
||||
|
||||
In a future version of the specification the keys can be removed completely,
|
||||
including for sending new messages.
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ Note that, as in the example above, child events of the `latest_event` should
|
|||
themselves be aggregated and included under `m.relations` for that event. The
|
||||
server should be careful to avoid loops, though loops are not currently
|
||||
possible due to `m.thread` not being permitted to target an event with an
|
||||
`m.relates_to` property.
|
||||
`m.relates_to` property with a `rel_type`.
|
||||
|
||||
`count` is simply the number of events using `m.thread` as a `rel_type` pointing to the target event.
|
||||
It does not include events sent by [ignored users](#ignoring-users).
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ properties:
|
|||
description: |-
|
||||
The ID of the user the device belongs to. Must match the user ID used
|
||||
when logging in.
|
||||
format: mx-user-id
|
||||
pattern: "^@"
|
||||
example: "@alice:example.com"
|
||||
device_id:
|
||||
type: string
|
||||
|
|
|
|||
|
|
@ -14,9 +14,9 @@
|
|||
|
||||
|
||||
type: object
|
||||
title: OlmPayload
|
||||
title: OlmPlaintext
|
||||
description: |-
|
||||
The plaintext payload of an event encrypted using Olm.
|
||||
The plaintext of an event encrypted using Olm.
|
||||
properties:
|
||||
type:
|
||||
type: string
|
||||
|
|
@ -27,9 +27,13 @@ properties:
|
|||
sender:
|
||||
type: string
|
||||
description: The user ID of the event sender.
|
||||
format: mx-user-id
|
||||
pattern: "^@"
|
||||
recipient:
|
||||
type: string
|
||||
description: The user ID of the intended event recipient.
|
||||
format: mx-user-id
|
||||
pattern: "^@"
|
||||
recipient_keys:
|
||||
description: The recipient's signing keys of the encrypted event.
|
||||
$ref: "#/components/schemas/SigningKeys"
|
||||
|
|
@ -1,4 +1,5 @@
|
|||
# Copyright 2018 New Vector Ltd
|
||||
# Copyright 2026 Hagen Echzell
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
|
|
@ -20,7 +21,11 @@ paths:
|
|||
get:
|
||||
summary: Gets Matrix server discovery information about the domain.
|
||||
description: |-
|
||||
Gets discovery information about the domain. The file may include
|
||||
Gets discovery information about the domain.
|
||||
{{% added-in v="1.20" %}} Clients SHOULD follow 30x redirects, carefully
|
||||
avoiding redirect loops, and use normal X.509 certificate validation.
|
||||
|
||||
The file may include
|
||||
additional keys, which MUST follow the Java package naming convention,
|
||||
e.g. `com.example.myapp.property`. This ensures property names are
|
||||
suitably namespaced for each application and reduces the risk of
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ description: |-
|
|||
[Olm](/client-server-api/#molmv1curve25519-aes-sha2).
|
||||
|
||||
The `sender_device_keys` property in the [Olm
|
||||
plaintext](/client-server-api/#definition-olmpayload) MUST be
|
||||
plaintext](/client-server-api/#definition-olmplaintext) MUST be
|
||||
populated. Recipients SHOULD ignore `m.room_key_bundle` messages which omit
|
||||
them.
|
||||
properties:
|
||||
|
|
|
|||
Loading…
Reference in a new issue