2.0 KiB
MSC3283: Expose enable_set_displayname, enable_set_avatar_url and enable_3pid_changes in capabilities response
Some home servers like Synapse
can be configured to enable_set_displayname: false, enable_set_avatar_url: false or enable_3pid_changes: false.
To enable clients to handle that gracefully in the UI this setting should be exposed.
Proposal
The /_matrix/client/r0/capabilities endpoint should be decorated to provide more information on capabilities.
{
"capabilities": {
"m.set_displayname": { "enabled": false },
"m.set_avatar_url": { "enabled": false },
"m.3pid_changes": { "enabled": false },
"m.room_versions": {...},
}
}
As part of this MSC, a capability for each setting will be added that exposes the server setting:
m.set_displayname
Whether users are allowed to change their displayname after it has been initially set. Useful when provisioning users based on the contents of a third-party directory.
m.set_avatar_url
Whether users are allowed to change their avatar after it has been initially set. Useful when provisioning users based on the contents of a third-party directory.
m.3pid_changes
Whether users can change the 3PIDs associated with their accounts (email address and msisdn). Useful when provisioning users based on the contents of a third-party directory.
Client recommendations
When presenting profile settings, clients should use capabilities in order to display the correct UI.
Capability should always be present. Servers should always send these capabilities. If they aren't (because the server does not support a new enough spec version or for any other reason), clients should behave as if they were present and set to true.
Unstable prefix
While this MSC is not considered stable, implementations should use org.matrix.msc3283. in place of m. throughout this proposal.