b07fe504ed
This is actually doing two things:
* creating `{fragments,modules}/index.md` turns the fragments and modules into
page resources, rather than pages in their own right. We have to update the
shortcodes to match.
* adding `headless: true` means that we don't render the pages.
The net effect is that we don't render pages like
https://spec.matrix.org/v1.4/rooms/fragments/v1-auth-rules/ and
https://spec.matrix.org/v1.4/client-server-api/modules/account_data/.
31 lines
1.1 KiB
Markdown
31 lines
1.1 KiB
Markdown
|
|
### Client Config
|
|
|
|
Clients can store custom config data for their account on their
|
|
homeserver. This account data will be synced between different devices
|
|
and can persist across installations on a particular device. Users may
|
|
only view the account data for their own account.
|
|
|
|
The account data may be either global or scoped to a particular room.
|
|
There is no inheritance mechanism here: a given `type` of data missing
|
|
from a room's account data does not fall back to the global account
|
|
data with the same `type`.
|
|
|
|
#### Events
|
|
|
|
The client receives the account data as events in the `account_data`
|
|
sections of a [`/sync`](#get_matrixclientv3sync) response.
|
|
|
|
These events can also be received in a `/events` response or in the
|
|
`account_data` section of a room in a `/sync` response. `m.tag` events appearing in
|
|
`/events` will have a `room_id` with the room the tags are for.
|
|
|
|
#### Client Behaviour
|
|
|
|
{{% http-api spec="client-server" api="account-data" %}}
|
|
|
|
#### Server Behaviour
|
|
|
|
Servers MUST reject clients from setting account data for event types
|
|
that the server manages. Currently, this only includes
|
|
[m.fully\_read](#mfully_read).
|