Fix broken links
A bunch of broken links I found
This commit is contained in:
parent
fd41d9d4ed
commit
6cbb88f9df
14 changed files with 21 additions and 20 deletions
|
@ -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…
Add table
Add a link
Reference in a new issue