From 334882fb2f7799ec55650c79780f4a4867b87148 Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Wed, 2 Oct 2024 17:00:05 +0100 Subject: [PATCH 1/4] Adding User-Defined Custom Fields to User Global Profiles --- proposals/4208-user-defined-profile-fields.md | 194 ++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100644 proposals/4208-user-defined-profile-fields.md diff --git a/proposals/4208-user-defined-profile-fields.md b/proposals/4208-user-defined-profile-fields.md new file mode 100644 index 000000000..7369e38d6 --- /dev/null +++ b/proposals/4208-user-defined-profile-fields.md @@ -0,0 +1,194 @@ +# MSC4208: Adding User-Defined Custom Fields to User Global Profiles #4208 + +*This proposal depends on [MSC4133: Extending User Profile API](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). It introduces user-defined custom fields in the `u.*` namespace for user profiles.* + +## Proposal + +This proposal aims to enable users to add arbitrary custom key:value pairs to their global user profiles within the Matrix ecosystem. By leveraging the extended profile API introduced in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), users can enrich their profiles with additional public information such as preferred languages, organisational roles, or other relevant details. + +### Key/Namespace Requirements + +As per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), the profile API is extended to allow additional fields beyond `avatar_url` and `displayname`. This MSC defines the use of the `u.*` namespace for user-defined custom fields. + +- **Namespace `u.*`**: Reserved for user-defined custom fields. The portion of the key name after the `u.` defines the display name of this field (e.g., `u.bio`). The values in this namespace must always be UTF-8 strings with content not exceeding 512 bytes. + +### Client-Server API Changes + +#### Setting a Custom Profile Field + +To set or update a custom profile field, clients can use the `PUT` endpoint defined in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133): + +- **Endpoint**: `PUT /_matrix/client/v3/profile/{userId}/{key_name}` +- **Description**: Set or update the value of a specified `key_name` in the user's profile, if permitted by the homeserver. +- **Request Body**: + +```json +{ + "key_name": "new_value" +} +``` + +*Example*: Setting the custom field `u.bio` for user `@alice:matrix.org`: + +```http +PUT /_matrix/client/v3/profile/@alice:matrix.org/u.bio +``` + +With body: + +```json +{ + "u.bio": "I love Matrix!" +} +``` + +#### Retrieving Custom Profile Fields + +To retrieve custom fields from a user's profile, clients use the `GET` endpoint: + +- **Endpoint**: `GET /_matrix/client/v3/profile/{userId}/{key_name}` +- **Description**: Retrieve the value of a specified `key_name` from a user's profile. +- **Response**: + +```json +{ + "key_name": "field_value" +} +``` + +*Example*: Retrieving the custom field `u.bio` for user `@alice:matrix.org`: + +```http +GET /_matrix/client/v3/profile/@alice:matrix.org/u.bio +``` + +Response: + +```json +{ + "u.bio": "I love Matrix!" +} +``` + +#### Deleting a Custom Profile Field + +To delete a custom profile field: + +- **Endpoint**: `DELETE /_matrix/client/v3/profile/{userId}/{key_name}` +- **Description**: Remove a specified `key_name` and its value from the user's profile, if permitted by the homeserver. + +#### Retrieving All Profile Fields + +Clients can retrieve all profile fields for a user, including custom fields: + +- **Endpoint**: `GET /_matrix/client/v3/profile/{userId}` +- **Description**: Retrieve all profile fields for a user. +- **Response**: + +```json +{ + "avatar_url": "mxc://matrix.org/MyC00lAvatar", + "displayname": "Alice", + "u.bio": "I love Matrix!", + "u.location": "London" +} +``` + +### Capabilities + +A new capability `m.custom_profile_fields` is introduced to control the ability to set custom profile fields. It is advertised on the `GET /_matrix/client/v3/capabilities` endpoint. Clients should check for this capability before attempting to create or modify custom fields. + +- **Capability Structure**: + +```json +{ + "capabilities": { + "m.custom_profile_fields": { + "enabled": true, + "allowed": ["u.*"], + "disallowed": [] + } + } +} +``` + +- **Behaviour**: + - **When capability is missing**: Clients should assume that custom profile fields are not supported and refrain from providing options to set them. + - **When `enabled` is `false`**: Clients should not allow users to create or update custom fields. Any attempt to do so should result in a `403 Forbidden` error. + - **When `enabled` is `true`**: Clients should allow users to create or update custom fields in the `u.*` namespace, except those listed in the `disallowed` array. + +### Error Handling + +Consistent error codes and messages ensure clear communication of issues. Homeservers should use the following error codes: + +- **`M_KEY_NOT_ALLOWED`**: The specified key is not allowed to be set. + +```json +{ + "errcode": "M_KEY_NOT_ALLOWED", + "error": "The profile key 'u.bio' is not allowed to be set." +} +``` + +- **`M_TOO_LARGE`**: The value provided exceeds the maximum allowed length. + +```json +{ + "errcode": "M_TOO_LARGE", + "error": "The value exceeds the maximum allowed length of 512 bytes." +} +``` + +### Client Considerations + +- Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*` namespace. +- When displaying other users' profiles, clients SHOULD retrieve and display custom fields in the `u.*` namespace. +- Clients SHOULD be cautious about the amount of data displayed and provide options to limit or filter the display of custom fields. + +### Server Considerations + +- Homeservers MAY impose limits on the size and number of custom fields. +- Homeservers SHOULD validate that keys in the `u.*` namespace conform to the required format and enforce size limits on values. +- Homeservers MAY restrict certain keys or values based on server policies. + +## Potential Issues + +- **Privacy Concerns**: Users need to be aware that custom profile fields are public and visible to anyone who can access their profile. +- **Abuse Potential**: As with any user-generated content, there is potential for misuse. Servers and clients need to be prepared to handle offensive or inappropriate content. +- **Interoperability**: Until widespread adoption occurs, not all clients may support displaying custom fields, leading to inconsistent user experiences. + +## Security Considerations + +- **Content Moderation**: Homeservers SHOULD provide mechanisms to report and handle abusive content in custom profile fields. +- **Data Protection**: Homeservers MUST ensure compliance with data protection regulations, especially regarding user consent and data retention. + +## Unstable Prefixes + +### Unstable Namespace + +Until this proposal is stabilised, custom fields should use an unstable prefix in their keys: + +- **Namespace `uk.tcpip.msc0000.u.*`**: For example, `uk.tcpip.msc0000.u.bio`. + +### Unstable Capability + +The capability should be advertised with an unstable prefix: + +```json +{ + "capabilities": { + "uk.tcpip.msc0000.custom_profile_fields": { + "enabled": true, + "allowed": ["uk.tcpip.msc0000.u.*"] + } + } +} +``` + +## Dependencies + +This proposal depends on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), which introduces the extended profile API to allow additional fields in user profiles. + +## Conclusion + +By introducing user-defined custom fields in the `u.*` namespace, this proposal allows users to enrich their profiles with additional information, enhancing interactions within the Matrix ecosystem while maintaining simplicity and compatibility with existing infrastructure. From d996f97a42d66532855d2808847d02d7b517de56 Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Wed, 2 Oct 2024 17:34:57 +0100 Subject: [PATCH 2/4] Tidy content, update MSC references --- proposals/4208-user-defined-profile-fields.md | 103 ++++++++++++------ 1 file changed, 68 insertions(+), 35 deletions(-) diff --git a/proposals/4208-user-defined-profile-fields.md b/proposals/4208-user-defined-profile-fields.md index 7369e38d6..e24481e65 100644 --- a/proposals/4208-user-defined-profile-fields.md +++ b/proposals/4208-user-defined-profile-fields.md @@ -1,30 +1,41 @@ -# MSC4208: Adding User-Defined Custom Fields to User Global Profiles #4208 +# MSC4208: Adding User-Defined Custom Fields to User Global Profiles -*This proposal depends on [MSC4133: Extending User Profile API](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). It introduces user-defined custom fields in the `u.*` namespace for user profiles.* +*This proposal depends on [MSC4133: Extending User Profile API](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). +It introduces user-defined custom fields in the `u.*` namespace for user profiles.* ## Proposal -This proposal aims to enable users to add arbitrary custom key:value pairs to their global user profiles within the Matrix ecosystem. By leveraging the extended profile API introduced in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), users can enrich their profiles with additional public information such as preferred languages, organisational roles, or other relevant details. +This proposal aims to enable users to add arbitrary custom key:value pairs to their global user +profiles within the Matrix ecosystem. By leveraging the extended profile API introduced in +[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), users can enrich their +profiles with additional public information such as preferred languages, organisational roles, or +other relevant details. ### Key/Namespace Requirements -As per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), the profile API is extended to allow additional fields beyond `avatar_url` and `displayname`. This MSC defines the use of the `u.*` namespace for user-defined custom fields. +As per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), the profile API is +extended to allow additional fields beyond `avatar_url` and `displayname`. This MSC defines the use +of the `u.*` namespace for user-defined custom fields: -- **Namespace `u.*`**: Reserved for user-defined custom fields. The portion of the key name after the `u.` defines the display name of this field (e.g., `u.bio`). The values in this namespace must always be UTF-8 strings with content not exceeding 512 bytes. +- **Namespace `u.*`**: Reserved for user-defined custom fields. The portion of the key name after + the `u.` defines the display name of this field (e.g., `u.bio`). The values in this namespace + must always be UTF-8 strings with content not exceeding 512 bytes. ### Client-Server API Changes #### Setting a Custom Profile Field -To set or update a custom profile field, clients can use the `PUT` endpoint defined in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133): +To set or update a custom profile field, clients can use the `PUT` endpoint defined in +[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133): - **Endpoint**: `PUT /_matrix/client/v3/profile/{userId}/{key_name}` -- **Description**: Set or update the value of a specified `key_name` in the user's profile, if permitted by the homeserver. +- **Description**: Set or update the value of a specified `key_name` in the user's profile, + if permitted by the homeserver. - **Request Body**: ```json { - "key_name": "new_value" + "u.key_name": "new_value" } ``` @@ -75,7 +86,8 @@ Response: To delete a custom profile field: - **Endpoint**: `DELETE /_matrix/client/v3/profile/{userId}/{key_name}` -- **Description**: Remove a specified `key_name` and its value from the user's profile, if permitted by the homeserver. +- **Description**: Remove a specified `key_name` and its value from the user's profile, + if permitted by the homeserver. #### Retrieving All Profile Fields @@ -96,7 +108,9 @@ Clients can retrieve all profile fields for a user, including custom fields: ### Capabilities -A new capability `m.custom_profile_fields` is introduced to control the ability to set custom profile fields. It is advertised on the `GET /_matrix/client/v3/capabilities` endpoint. Clients should check for this capability before attempting to create or modify custom fields. +A new capability `m.custom_profile_fields` is introduced to control the ability to set custom +profile fields. It is advertised on the `GET /_matrix/client/v3/capabilities` endpoint. Clients +should check for this capability before attempting to create or modify custom fields. - **Capability Structure**: @@ -104,22 +118,26 @@ A new capability `m.custom_profile_fields` is introduced to control the ability { "capabilities": { "m.custom_profile_fields": { - "enabled": true, - "allowed": ["u.*"], - "disallowed": [] + "enabled": true } } } ``` - **Behaviour**: - - **When capability is missing**: Clients should assume that custom profile fields are not supported and refrain from providing options to set them. - - **When `enabled` is `false`**: Clients should not allow users to create or update custom fields. Any attempt to do so should result in a `403 Forbidden` error. - - **When `enabled` is `true`**: Clients should allow users to create or update custom fields in the `u.*` namespace, except those listed in the `disallowed` array. + - **When capability is missing**: Clients should assume that custom profile fields are not + supported and refrain from providing options to set them. + + - **When `enabled` is `false`**: Clients should not allow users to create or update custom + fields. Any attempt to do so should result in a `403 Forbidden` error. + + - **When `enabled` is `true`**: Clients should allow users to create or update custom fields in + the `u.*` namespace, except those listed in the `disallowed` array. ### Error Handling -Consistent error codes and messages ensure clear communication of issues. Homeservers should use the following error codes: +Consistent error codes and messages ensure clear communication of issues. Homeservers should use +the following error codes: - **`M_KEY_NOT_ALLOWED`**: The specified key is not allowed to be set. @@ -141,26 +159,44 @@ Consistent error codes and messages ensure clear communication of issues. Homese ### Client Considerations -- Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*` namespace. -- When displaying other users' profiles, clients SHOULD retrieve and display custom fields in the `u.*` namespace. -- Clients SHOULD be cautious about the amount of data displayed and provide options to limit or filter the display of custom fields. +- Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*` + namespace. + +- When displaying other users' profiles, clients SHOULD retrieve and display custom fields in the + `u.*` namespace. + +- Clients SHOULD be cautious about the amount of data displayed and provide options to limit or + filter the display of custom fields. ### Server Considerations -- Homeservers MAY impose limits on the size and number of custom fields. -- Homeservers SHOULD validate that keys in the `u.*` namespace conform to the required format and enforce size limits on values. +- Homeservers MAY impose limits on the number of custom fields, whether for storage reasons or to + ensure the total profile size remains under 64KiB as defined in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). + +- Homeservers MAY validate that keys in the `u.*` namespace conform to the required format and + enforce size limits on values. + - Homeservers MAY restrict certain keys or values based on server policies. ## Potential Issues -- **Privacy Concerns**: Users need to be aware that custom profile fields are public and visible to anyone who can access their profile. -- **Abuse Potential**: As with any user-generated content, there is potential for misuse. Servers and clients need to be prepared to handle offensive or inappropriate content. -- **Interoperability**: Until widespread adoption occurs, not all clients may support displaying custom fields, leading to inconsistent user experiences. +- **Privacy Concerns**: Users need to be aware that custom profile fields are public and visible to + anyone who can access their profile. + +- **Abuse Potential**: As with any user-generated content, there is potential for misuse. Servers + and clients need to be prepared to handle offensive or inappropriate content. + +- **Interoperability**: Until widespread adoption occurs, not all clients may support displaying + custom fields, leading to inconsistent user experiences. ## Security Considerations -- **Content Moderation**: Homeservers SHOULD provide mechanisms to report and handle abusive content in custom profile fields. -- **Data Protection**: Homeservers MUST ensure compliance with data protection regulations, especially regarding user consent and data retention. +- **Content Moderation**: Homeservers SHOULD provide mechanisms to report and handle abusive + content in custom profile fields. [MSC4202](https://github.com/matrix-org/matrix-spec-proposals/pull/4202) + provides an example of one such mechanism. + +- **Data Protection**: Homeservers SHOULD ensure compliance with data protection regulations, + especially regarding user consent and data retention. ## Unstable Prefixes @@ -168,7 +204,7 @@ Consistent error codes and messages ensure clear communication of issues. Homese Until this proposal is stabilised, custom fields should use an unstable prefix in their keys: -- **Namespace `uk.tcpip.msc0000.u.*`**: For example, `uk.tcpip.msc0000.u.bio`. +- **Namespace `uk.tcpip.msc4208.u.*`**: For example, `uk.tcpip.msc4208.u.bio`. ### Unstable Capability @@ -177,9 +213,9 @@ The capability should be advertised with an unstable prefix: ```json { "capabilities": { - "uk.tcpip.msc0000.custom_profile_fields": { + "uk.tcpip.msc4208.custom_profile_fields": { "enabled": true, - "allowed": ["uk.tcpip.msc0000.u.*"] + "allowed": ["uk.tcpip.msc4208.u.*"] } } } @@ -187,8 +223,5 @@ The capability should be advertised with an unstable prefix: ## Dependencies -This proposal depends on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), which introduces the extended profile API to allow additional fields in user profiles. - -## Conclusion - -By introducing user-defined custom fields in the `u.*` namespace, this proposal allows users to enrich their profiles with additional information, enhancing interactions within the Matrix ecosystem while maintaining simplicity and compatibility with existing infrastructure. +This proposal depends on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), +which introduces the extended profile API to allow additional fields in user profiles. From a22b9fce1f8b2e42834ad4349fcb24af528ded8e Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Thu, 23 Jan 2025 20:43:55 +0000 Subject: [PATCH 3/4] Shift from API to more T&S focus --- proposals/4208-user-defined-profile-fields.md | 187 ++++++------------ 1 file changed, 58 insertions(+), 129 deletions(-) diff --git a/proposals/4208-user-defined-profile-fields.md b/proposals/4208-user-defined-profile-fields.md index e24481e65..97240239d 100644 --- a/proposals/4208-user-defined-profile-fields.md +++ b/proposals/4208-user-defined-profile-fields.md @@ -21,162 +21,91 @@ of the `u.*` namespace for user-defined custom fields: the `u.` defines the display name of this field (e.g., `u.bio`). The values in this namespace must always be UTF-8 strings with content not exceeding 512 bytes. -### Client-Server API Changes - -#### Setting a Custom Profile Field - -To set or update a custom profile field, clients can use the `PUT` endpoint defined in -[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133): - -- **Endpoint**: `PUT /_matrix/client/v3/profile/{userId}/{key_name}` -- **Description**: Set or update the value of a specified `key_name` in the user's profile, - if permitted by the homeserver. -- **Request Body**: - -```json -{ - "u.key_name": "new_value" -} -``` - -*Example*: Setting the custom field `u.bio` for user `@alice:matrix.org`: - -```http -PUT /_matrix/client/v3/profile/@alice:matrix.org/u.bio -``` - -With body: - -```json -{ - "u.bio": "I love Matrix!" -} -``` - -#### Retrieving Custom Profile Fields - -To retrieve custom fields from a user's profile, clients use the `GET` endpoint: - -- **Endpoint**: `GET /_matrix/client/v3/profile/{userId}/{key_name}` -- **Description**: Retrieve the value of a specified `key_name` from a user's profile. -- **Response**: - -```json -{ - "key_name": "field_value" -} -``` - -*Example*: Retrieving the custom field `u.bio` for user `@alice:matrix.org`: - -```http -GET /_matrix/client/v3/profile/@alice:matrix.org/u.bio -``` - -Response: - -```json -{ - "u.bio": "I love Matrix!" -} -``` - -#### Deleting a Custom Profile Field - -To delete a custom profile field: +### Client Considerations -- **Endpoint**: `DELETE /_matrix/client/v3/profile/{userId}/{key_name}` -- **Description**: Remove a specified `key_name` and its value from the user's profile, - if permitted by the homeserver. +- Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*` + namespace. -#### Retrieving All Profile Fields +- When displaying other users' profiles, clients SHOULD retrieve and display custom fields in the + `u.*` namespace. -Clients can retrieve all profile fields for a user, including custom fields: +- Clients SHOULD be cautious about the amount of data displayed and provide options to limit or + filter the display of custom fields. -- **Endpoint**: `GET /_matrix/client/v3/profile/{userId}` -- **Description**: Retrieve all profile fields for a user. -- **Response**: +- Clients SHOULD implement appropriate content warnings and user education about the public nature + of profile fields. -```json -{ - "avatar_url": "mxc://matrix.org/MyC00lAvatar", - "displayname": "Alice", - "u.bio": "I love Matrix!", - "u.location": "London" -} -``` +### Server Considerations -### Capabilities +- Homeservers MAY impose limits on the number of custom fields, whether for storage reasons or to + ensure the total profile size remains under 64KiB as defined in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). -A new capability `m.custom_profile_fields` is introduced to control the ability to set custom -profile fields. It is advertised on the `GET /_matrix/client/v3/capabilities` endpoint. Clients -should check for this capability before attempting to create or modify custom fields. +- Homeservers MAY validate that keys in the `u.*` namespace conform to the required format and + enforce size limits on values. -- **Capability Structure**: +- Homeservers SHOULD use the existing `m.profile_fields` capability to control access to the `u.*` + namespace. For example: -```json -{ - "capabilities": { - "m.custom_profile_fields": { - "enabled": true + ```json + { + "m.profile_fields": { + "enabled": true, + "disallowed": ["u.*"] } } -} -``` + ``` -- **Behaviour**: - - **When capability is missing**: Clients should assume that custom profile fields are not - supported and refrain from providing options to set them. +### Trust & Safety Considerations - - **When `enabled` is `false`**: Clients should not allow users to create or update custom - fields. Any attempt to do so should result in a `403 Forbidden` error. +The ability for users to set arbitrary freetext fields in their profiles introduces several +significant trust and safety concerns that implementations must consider: - - **When `enabled` is `true`**: Clients should allow users to create or update custom fields in - the `u.*` namespace, except those listed in the `disallowed` array. +#### Content Moderation -### Error Handling +- **Hate Speech and Harassment**: Users could use profile fields to spread hate speech or harass + others. Homeservers MUST implement appropriate content moderation tools. -Consistent error codes and messages ensure clear communication of issues. Homeservers should use -the following error codes: +- **Impersonation**: Custom fields could be used to impersonate others or create misleading + profiles. Homeservers SHOULD have mechanisms to handle impersonation reports. -- **`M_KEY_NOT_ALLOWED`**: The specified key is not allowed to be set. +- **Spam and Malicious Links**: Profile fields could be used to spread spam or malicious links. + Homeservers SHOULD implement link scanning and spam detection. -```json -{ - "errcode": "M_KEY_NOT_ALLOWED", - "error": "The profile key 'u.bio' is not allowed to be set." -} -``` +#### Privacy and Data Protection -- **`M_TOO_LARGE`**: The value provided exceeds the maximum allowed length. +- **Personal Information**: Users might inadvertently overshare personal information. Clients + SHOULD warn users about the public nature of profile fields. -```json -{ - "errcode": "M_TOO_LARGE", - "error": "The value exceeds the maximum allowed length of 512 bytes." -} -``` +- **Data Mining**: Public profile fields could be scraped for data mining. Homeservers SHOULD + implement rate limiting and monitoring for bulk profile access. -### Client Considerations +- **Right to be Forgotten**: Homeservers MUST ensure compliance with data protection regulations, + including the ability to completely remove profile data when requested. -- Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*` - namespace. +#### Implementation Requirements -- When displaying other users' profiles, clients SHOULD retrieve and display custom fields in the - `u.*` namespace. +To address these concerns: -- Clients SHOULD be cautious about the amount of data displayed and provide options to limit or - filter the display of custom fields. +1. **Content Filtering**: + - Homeservers MUST implement content filtering capabilities for custom fields + - Support for blocking specific patterns or content types + - Ability to quickly respond to emerging abuse patterns -### Server Considerations +2. **Reporting Mechanisms**: + - Integration with [MSC4202](https://github.com/matrix-org/matrix-spec-proposals/pull/4202) + or similar reporting systems + - Clear processes for handling abuse reports + - Tools for moderators to review and action reported content -- Homeservers MAY impose limits on the number of custom fields, whether for storage reasons or to - ensure the total profile size remains under 64KiB as defined in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). - -- Homeservers MAY validate that keys in the `u.*` namespace conform to the required format and - enforce size limits on values. +3. **Rate Limiting**: + - Limits on frequency of profile updates + - Protection against automated abuse + - Monitoring for suspicious patterns -- Homeservers MAY restrict certain keys or values based on server policies. +4. **User Education**: + - Clear warnings about public nature of fields + - Guidelines for appropriate content + - Privacy implications documentation ## Potential Issues From da34a368aab4f99efc04563d7e015fa34114a96b Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Thu, 23 Jan 2025 20:53:01 +0000 Subject: [PATCH 4/4] Remove redundant unstable capability --- proposals/4208-user-defined-profile-fields.md | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/proposals/4208-user-defined-profile-fields.md b/proposals/4208-user-defined-profile-fields.md index 97240239d..2e554992a 100644 --- a/proposals/4208-user-defined-profile-fields.md +++ b/proposals/4208-user-defined-profile-fields.md @@ -135,21 +135,6 @@ Until this proposal is stabilised, custom fields should use an unstable prefix i - **Namespace `uk.tcpip.msc4208.u.*`**: For example, `uk.tcpip.msc4208.u.bio`. -### Unstable Capability - -The capability should be advertised with an unstable prefix: - -```json -{ - "capabilities": { - "uk.tcpip.msc4208.custom_profile_fields": { - "enabled": true, - "allowed": ["uk.tcpip.msc4208.u.*"] - } - } -} -``` - ## Dependencies This proposal depends on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133),