Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-16 08:24:09 +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 When this capability is not listed, clients should use `"1"` as the
default and only stable `available` room version. 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 ### `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 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 is able to change their own display name via profile endpoints. Cases for
disabling might include users mapped from external identity/directory 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 ### `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 This capability has a single flag, `enabled`, to denote whether the user
is able to change their own avatar via profile endpoints. Cases for is able to change their own avatar via profile endpoints. Cases for
disabling might include users mapped from external identity/directory disabling might include users mapped from external identity/directory