Merge pull request #1330 from matrix-org/rav/fix_dead_links

Fix broken links
pull/1338/head
Richard van der Hoff 2 years ago committed by GitHub
commit 44c7eb5b88
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -0,0 +1 @@
Fix a number of broken links in the specification.

@ -0,0 +1 @@
Fix a number of broken links in the specification.

@ -0,0 +1 @@
Fix a number of broken links in the specification.

@ -0,0 +1 @@
Fix a number of broken links in the specification.

@ -2527,7 +2527,7 @@ that profile.
| [Instant Messaging](#instant-messaging) | Required | Required | Required | Required | Optional |
| [Rich replies](#rich-replies) | Optional | Optional | Optional | Optional | Optional |
| [Direct Messaging](#direct-messaging) | Required | Required | Required | Required | Optional |
| [Mentions](#user-room-and-group-mentions) | Required | Required | Required | Optional | Optional |
| [Mentions](#user-and-room-mentions) | Required | Required | Required | Optional | Optional |
| [Presence](#presence) | Required | Required | Required | Required | Optional |
| [Push Notifications](#push-notifications) | Optional | Required | Optional | Optional | Optional |
| [Receipts](#receipts) | Required | Required | Required | Required | Optional |

@ -256,8 +256,8 @@ unable to do so. This happens in the following situations:
* The original event (and hence its replacement) are encrypted.
Client authors are reminded to take note of the requirements for [Validity of
message edit events](#validity-of-message-edit-events), and to ignore any
invalid edit events that are received.
replacement events](#validity-of-replacement-events), and to ignore any
invalid replacement events that are received.
##### Permalinks

@ -4,7 +4,7 @@
Users may wish to be informed when another user is typing in a room.
This can be achieved using typing notifications. These are ephemeral
events, so they do not form part of the
[Event Graph](index.html#event-graphs). Typing notifications are scoped
[Event Graph](/#event-graphs). Typing notifications are scoped
to a room.
#### Events

@ -31,7 +31,7 @@ not necessarily provide evidence that they have validated associations,
but claim to have done so. Establishing the trustworthiness of an
individual identity server is left as an exercise for the client.
3PID types are described in [3PID Types](/appendices#pid-types)
3PID types are described in [3PID Types](/appendices#3pid-types)
Appendix.
## API standards

@ -3,7 +3,7 @@ The types of state events that affect authorization are:
- [`m.room.create`](/client-server-api#mroomcreate)
- [`m.room.member`](/client-server-api#mroommember)
- [`m.room.join_rules`](/client-server-api#mroom)
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)
@ -32,7 +32,7 @@ The rules are as follows:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
3. If the `content` of the `m.room.create` event in the room state has the
property `m.federate` set to `false`, and the `sender` domain of the event

@ -11,7 +11,7 @@ The types of state events that affect authorization are:
- [`m.room.create`](/client-server-api#mroomcreate)
- [`m.room.member`](/client-server-api#mroommember)
- [`m.room.join_rules`](/client-server-api#mroom)
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)
@ -40,7 +40,7 @@ The complete list of rules, as of room version 3, is as follows:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
3. If the `content` of the `m.room.create` event in the room state has the
property `m.federate` set to `false`, and the `sender` domain of the event

@ -11,7 +11,7 @@ The types of state events that affect authorization are:
- [`m.room.create`](/client-server-api#mroomcreate)
- [`m.room.member`](/client-server-api#mroommember)
- [`m.room.join_rules`](/client-server-api#mroom)
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)
@ -40,7 +40,7 @@ The rules are as follows:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
3. If the `content` of the `m.room.create` event in the room state has the
property `m.federate` set to `false`, and the `sender` domain of the event

@ -86,7 +86,7 @@ The types of state events that affect authorization are:
- [`m.room.create`](/client-server-api#mroomcreate)
- [`m.room.member`](/client-server-api#mroommember)
- [`m.room.join_rules`](/client-server-api#mroom)
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)
@ -115,7 +115,7 @@ The rules are as follows:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
3. If the `content` of the `m.room.create` event in the room state has the
property `m.federate` set to `false`, and the `sender` domain of the event

@ -61,7 +61,7 @@ The types of state events that affect authorization are:
- [`m.room.create`](/client-server-api#mroomcreate)
- [`m.room.member`](/client-server-api#mroommember)
- [`m.room.join_rules`](/client-server-api#mroom)
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)

@ -47,7 +47,7 @@ The types of state events that affect authorization are:
- [`m.room.create`](/client-server-api#mroomcreate)
- [`m.room.member`](/client-server-api#mroommember)
- [`m.room.join_rules`](/client-server-api#mroom)
- [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
- [`m.room.power_levels`](/client-server-api#mroompower_levels)
- [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)

@ -51,7 +51,7 @@ paths:
description: |-
Optional (default `all`) flag to denote which thread roots are of interest to the caller.
When `all`, all thread roots found in the room are returned. When `participated`, only
thread roots for threads the user has [participated in](/client-server-api/#server-side-aggreagtion-of-mthread-relationships)
thread roots for threads the user has [participated in](/client-server-api/#server-side-aggregation-of-mthread-relationships)
will be returned.
x-example: "all"
- in: query

@ -103,7 +103,7 @@ paths:
hashed or formatted will lead to no matches.
Note that addresses are case sensitive: review the
[3PID Types](/appendices#pid-types) to verify the intended case an
[3PID Types](/appendices#3pid-types) to verify the intended case an
identifier should be prior to submission/hashing.
example: [
"4kenr7N9drpCJ4AfalmlGQVsOn3o2RHjkADUpXJWZUc",

@ -36,7 +36,7 @@ paths:
the space-room's children the requesting server could feasibly peek/join are returned. The
requesting server is responsible for filtering the results further down for the user's request.
Only [`m.space.child`](#mspacechild) state events of the room are considered. Invalid child
Only [`m.space.child`](/client-server-api/#mspacechild) state events of the room are considered. Invalid child
rooms and parent events are not covered by this endpoint.
Responses to this endpoint should be cached for a period of time.
@ -55,7 +55,7 @@ paths:
name: suggested_only
description: |-
Optional (default `false`) flag to indicate whether or not the server should only consider
suggested rooms. Suggested rooms are annotated in their [`m.space.child`](#mspacechild) event
suggested rooms. Suggested rooms are annotated in their [`m.space.child`](/client-server-api/#mspacechild) event
contents.
x-example: true
responses:

@ -4,7 +4,8 @@ allOf:
description: |-
This event type is used when sending encrypted events. It can be used either
within a room (in which case it will have all of the [Room Event fields](/client-server-api/#room-event-fields)), or
within a room (in which case it will have all of the normal properties in
[Room events](/client-server-api/#room-event-format)), or
as a [to-device](/client-server-api/#send-to-device-messaging) event.
properties:

Loading…
Cancel
Save