Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-23 06:23:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge pull request #2 from Johennes/MSC4133

Browse source 
Add profile_fields capability and deprecations into text section
This commit is contained in:
Tom Foster 2025-08-06 18:34:01 +01:00 committed by GitHub
parent 729d50cd4a 0d89ec84e2
commit 433f0361e1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 69 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

69
content/client-server-api/_index.md
View file

@ -2491,8 +2491,66 @@ using an `unstable` version.
When this capability is not listed, clients should use `"1"` as the
default and only stable `available` room version.
### `m.profile_fields` capability
{{% added-in v="1.16" %}}
This capability defines which [profile](#profiles) fields the user is
able to change.
The capability value has a required flag, `enabled`, and two optional lists, `allowed` and
`disallowed`.
When `enabled` is `false`, all profile fields are managed by the server
and the client is not permitted to make any changes.
When `enabled` is `true`, clients are permitted to modify profile fields,
subject to the restrictions implied by the OPTIONAL lists `allowed` and
`disallowed`.
If `allowed` is present, clients can modify only the fields
listed. They SHOULD assume all other fields to be managed by
the server. In this case, `disallowed` has no meaning and should be ignored.
If `disallowed` is present (and `allowed` is not), clients SHOULD assume
that the listed fields are managed by the server. Clients may modify any
fields that are *not* listed, provided `enabled` is `true`.
If neither `allowed` nor `disallowed` is present, clients can modify all fields
without restrictions, provided `enabled` is `true`.
When this capability is not listed, clients SHOULD assume the user is able to change
profile fields without any restrictions, provided the homeserver
advertises a specification version that includes the `m.profile_fields`
capability in the [`/versions`](/client-server-api/#get_matrixclientversions)
response.
An example of the capability API's response for this capability is:
```json
{
"capabilities": {
"m.profile_fields": {
"enabled": true,
"disallowed": ["displayname"]
}
}
}
```
### `m.set_displayname` capability
{{% boxes/note %}}
{{% changed-in v="1.16" %}}
This capability is now deprecated. Clients SHOULD use the
[`m.profile_fields`](/client-server-api/#mprofile_fields-capability)
capability instead.
For backwards compatibility, servers that forbid setting the
`displayname` profile field in the `m.profile_fields` capability
MUST still present this capability with `"enabled": false`.
{{% /boxes/note %}}
This capability has a single flag, `enabled`, to denote whether the user
is able to change their own display name via profile endpoints. Cases for
disabling might include users mapped from external identity/directory
@ -2517,6 +2575,17 @@ An example of the capability API's response for this capability is:
### `m.set_avatar_url` capability
{{% boxes/note %}}
{{% changed-in v="1.16" %}}
This capability is now deprecated. Clients SHOULD use the
[`m.profile_fields`](/client-server-api/#mprofile_fields-capability)
capability instead.
For backwards compatibility, servers that forbid setting the
`avatar_url` profile field in the `m.profile_fields` capability
MUST still present this capability with `"enabled": false`.
{{% /boxes/note %}}
This capability has a single flag, `enabled`, to denote whether the user
is able to change their own avatar via profile endpoints. Cases for
disabling might include users mapped from external identity/directory