Merge da34a368aa into e9f0f31d27

proposals/4208-user-defined-profile-fields.md

@@ -0,0 +1,141 @@
+# 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.*
+
+## 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 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 implement appropriate content warnings and user education about the public nature
+  of profile fields.
+
+### Server Considerations
+
+- 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 SHOULD use the existing `m.profile_fields` capability to control access to the `u.*`
+  namespace. For example:
+
+  ```json
+  {
+    "m.profile_fields": {
+      "enabled": true,
+      "disallowed": ["u.*"]
+    }
+  }
+  ```
+
+### Trust & Safety Considerations
+
+The ability for users to set arbitrary freetext fields in their profiles introduces several
+significant trust and safety concerns that implementations must consider:
+
+#### Content Moderation
+
+- **Hate Speech and Harassment**: Users could use profile fields to spread hate speech or harass
+  others. Homeservers MUST implement appropriate content moderation tools.
+
+- **Impersonation**: Custom fields could be used to impersonate others or create misleading
+  profiles. Homeservers SHOULD have mechanisms to handle impersonation reports.
+
+- **Spam and Malicious Links**: Profile fields could be used to spread spam or malicious links.
+  Homeservers SHOULD implement link scanning and spam detection.
+
+#### Privacy and Data Protection
+
+- **Personal Information**: Users might inadvertently overshare personal information. Clients
+  SHOULD warn users about the public nature of profile fields.
+
+- **Data Mining**: Public profile fields could be scraped for data mining. Homeservers SHOULD
+  implement rate limiting and monitoring for bulk profile access.
+
+- **Right to be Forgotten**: Homeservers MUST ensure compliance with data protection regulations,
+  including the ability to completely remove profile data when requested.
+
+#### Implementation Requirements
+
+To address these concerns:
+
+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
+
+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
+
+3. **Rate Limiting**:
+   - Limits on frequency of profile updates
+   - Protection against automated abuse
+   - Monitoring for suspicious patterns
+
+4. **User Education**:
+   - Clear warnings about public nature of fields
+   - Guidelines for appropriate content
+   - Privacy implications documentation
+
+## 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. [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
+
+### Unstable Namespace
+
+Until this proposal is stabilised, custom fields should use an unstable prefix in their keys:
+
+- **Namespace `uk.tcpip.msc4208.u.*`**: For example, `uk.tcpip.msc4208.u.bio`.
+
+## 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.