MSC4339: Allow the user directory to return full profiles #4339
Conversation
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
- Client making use of the data?
| Because this changes the response format of the endpoint, the new endpoint should use `v4`. The full | ||
| endpoint would be `POST /_matrix/client/v4/user_directory/search`. |
There was a problem hiding this comment.
Not really related to this, but was considering given to whether the given profile fields should be used to control which fields are searched?
There was a problem hiding this comment.
The spec says:
The search is performed case-insensitively on user IDs and display names preferably using a collation determined based upon the Accept-Language header provided in the request, if present.
I wonder if we should just relax this to "the server searches relevant profile fields" and leaves those fields up to the implementation rather than be overly specific? I'd rather not extend the spec to specifying specific fields to search, but I think the server should be allowed to search any field it wishes
There was a problem hiding this comment.
I think that makes sense, but... not sure it would fit all use-cases. I'm OK with it being out of scope, but might require another API rev in the future.
| fields returned this can be carefully managed. | ||
|
|
||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Could you reasonably shoehorn other profile fields into the existing User object (thereby not breaking the response format)? The user_id field could cause clashes but it seems fairly unlikely that somebody would have a user_id field in their profile?
There was a problem hiding this comment.
I'm a bit skeptical that someone hasn't tried it. But even if, I feel like you might one day put non-profile fields in the response anyway like "mutual_rooms", or some other non-profile criteria ("is_bot"?)
I feel for extensibility purposes it's good to get a clean slate.
But the point is valid, this would be a breaking change. I think that's why it's probably good to have a version bump for this endpoint. If a client tries to use a v3 endpoint then servers just need to do a little wrapper code to return a reduced profile set.
Rendered