MSC4133: Update profile endpoints to support extended fields #2071
Conversation
|
Could you link to matrix-org/matrix-spec-proposals#4133 in the body for easy referencing? |
…pability deprecation
|
I think that this also needs at least a small sentence in the "Events on Change of Profile Information" section that other fields are not propagated through |
| @@ -0,0 +1 @@ | |||
| Feature: Update profile endpoints to become generic to support [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) extended fields. Extended profile fields are now supported via the new `m.profile_fields` capability, which deprecates the previous `m.set_avatar_url` and `m.set_displayname` capabilities. Stabilised keys are explicitly enumerated, and custom keys must conform to the Common Namespaced Identifier Grammar. | |||
There was a problem hiding this comment.
I can see this has gone through a bit of iteration, so apologies for the back-and-forth, but honestly this feels rather wordy for a changelog entry. Take a look at the examples in https://spec.matrix.org/v1.14/changelog/v1.14/ (and previous versions): there are very few that run to more than a single sentence; if people want more details about what's actually changing they can easily click through to the PR; and the body of the spec contains "Changed in v1.14" notes.
I think a good trick here would be to have two separate changelog entries; so here, we want something like:
| Feature: Update profile endpoints to become generic to support [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) extended fields. Extended profile fields are now supported via the new `m.profile_fields` capability, which deprecates the previous `m.set_avatar_url` and `m.set_displayname` capabilities. Stabilised keys are explicitly enumerated, and custom keys must conform to the Common Namespaced Identifier Grammar. | |
| Update user profile endpoints to handle custom fields, and add a new `m.profile_fields` capability,as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). |
... and then in changelogs/client_server/newsfragments/2071.deprecation, we want:
Deprecate `m.set_avatar_url` and `m.set_displayname` capabilities, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133).There was a problem hiding this comment.
we could do with corresponding updates to the text sections that describe the capabilites: https://pr2071--matrix-spec-previews.netlify.app/client-server-api/#mset_displayname-capability, https://pr2071--matrix-spec-previews.netlify.app/client-server-api/#mset_avatar_url-capability
| description: Capability to indicate if the user can change their display name. | ||
| description: | | ||
| **Deprecated:** Capability to indicate if the user can change their display name. | ||
| Please refer to `m.profile_fields` for extended profile management. |
There was a problem hiding this comment.
| Please refer to `m.profile_fields` for extended profile management. | |
| Refer to `m.profile_fields` for extended profile management. |
| description: Capability to indicate if the user can change their avatar. | ||
| description: | | ||
| **Deprecated:** Capability to indicate if the user can change their avatar. | ||
| Please refer to `m.profile_fields` for extended profile management. |
There was a problem hiding this comment.
| Please refer to `m.profile_fields` for extended profile management. | |
| Refer to `m.profile_fields` for extended profile management. |
| description: List of allowed additional custom profile field keys. A `*` can be used as a | ||
| wildcard to match any sequence of characters. This list takes precedence over the |
There was a problem hiding this comment.
A
*can be used as a wildcard to match any sequence of characters.
Wait, where did this come from? This wasn't in the MSC, was it? Wildcarding opens up a whole new set of questions that I don't think we want to deal with.
| parameters: | ||
| - in: path | ||
| name: userId | ||
| description: The user whose display name to get. | ||
| description: The user whose profile field to get. |
There was a problem hiding this comment.
| description: The user whose profile field to get. | |
| description: The user whose profile field should be returned. |
| and `displayname` (unless set to `null`, as they can only be strings) | ||
| plus any custom profile fields. | ||
|
|
||
| **Note**: The complete profile must be under 64 KiB. |
There was a problem hiding this comment.
Again, I don't think this is the place to mention this.
| security: | ||
| - accessTokenQuery: [] | ||
| - accessTokenBearer: [] | ||
| parameters: | ||
| - in: path | ||
| name: userId | ||
| description: The user whose avatar URL to set. | ||
| description: The user whose profile field to delete. |
There was a problem hiding this comment.
| description: The user whose profile field to delete. | |
| description: The user whose profile field should be deleted. |
| name: userId | ||
| description: The user whose avatar URL to get. | ||
| name: keyName | ||
| description: The profile field key name to delete. It must be either |
There was a problem hiding this comment.
| description: The profile field key name to delete. It must be either | |
| description: The key name of the profile field to delete. It must be either |
| schema: | ||
| type: string | ||
| pattern: '^(avatar_url|displayname|[a-z][a-z0-9_]*(\.[a-z][a-z0-9_]*)+)$' | ||
| responses: |
There was a problem hiding this comment.
mea culpa, but we don't appear to have discussed as part of the MSC process what should happen if we attempt to delete a profile field which doesn't exist (should it return a 404 or a 200?)
It looks like the sample implementation returns a 200? I think it would be a good idea to spec that while we're here
Signed-off-by: Tom Foster tom@tcpip.uk
Pull Request Checklist
Preview: https://pr2071--matrix-spec-previews.netlify.app