Fix internal links
This commit is contained in:
Will
parent
338434bfcd
commit
4e39200cfa
30 changed files with 194 additions and 792 deletions
|
|
@ -29,4 +29,4 @@ These events can also be received in a `/events` response or in the
|
|||
|
||||
Servers MUST reject clients from setting account data for event types
|
||||
that the server manages. Currently, this only includes
|
||||
[m.fully\_read]().
|
||||
[m.fully\_read](#mfully_read).
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ weight: 90
|
|||
|
||||
### Device Management
|
||||
|
||||
This module provides a means for a user to manage their [devices]().
|
||||
This module provides a means for a user to manage their [devices](/#devices).
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ a person's profile picture would imply the `is_direct` flag should be
|
|||
set.
|
||||
|
||||
The invitee's client may use the `is_direct` flag in the
|
||||
[m.room.member]() event to automatically mark the room as a direct chat
|
||||
[m.room.member](#mroommember) event to automatically mark the room as a direct chat
|
||||
but this is not required: it may for example, prompt the user, or ignore
|
||||
the flag altogether.
|
||||
|
||||
|
|
|
|||
|
|
@ -57,13 +57,13 @@ keys.
|
|||
|
||||
The name `ed25519` corresponds to the
|
||||
[Ed25519](http://ed25519.cr.yp.to/) signature algorithm. The key is a
|
||||
32-byte Ed25519 public key, encoded using [unpadded Base64](). Example:
|
||||
32-byte Ed25519 public key, encoded using [unpadded Base64](/appendices/#unpadded-base64). Example:
|
||||
|
||||
"SogYyrkTldLz0BXP+GYWs0qaYacUI0RleEqNT8J3riQ"
|
||||
|
||||
The name `curve25519` corresponds to the
|
||||
[Curve25519](https://cr.yp.to/ecdh.html) ECDH algorithm. The key is a
|
||||
32-byte Curve25519 public key, encoded using [unpadded Base64]().
|
||||
32-byte Curve25519 public key, encoded using [unpadded Base64](/appendices/#unpadded-base64).
|
||||
Example:
|
||||
|
||||
"JGLn/yafz74HB2AbPLYJWIVGnKAtqECOBf11yyXac2Y"
|
||||
|
|
@ -92,7 +92,7 @@ with the following properties:
|
|||
<td><p>signatures</p></td>
|
||||
<td><p>Signatures</p></td>
|
||||
<td><p><strong>Required.</strong> Signatures of the key object.</p>
|
||||
<p>The signature is calculated using the process described at <a href="../appendices.html#signing-json">Signing JSON</a>.</p></td>
|
||||
<p>The signature is calculated using the process described at <a href="/appendices/#signing-json">Signing JSON</a>.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -134,7 +134,7 @@ A device uploads the public parts of identity keys to their homeserver
|
|||
as a signed JSON object, using the `/keys/upload`\_ API. The JSON object
|
||||
must include the public part of the device's Ed25519 key, and must be
|
||||
signed by that key, as described in [Signing
|
||||
JSON](../appendices.html#signing-json).
|
||||
JSON](/appendices/#signing-json).
|
||||
|
||||
One-time keys are also uploaded to the homeserver using the
|
||||
`/keys/upload`\_ API.
|
||||
|
|
@ -270,7 +270,7 @@ Extensions to `m.room.message` msgtypes
|
|||
|
||||
This module adds `file` and `thumbnail_file` properties, of type
|
||||
`EncryptedFile`, to `m.room.message` msgtypes that reference files, such
|
||||
as [m.file]() and [m.image](), replacing the `url` and `thumbnail_url`
|
||||
as [m.file](#mfile) and [m.image](#mimage), replacing the `url` and `thumbnail_url`
|
||||
properties.
|
||||
|
||||
`EncryptedFile`
|
||||
|
|
@ -508,7 +508,7 @@ example, if we verify 40 bits, then an attacker has a 1 in
|
|||
success. A failed attack would result in a mismatched Short
|
||||
Authentication String, alerting users to the attack.
|
||||
|
||||
The verification process takes place over [to-device]() messages in two
|
||||
The verification process takes place over [to-device](#send-to-device-messaging) messages in two
|
||||
phases:
|
||||
|
||||
1. Key agreement phase (based on [ZRTP key
|
||||
|
|
@ -566,7 +566,7 @@ The process between Alice and Bob verifying each other would be:
|
|||
hash function. HMAC is defined in [RFC
|
||||
2104](https://tools.ietf.org/html/rfc2104). The key for the HMAC is
|
||||
different for each item and is calculated by generating 32 bytes
|
||||
(256 bits) using [the key verification HKDF](#sas-hkdf).
|
||||
(256 bits) using [the key verification HKDF](#hkdf-calculation).
|
||||
18. Alice's device sends Bob's device an `m.key.verification.mac`
|
||||
message containing the MAC of Alice's device keys and the MAC of her
|
||||
key IDs to be verified. Bob's device does the same for Bob's device
|
||||
|
|
@ -721,7 +721,7 @@ parameter is the concatenation of:
|
|||
|
||||
###### SAS method: `decimal`
|
||||
|
||||
Generate 5 bytes using [HKDF](#sas-hkdf) then take sequences of 13 bits
|
||||
Generate 5 bytes using [HKDF](#hkdf-calculation) then take sequences of 13 bits
|
||||
to convert to decimal numbers (resulting in 3 numbers between 0 and 8191
|
||||
inclusive each). Add 1000 to each calculated number.
|
||||
|
||||
|
|
@ -739,7 +739,7 @@ separator, such as dashes, or with the numbers on individual lines.
|
|||
|
||||
###### SAS method: `emoji`
|
||||
|
||||
Generate 6 bytes using [HKDF](#sas-hkdf) then split the first 42 bits
|
||||
Generate 6 bytes using [HKDF](#hkdf-calculation) then split the first 42 bits
|
||||
into 7 groups of 6 bits, similar to how one would base64 encode
|
||||
something. Convert each group of 6 bits to a number and use the
|
||||
following table to get the corresponding emoji:
|
||||
|
|
@ -933,20 +933,20 @@ device to another.
|
|||
##### Key requests
|
||||
|
||||
When a device is missing keys to decrypt messages, it can request the
|
||||
keys by sending [m.room\_key\_request]() to-device messages to other
|
||||
keys by sending [m.room\_key\_request](#mroom_key_request) to-device messages to other
|
||||
devices with `action` set to `request`.
|
||||
|
||||
If a device wishes to share the keys with that device, it can forward
|
||||
the keys to the first device by sending an encrypted
|
||||
[m.forwarded\_room\_key]() to-device message. The first device should
|
||||
then send an [m.room\_key\_request]() to-device message with `action`
|
||||
[m.forwarded\_room\_key](#mforwarded_room_key) to-device message. The first device should
|
||||
then send an [m.room\_key\_request](#mroom_key_request) to-device message with `action`
|
||||
set to `request_cancellation` to the other devices that it had
|
||||
originally sent the key request to; a device that receives a
|
||||
`request_cancellation` should disregard any previously-received
|
||||
`request` message with the same `request_id` and `requesting_device_id`.
|
||||
|
||||
If a device does not wish to share keys with that device, it can
|
||||
indicate this by sending an [m.room\_key.withheld]() to-device message,
|
||||
indicate this by sending an [m.room\_key.withheld](#mroom_key.withheld) to-device message,
|
||||
as described in [Reporting that decryption keys are
|
||||
withheld](#reporting-that-decryption-keys-are-withheld).
|
||||
|
||||
|
|
@ -969,17 +969,17 @@ However, as the session keys are stored on the server encrypted, it
|
|||
requires users to enter a decryption key to decrypt the session keys.
|
||||
|
||||
To create a backup, a client will call [POST
|
||||
/\_matrix/client/r0/room\_keys/version]() and define how the keys are to
|
||||
/\_matrix/client/r0/room\_keys/version](#post_matrixclientr0room_keysversion) and define how the keys are to
|
||||
be encrypted through the backup's `auth_data`; other clients can
|
||||
discover the backup by calling [GET
|
||||
/\_matrix/client/r0/room\_keys/version](). Keys are encrypted according
|
||||
/\_matrix/client/r0/room\_keys/version](#get_matrixclientr0room_keysversion). Keys are encrypted according
|
||||
to the backup's `auth_data` and added to the backup by calling [PUT
|
||||
/\_matrix/client/r0/room\_keys/keys]() or one of its variants, and can
|
||||
be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys]() or
|
||||
be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#put_matrixclientr0room_keyskeys) or
|
||||
one of its variants. Keys can only be written to the most recently
|
||||
created version of the backup. Backups can also be deleted using [DELETE
|
||||
/\_matrix/client/r0/room\_keys/version/{version}](), or individual keys
|
||||
can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys]() or
|
||||
/\_matrix/client/r0/room\_keys/version/{version}](#delete_matrixclientr0room_keysversionversion), or individual keys
|
||||
can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys](#delete_matrixclientr0room_keyskeys) or
|
||||
one of its variants.
|
||||
|
||||
Clients must only store keys in backups after they have ensured that the
|
||||
|
|
@ -1071,7 +1071,7 @@ The `session_data` field in the backups is constructed as follows:
|
|||
<tr class="even">
|
||||
<td><p>forwarding_curve25519_key_chain</p></td>
|
||||
<td><p>[string]</p></td>
|
||||
<td><p><strong>Required.</strong> Chain of Curve25519 keys through which this session was forwarded, via <a href="">m.forwarded_room_key</a> events.</p></td>
|
||||
<td><p><strong>Required.</strong> Chain of Curve25519 keys through which this session was forwarded, via <a href="#mforwarded_room_key">m.forwarded_room_key</a> events.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td><p>sender_key</p></td>
|
||||
|
|
@ -1205,7 +1205,7 @@ objects described as follows:
|
|||
<tr class="even">
|
||||
<td><p>forwarding_curve25519_key_chain</p></td>
|
||||
<td><p>[string]</p></td>
|
||||
<td><p>Required. Chain of Curve25519 keys through which this session was forwarded, via <a href="">m.forwarded_room_key</a> events.</p></td>
|
||||
<td><p>Required. Chain of Curve25519 keys through which this session was forwarded, via <a href="#mforwarded_room_key">m.forwarded_room_key</a> events.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td><p>room_id</p></td>
|
||||
|
|
@ -1396,7 +1396,7 @@ a way to recover from the failure, making this session replacement
|
|||
process required.
|
||||
{{% /boxes/note %}}
|
||||
|
||||
To establish a new session, the client sends an [m.dummy](#m-dummy)
|
||||
To establish a new session, the client sends an [m.dummy](#mdummy)
|
||||
to-device event to the other party to notify them of the new session
|
||||
details.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ should interact with servers in order to participate in rooms as guests.
|
|||
|
||||
Guest users retrieve access tokens from a homeserver using the ordinary
|
||||
[register
|
||||
endpoint](#post-matrix-client-%CLIENT_MAJOR_VERSION%-register),
|
||||
endpoint](#post_matrixclientr0register),
|
||||
specifying the `kind` parameter as `guest`. They may then interact with
|
||||
the client-server API as any other user would, but will only have access
|
||||
to a subset of the API as described the Client behaviour subsection
|
||||
|
|
@ -39,55 +39,38 @@ rather than allowing all homeservers to enforce the rules on each other.
|
|||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
for retrieving events:
|
||||
|
||||
- [GET
|
||||
/rooms/:room\_id/state](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-state)
|
||||
- [GET
|
||||
/rooms/:room\_id/context/:event\_id](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-context-eventid)
|
||||
- [GET
|
||||
/rooms/:room\_id/event/:event\_id](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-event-eventid)
|
||||
- [GET
|
||||
/rooms/:room\_id/state/:event\_type/:state\_key](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-state-eventtype-statekey)
|
||||
- [GET
|
||||
/rooms/:room\_id/messages](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-messages)
|
||||
- [GET
|
||||
/rooms/:room\_id/members](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-members)
|
||||
- [GET
|
||||
/rooms/:room\_id/initialSync](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-initialsync)
|
||||
- [GET /sync](#get-matrix-client-%CLIENT_MAJOR_VERSION%-sync)
|
||||
- [GET /events]() as used for room previews.
|
||||
- [GET /rooms/:room\_id/state](#get_matrixclientr0roomsroomidstate)
|
||||
- [GET /rooms/:room\_id/context/:event\_id](#get_matrixclientr0roomsroomidcontexteventid)
|
||||
- [GET /rooms/:room\_id/event/:event\_id](#get_matrixclientr0roomsroomideventeventid)
|
||||
- [GET /rooms/:room\_id/state/:event\_type/:state\_key](#get_matrixclientr0roomsroomidstateeventtypestatekey)
|
||||
- [GET /rooms/:room\_id/messages](#get_matrixclientr0roomsroomidmessages)
|
||||
- [GET /rooms/:room\_id/members](#get_matrixclientr0roomsroomidmembers)
|
||||
- [GET /rooms/:room\_id/initialSync](#get_matrixclientr0roomsroomidinitialsync)
|
||||
- [GET /sync](#get_matrixclientr0sync)
|
||||
- [GET /events](#get_matrixclientr0events) as used for room previews.
|
||||
|
||||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
for sending events:
|
||||
|
||||
- [POST
|
||||
/rooms/:room\_id/join](#post-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-join)
|
||||
- [POST
|
||||
/rooms/:room\_id/leave](#post-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-leave)
|
||||
- [PUT
|
||||
/rooms/:room\_id/send/m.room.message/:txn\_id](#put-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-send-eventtype-txnid)
|
||||
- [PUT
|
||||
/sendToDevice/{eventType}/{txnId}](#put-matrix-client-%CLIENT_MAJOR_VERSION%-sendtodevice-eventtype-txnid)
|
||||
- [POST /rooms/:room\_id/join](#post_matrixclientr0roomsroomidjoin)
|
||||
- [POST /rooms/:room\_id/leave](#post_matrixclientr0roomsroomidleave)
|
||||
- [PUT /rooms/:room\_id/send/m.room.message/:txn\_id](#put_matrixclientr0roomsroomidsendeventtypetxnid)
|
||||
- [PUT /sendToDevice/{eventType}/{txnId}](#put_matrixclientr0sendtodeviceeventtypetxnid)
|
||||
|
||||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
for their own account maintenance:
|
||||
|
||||
- [PUT
|
||||
/profile/:user\_id/displayname](#put-matrix-client-%CLIENT_MAJOR_VERSION%-profile-userid-displayname)
|
||||
- [GET /devices](#get-matrix-client-%CLIENT_MAJOR_VERSION%-devices)
|
||||
- [GET
|
||||
/devices/{deviceId}](#get-matrix-client-%CLIENT_MAJOR_VERSION%-devices-deviceid)
|
||||
- [PUT
|
||||
/devices/{deviceId}](#put-matrix-client-%CLIENT_MAJOR_VERSION%-devices-deviceid)
|
||||
- [PUT /profile/:user\_id/displayname](#put_matrixclientr0profileuseriddisplayname)
|
||||
- [GET /devices](#get_matrixclientr0devices)
|
||||
- [GET /devices/{deviceId}](#get_matrixclientr0devicesdeviceid)
|
||||
- [PUT /devices/{deviceId}](#put_matrixclientr0devicesdeviceid)
|
||||
|
||||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
for end-to-end encryption:
|
||||
|
||||
- [POST
|
||||
/keys/upload](#post-matrix-client-%CLIENT_MAJOR_VERSION%-keys-upload)
|
||||
- [POST
|
||||
/keys/query](#post-matrix-client-%CLIENT_MAJOR_VERSION%-keys-query)
|
||||
- [POST
|
||||
/keys/claim](#post-matrix-client-%CLIENT_MAJOR_VERSION%-keys-claim)
|
||||
- [POST /keys/upload](#post_matrixclientr0keysupload)
|
||||
- [POST /keys/query](#post_matrixclientr0keysquery)
|
||||
- [POST /keys/claim](#post_matrixclientr0keysclaim)
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ room itself such as a room name and topic.
|
|||
Usage of this event is discouraged for several reasons:
|
||||
- The number of feedback events will grow very quickly with the number
|
||||
of users in the room. This event provides no way to "batch"
|
||||
feedback, unlike the [receipts module]().
|
||||
feedback, unlike the [receipts module](#receipts).
|
||||
- Pairing feedback to messages gets complicated when paginating as
|
||||
feedback arrives before the message it is acknowledging.
|
||||
- There are no guarantees that the client has seen the event ID being
|
||||
|
|
@ -34,7 +34,7 @@ Usage of this event is discouraged for several reasons:
|
|||
|
||||
##### m.room.message msgtypes
|
||||
|
||||
Each [m.room.message]() MUST have a `msgtype` key which identifies the
|
||||
Each [m.room.message](#m.room.message) MUST have a `msgtype` key which identifies the
|
||||
type of message being sent. Each type has their own required and
|
||||
optional keys, as outlined below. If a client cannot display the given
|
||||
`msgtype` then it SHOULD display the fallback plain text `body` key
|
||||
|
|
@ -74,7 +74,7 @@ scheme matching one of: `https`, `http`, `ftp`, `mailto`, `magnet`)
|
|||
|
||||
`img`
|
||||
`width`, `height`, `alt`, `title`, `src` (provided it is a [Matrix
|
||||
Content (MXC) URI]())
|
||||
Content (MXC) URI](#matrix-content-mxc-uris))
|
||||
|
||||
`ol`
|
||||
`start`
|
||||
|
|
@ -128,15 +128,16 @@ can either be replaced with placeholder text (e.g. "\[REDACTED\]") or
|
|||
the redacted message can be removed entirely from the messages view.
|
||||
|
||||
Events which have attachments (e.g. `m.image`, `m.file`) SHOULD be
|
||||
uploaded using the [content repository module]() where available. The
|
||||
resulting `mxc://` URI can then be used in the `url` key.
|
||||
uploaded using the [content repository module](#content-repository)
|
||||
where available. The resulting `mxc://` URI can then be used in the `url`
|
||||
key.
|
||||
|
||||
Clients MAY include a client generated thumbnail image for an attachment
|
||||
under a `info.thumbnail_url` key. The thumbnail SHOULD also be a
|
||||
`mxc://` URI. Clients displaying events with attachments can either use
|
||||
the client generated thumbnail or ask its homeserver to generate a
|
||||
thumbnail from the original attachment using the [content repository
|
||||
module]().
|
||||
module](#content-repository).
|
||||
|
||||
##### Recommendations when sending messages
|
||||
|
||||
|
|
@ -259,15 +260,15 @@ number of possibilities for choosing a useful name. To ensure that rooms
|
|||
are named consistently across clients, clients SHOULD use the following
|
||||
algorithm to choose a name:
|
||||
|
||||
1. If the room has an [m.room.name]() state event with a non-empty
|
||||
1. If the room has an [m.room.name](#m.room.name) state event with a non-empty
|
||||
`name` field, use the name given by that field.
|
||||
2. If the room has an [m.room.canonical\_alias]() state event with a
|
||||
2. If the room has an [m.room.canonical\_alias](#m.room.canonical_alias) state event with a
|
||||
valid `alias` field, use the alias given by that field as the name.
|
||||
Note that clients should avoid using `alt_aliases` when calculating
|
||||
the room name.
|
||||
3. If none of the above conditions are met, a name should be composed
|
||||
based on the members of the room. Clients should consider
|
||||
[m.room.member]() events for users other than the logged-in user, as
|
||||
[m.room.member](#m.room.member) events for users other than the logged-in user, as
|
||||
defined below.
|
||||
1. If the number of `m.heroes` for the room are greater or equal to
|
||||
`m.joined_member_count + m.invited_member_count - 1`, then use
|
||||
|
|
@ -382,7 +383,7 @@ The `formatted_body` should use the following template:
|
|||
If the related event does not have a `formatted_body`, the event's
|
||||
`body` should be considered after encoding any HTML special characters.
|
||||
Note that the `href` in both of the anchors use a [matrix.to
|
||||
URI](../appendices.html#matrix-to-navigation).
|
||||
URI](/appendices#matrixto-navigation).
|
||||
|
||||
######## Stripping the fallback
|
||||
|
||||
|
|
@ -477,7 +478,7 @@ status code of 400.
|
|||
#### Security considerations
|
||||
|
||||
Messages sent using this module are not encrypted, although end to end
|
||||
encryption is in development (see [E2E module]()).
|
||||
encryption is in development (see [E2E module](#end-to-end-encryption)).
|
||||
|
||||
Clients should sanitise **all displayed keys** for unsafe HTML to
|
||||
prevent Cross-Site Scripting (XSS) attacks. This includes room names and
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@ weight: 300
|
|||
|
||||
This module allows users to mention other users, rooms, and groups
|
||||
within a room message. This is achieved by including a [matrix.to
|
||||
URI](../appendices.html#matrix-to-navigation) in the HTML body of an
|
||||
[m.room.message]() event. This module does not have any server-specific
|
||||
URI](/appendices/#matrixto-navigation) in the HTML body of an
|
||||
[m.room.message](#mroommessage) event. This module does not have any server-specific
|
||||
behaviour to it.
|
||||
|
||||
Mentions apply only to [m.room.message]() events where the `msgtype` is
|
||||
Mentions apply only to [m.room.message](#mroommessage) events where the `msgtype` is
|
||||
`m.text`, `m.emote`, or `m.notice`. The `format` for the event must be
|
||||
`org.matrix.custom.html` and therefore requires a `formatted_body`.
|
||||
|
||||
|
|
|
|||
|
|
@ -253,7 +253,7 @@ Parameters:
|
|||
|
||||
- `key`: A string that determines the power level the sender must have
|
||||
to trigger notifications of a given type, such as `room`. Refer to
|
||||
the [m.room.power\_levels]() event schema for information about what
|
||||
the [m.room.power\_levels](#mroompower_levels) event schema for information about what
|
||||
the defaults are and how to interpret the event. The `key` is used
|
||||
to look up the power level required to send a notification type from
|
||||
the `notifications` object in the power level event content.
|
||||
|
|
|
|||
|
|
@ -7,22 +7,22 @@ weight: 170
|
|||
|
||||
It is sometimes desirable to offer a preview of a room, where a user can
|
||||
"lurk" and read messages posted to the room, without joining the room.
|
||||
This can be particularly effective when combined with [Guest Access]().
|
||||
This can be particularly effective when combined with [Guest Access](#guest-access).
|
||||
|
||||
Previews are implemented via the `world_readable` [Room History
|
||||
Visibility](). setting, along with a special version of the [GET
|
||||
/events](#get-matrix-client-%CLIENT_MAJOR_VERSION%-events) endpoint.
|
||||
Visibility](#room-history-visibility). setting, along with a special version of the [GET
|
||||
/events](#get_matrixclientr0events) endpoint.
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
A client wishing to view a room without joining it should call [GET
|
||||
/rooms/:room\_id/initialSync](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-initialsync),
|
||||
followed by [GET /events](#peeking_events_api). Clients will need to do
|
||||
/rooms/:room\_id/initialSync](#get_matrixclientr0roomsroomidinitialsync),
|
||||
followed by [GET /events](#get_matrixclientr0events). Clients will need to do
|
||||
this in parallel for each room they wish to view.
|
||||
|
||||
Clients can of course also call other endpoints such as [GET
|
||||
/rooms/:room\_id/messages](#get-matrix-client-%CLIENT_MAJOR_VERSION%-rooms-roomid-messages)
|
||||
and [GET /search](#get-matrix-client-%CLIENT_MAJOR_VERSION%-search) to
|
||||
/rooms/:room\_id/messages](#get_matrixclientr0roomsroomidmessages)
|
||||
and [GET /search](#post_matrixclientr0search) to
|
||||
access events outside the `/events` stream.
|
||||
|
||||
{{peeking\_events\_cs\_http\_api}}
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ as a string.
|
|||
#### Storage
|
||||
|
||||
When secrets are stored on the server, they are stored in the user's
|
||||
[account-data](#module-account-data), using an event type equal to the
|
||||
[account-data](#client-config), using an event type equal to the
|
||||
secret's identifier. The keys that secrets are encrypted with are
|
||||
described by data that is also stored in the user's account-data. Users
|
||||
can have multiple keys, allowing them to control what sets of secrets
|
||||
|
|
@ -103,7 +103,7 @@ of the data.
|
|||
<tr class="odd">
|
||||
<td><p>encrypted</p></td>
|
||||
<td><p>{string: object}</p></td>
|
||||
<td><p><strong>Required.</strong> Map from key ID the encrypted data. The exact format for the encrypted data is dependent on the key algorithm. See the definition of <code>AesHmacSha2EncryptedData</code> in the <a href="#m.secret_storage.v1.aes-hmac-sha2">m.secret_storage.v1.aes-hmac-sha2</a> section.</p></td>
|
||||
<td><p><strong>Required.</strong> Map from key ID the encrypted data. The exact format for the encrypted data is dependent on the key algorithm. See the definition of <code>AesHmacSha2EncryptedData</code> in the <a href="#msecret_storagev1aes-hmac-sha2">m.secret_storage.v1.aes-hmac-sha2</a> section.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ type: module
|
|||
weight: 80
|
||||
---
|
||||
|
||||
### Send-to-Device messaging<span id="module:to_device"></span>
|
||||
### Send-to-Device messaging
|
||||
|
||||
This module provides a means by which clients can exchange signalling
|
||||
messages without them being stored permanently as part of a shared
|
||||
|
|
@ -48,7 +48,7 @@ recommended as a reasonable limit.
|
|||
|
||||
If the client sends messages to users on remote domains, those messages
|
||||
should be sent on to the remote servers via
|
||||
[federation](../server_server/%SERVER_RELEASE_LABEL%.html#send-to-device-messaging).
|
||||
[federation](/server-server-api#send-to-device-messaging).
|
||||
|
||||
#### Protocol definitions
|
||||
|
||||
|
|
|
|||
|
|
@ -7,14 +7,14 @@ weight: 290
|
|||
|
||||
In some scenarios room operators may wish to prevent a malicious or
|
||||
untrusted server from participating in their room. Sending an
|
||||
[m.room.server\_acl]() state event into a room is an effective way to
|
||||
[m.room.server\_acl](#mroomserver_acl) state event into a room is an effective way to
|
||||
prevent the server from participating in the room at the federation
|
||||
level.
|
||||
|
||||
Server ACLs can also be used to make rooms only federate with a limited
|
||||
set of servers, or retroactively make the room no longer federate with
|
||||
any other server, similar to setting the `m.federate` value on the
|
||||
[m.room.create]() event.
|
||||
[m.room.create](#mroomcreate) event.
|
||||
|
||||
{{m\_room\_server\_acl\_event}}
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ excluded from the room.
|
|||
#### Server behaviour
|
||||
|
||||
Servers MUST prevent blacklisted servers from sending events or
|
||||
participating in the room when an [m.room.server\_acl]() event is
|
||||
participating in the room when an [m.room.server\_acl](#mroomserver_acl) event is
|
||||
present in the room state. Which APIs are specifically affected are
|
||||
described in the Server-Server API specification.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ encouraged to treat syncing users as "active".
|
|||
|
||||
Clients can identify the server notices room by the `m.server_notice`
|
||||
tag on the room. Active notices are represented by the [pinned
|
||||
events](#m-room-pinned-events) in the server notices room. Server notice
|
||||
events](#mroompinned_events) in the server notices room. Server notice
|
||||
events pinned in that room should be shown to the user through special
|
||||
UI and not through the normal pinned events interface in the client. For
|
||||
example, clients may show warning banners or bring up dialogs to get the
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ used to communicate with the authentication server. Different Matrix
|
|||
homeserver implementations might support different SSO protocols.
|
||||
|
||||
Clients and homeservers implementing the SSO flow will need to consider
|
||||
both [login]() and [user-interactive authentication](). The flow is
|
||||
both [login](#login) and [user-interactive authentication](#user-interactive-authentication-api). The flow is
|
||||
similar in both cases, but there are slight differences.
|
||||
|
||||
Typically, SSO systems require a single "callback" URI to be configured
|
||||
|
|
@ -170,9 +170,9 @@ The homeserver then proceeds as follows:
|
|||
|
||||
1. The homeserver MUST map the user details received from the
|
||||
authentication server to a valid [Matrix user
|
||||
identifier](../appendices.html#user-identifiers). The guidance in
|
||||
identifier](/appendices#user-identifiers). The guidance in
|
||||
[Mapping from other character
|
||||
sets](../appendices.html#mapping-from-other-character-sets) may be
|
||||
sets](/appendices#mapping-from-other-character-sets) may be
|
||||
useful.
|
||||
2. If the generated user identifier represents a new user, it should be
|
||||
registered as a new user.
|
||||
|
|
@ -212,7 +212,7 @@ The homeserver then proceeds as follows:
|
|||
|
||||
It may be appropriate to whitelist a set of known-trusted client
|
||||
URLs in this process. In particular, the homeserver's own [login
|
||||
fallback]() implementation could be excluded.
|
||||
fallback](#login-fallback) implementation could be excluded.
|
||||
|
||||
2. For added security, homeservers SHOULD guard against unsolicited
|
||||
authentication attempts by tracking pending requests. One way to do
|
||||
|
|
@ -223,14 +223,14 @@ The homeserver then proceeds as follows:
|
|||
|
||||
#### SSO during User-Interactive Authentication
|
||||
|
||||
[User-interactive authentication]() is used by client-server endpoints
|
||||
[User-interactive authentication](#user-interactive-authentication-api) is used by client-server endpoints
|
||||
which require additional confirmation of the user's identity (beyond
|
||||
holding an access token). Typically this means that the user must
|
||||
re-enter their password, but for homeservers which delegate to an SSO
|
||||
server, this means redirecting to the authentication server during
|
||||
user-interactive auth.
|
||||
|
||||
The implemementation of this is based on the [Fallback]() mechanism for
|
||||
The implemementation of this is based on the [Fallback](#fallback) mechanism for
|
||||
user-interactive auth.
|
||||
|
||||
#### Client behaviour
|
||||
|
|
@ -274,7 +274,7 @@ may require additional calls to the authentication server, and/or may
|
|||
require checking a signature on the response.
|
||||
|
||||
The homeserver then returns the [user-interactive authentication
|
||||
fallback completion]() page to the user's browser.
|
||||
fallback completion](#fallback) page to the user's browser.
|
||||
|
||||
###### Security considerations
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ messaging sessions.
|
|||
|
||||
Sticker messages are specialised image messages that are displayed
|
||||
without controls (e.g. no "download" link, or light-box view on click,
|
||||
as would be displayed for for [m.image]() events).
|
||||
as would be displayed for for [m.image](#mimage) events).
|
||||
|
||||
Sticker messages are intended to provide simple "reaction" events in the
|
||||
message timeline. The matrix client should provide some mechanism to
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ tags are defined in the `m.*` namespace:
|
|||
- `m.lowpriority`: These should be shown with lower precedence than
|
||||
others.
|
||||
- `m.server_notice`: Used to identify [Server Notice
|
||||
Rooms](#module-server-notices).
|
||||
Rooms](#server-notices).
|
||||
|
||||
{{m\_tag\_event}}
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ it should insert an `m.room.member` event into the room's graph for that
|
|||
user, with `content.membership` = `invite`, as well as a
|
||||
`content.third_party_invite` property which contains proof that the
|
||||
invitee does indeed own that third party identifier. See the
|
||||
[m.room.member](#m-room-member) schema for more information.
|
||||
[m.room.member](#mroommember) schema for more information.
|
||||
|
||||
#### Events
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ at any time - the completion is not shown in the diagram.
|
|||
H1 MUST verify the request from H3 to ensure the `signed` property is
|
||||
correct as well as the `key_validity_url` as still being valid. This is
|
||||
done by making a request to the [identity server
|
||||
/isvalid](../identity_service/%IDENTITY_RELEASE_LABEL%.html#get-matrix-identity-v2-pubkey-isvalid)
|
||||
/isvalid](/identity-service-api/#get_matrixidentityv2pubkeyisvalid)
|
||||
endpoint, using the provided URL rather than constructing a new one. The
|
||||
query string and response for the provided URL must match the Identity
|
||||
Service Specification.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 20
|
|||
This module outlines how two users in a room can set up a Voice over IP
|
||||
(VoIP) call to each other. Voice and video calls are built upon the
|
||||
WebRTC 1.0 standard. Call signalling is achieved by sending [message
|
||||
events]() to the room. In this version of the spec, only two-party
|
||||
events](#events) to the room. In this version of the spec, only two-party
|
||||
communication is supported (e.g. between two peers, or between a peer
|
||||
and a multi-point conferencing unit). This means that clients MUST only
|
||||
send call events to rooms with exactly two participants.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue