archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Shift from API to more T&S focus

Browse Source
pull/4208/head
Tom Foster 11 months ago
parent d996f97a42
commit a22b9fce1f
1 changed files with 58 additions and 129 deletions
Show Stats Download Patch File Download Diff File

181
proposals/4208-user-defined-profile-fields.md
Unescape Escape View File

@ -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 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. must always be UTF-8 strings with content not exceeding 512 bytes.
### Client-Server API Changes ### Client Considerations
#### 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:
- **Endpoint**: `DELETE /_matrix/client/v3/profile/{userId}/{key_name}` - Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*`
- **Description**: Remove a specified `key_name` and its value from the user's profile, namespace.
if permitted by the homeserver.
#### 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}` - Clients SHOULD implement appropriate content warnings and user education about the public nature
- **Description**: Retrieve all profile fields for a user. of profile fields.
- **Response**:
```json ### Server Considerations
{
"avatar_url": "mxc://matrix.org/MyC00lAvatar",
"displayname": "Alice",
"u.bio": "I love Matrix!",
"u.location": "London"
}
```
### 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 - Homeservers MAY validate that keys in the `u.*` namespace conform to the required format and
profile fields. It is advertised on the `GET /_matrix/client/v3/capabilities` endpoint. Clients enforce size limits on values.
should check for this capability before attempting to create or modify custom fields.
- **Capability Structure**: - Homeservers SHOULD use the existing `m.profile_fields` capability to control access to the `u.*`
namespace. For example:
```json ```json
{ {
"capabilities": { "m.profile_fields": {
"m.custom_profile_fields": { "enabled": true,
"enabled": true "disallowed": ["u.*"]
}
} }
} }
``` ```
- **Behaviour**: ### Trust & Safety Considerations
- **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 The ability for users to set arbitrary freetext fields in their profiles introduces several
fields. Any attempt to do so should result in a `403 Forbidden` error. significant trust and safety concerns that implementations must consider:
- **When `enabled` is `true`**: Clients should allow users to create or update custom fields in #### Content Moderation
the `u.*` namespace, except those listed in the `disallowed` array.
### 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 - **Impersonation**: Custom fields could be used to impersonate others or create misleading
the following error codes: 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."
}
```
- **`M_TOO_LARGE`**: The value provided exceeds the maximum allowed length. #### Privacy and Data Protection
```json - **Personal Information**: Users might inadvertently overshare personal information. Clients
{ SHOULD warn users about the public nature of profile fields.
"errcode": "M_TOO_LARGE",
"error": "The value exceeds the maximum allowed length of 512 bytes."
}
```
### Client Considerations - **Data Mining**: Public profile fields could be scraped for data mining. Homeservers SHOULD
implement rate limiting and monitoring for bulk profile access.
- Clients SHOULD provide a UI for users to view and edit their own custom fields in the `u.*` - **Right to be Forgotten**: Homeservers MUST ensure compliance with data protection regulations,
namespace. including the ability to completely remove profile data when requested.
- When displaying other users' profiles, clients SHOULD retrieve and display custom fields in the #### Implementation Requirements
`u.*` namespace.
- Clients SHOULD be cautious about the amount of data displayed and provide options to limit or To address these concerns:
filter the display of custom fields.
### Server Considerations 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
- Homeservers MAY impose limits on the number of custom fields, whether for storage reasons or to 2. **Reporting Mechanisms**:
ensure the total profile size remains under 64KiB as defined in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). - 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 validate that keys in the `u.*` namespace conform to the required format and 3. **Rate Limiting**:
enforce size limits on values. - 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 ## Potential Issues

Write Preview
Loading…
Cancel
Save