This commit is contained in:
Kim Brose 2026-02-24 16:43:23 +00:00 committed by GitHub
commit 88f6e7bc89
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
14 changed files with 19 additions and 17 deletions

View file

@ -0,0 +1 @@
Fix typos, formatting, wording. Contributed by @HarHarLinks.

View file

@ -0,0 +1 @@
Fix typos, formatting, wording. Contributed by @HarHarLinks.

View file

@ -65,7 +65,7 @@ description = "Home of the Matrix specification for decentralised communication"
# Everything below this are Site Params
[params]
copyright = "The Matrix.org Foundation CIC"
copyright = "The Matrix.org Foundation C.I.C."
[params.version]
# must be one of "unstable", "current", "historical"

View file

@ -3320,7 +3320,7 @@ PUT /rooms/!roomid:domain/state/m.room.bgd.color
### Redactions
Since events are extensible it is possible for malicious users and/or
servers to add keys that are, for example offensive or illegal. Since
servers to add keys that are, for example, offensive or illegal. Since
some events cannot be simply deleted, e.g. membership events, we instead
'redact' events. This involves removing all keys from an event that are
not required by the protocol. This stripped down event is thereafter
@ -3418,7 +3418,7 @@ This specification describes the following relationship types:
* [Event replacements](#event-replacements).
* [Event annotations](#event-annotations-and-reactions).
* [Threads](#threading).
* [References](#reference-relations)
* [References](#reference-relations).
#### Aggregations of child events

View file

@ -107,7 +107,7 @@ flag to `true`.
```
{{% boxes/note %}}
Clients which are acutely aware of threads (they do not render threads, but are otherwise
Clients which are aware of threads (they do not render threads, but are otherwise
aware of the feature existing in the spec) can treat rich replies to an event with a `rel_type`
of `m.thread` as a threaded reply, for conversation continuity on the threaded client's side.

View file

@ -226,7 +226,7 @@ paths:
type: boolean
description: |-
Whether or not to include all known networks/protocols from
application services on the homeserver. Defaults to false.
application services on the homeserver. Defaults to `false`.
example: false
third_party_instance_id:
type: string
@ -277,4 +277,4 @@ components:
accessTokenQuery:
$ref: definitions/security.yaml#/accessTokenQuery
accessTokenBearer:
$ref: definitions/security.yaml#/accessTokenBearer
$ref: definitions/security.yaml#/accessTokenBearer

View file

@ -163,7 +163,7 @@ paths:
known client device, a new device will be created. The given
device ID must not be the same as a
[cross-signing](/client-server-api/#cross-signing) key ID.
The server will auto-generate a device_id
The server will auto-generate a `device_id`
if this is not specified.
initial_device_display_name:
type: string

View file

@ -57,7 +57,7 @@ paths:
type: boolean
description: |-
Whether the user's other access tokens, and their associated devices, should be
revoked if the request succeeds. Defaults to true.
revoked if the request succeeds. Defaults to `true`.
When `false`, the server can still take advantage of the [soft logout method](/client-server-api/#soft-logout)
for the user's remaining devices.

View file

@ -126,7 +126,7 @@ paths:
description: |-
ID of the client device. If this does not correspond to a
known client device, a new device will be created. The server
will auto-generate a device_id if this is not specified.
will auto-generate a `device_id` if this is not specified.
example: GHTYAJCE
initial_device_display_name:
type: string
@ -139,11 +139,11 @@ paths:
description: |-
If true, an `access_token` and `device_id` should not be
returned from this call, therefore preventing an automatic
login. Defaults to false.
login. Defaults to `false`.
example: false
refresh_token:
type: boolean
description: If true, the client supports refresh tokens.
description: If `true`, the client supports refresh tokens.
x-addedInMatrixVersion: "1.3"
required: true
responses:

View file

@ -31,7 +31,7 @@ paths:
The body of the request should be the content object of the event; the
fields in this object will vary depending on the type of event. See
[Room Events](/client-server-api/#room-events) for the m. event specification.
[Room Events](/client-server-api/#room-events) for the `m.` event specification.
Homeservers MUST allow clients to send `m.room.redaction` events with this
endpoint for all room versions. In rooms with a version older than 11 they

View file

@ -49,7 +49,7 @@ paths:
name: include_all_networks
description: |-
Whether or not to include all networks/protocols defined by application
services on the homeserver. Defaults to false.
services on the homeserver. Defaults to `false`.
example: false
schema:
type: boolean
@ -121,7 +121,7 @@ paths:
type: boolean
description: |-
Whether or not to include all known networks/protocols from
application services on the homeserver. Defaults to false.
application services on the homeserver. Defaults to `false`.
example: false
third_party_instance_id:
type: string

View file

@ -8,7 +8,7 @@ properties:
type: object
type:
description: The type of event. This SHOULD be namespaced similar to Java package
naming conventions e.g. 'com.example.subdomain.event.type'
naming conventions e.g. `com.example.subdomain.event.type`
type: string
required:
- type

View file

@ -54,7 +54,7 @@ properties:
type: boolean
description: |-
True to allow server names that are IP address literals. False to
deny. Defaults to true if missing or otherwise not a boolean.
deny. Defaults to `true` if missing or otherwise not a boolean.
This is strongly recommended to be set to `false` as servers running
with IP literal names are strongly discouraged in order to require

View file

@ -49,7 +49,7 @@
</tr>
{{ if $state_key }}
<tr>
<th>State key</th>
<th>State key:</th>
<td>{{ $state_key.description | markdownify }}</td>
</tr>
{{ end }}