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

MSC4208: Adding User-Defined Custom Fields to User Global Profiles

This proposal depends on MSC4133: Extending User Profile API. 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, 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, 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.

• 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:

  {
    "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 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 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, which introduces the extended profile API to allow additional fields in user profiles.