MSC4258: Federated User Directory #4258
Conversation
MatMaul
changed the title
MatMaul
force-pushed
the
fed-user-dir
branch
3 times, most recently
from
224fe5c to
f4ee6bc
Compare
Co-authored-by: Maghen Calinghee <[email protected]> Co-authored-by: Olivier Delcroix <[email protected]> Co-authored-by: Yoan Pintas <[email protected]> Co-authored-by: Nicolas Buquet <[email protected]>
|
We are planning to implement the MSC in the coming months, however we would happily take early feedback in the meantime. |
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
|
|
||
| ## Alternatives | ||
|
|
||
| We first thought about using an account data, however it has a big caveat: remote servers can't access it, hence remote servers will not be able to honor the visibility when trying to return remote users that are already visible locally to them. |
There was a problem hiding this comment.
An alternative to this is to include the requesting user to the federated servers and let them decide whether to provide the user in the result or not?
|
|
||
| #### New profile field to control user visibility in the directory | ||
|
|
||
| We propose to add a new field in the profile (MSC4133) `m.user_directory.visibility` to give the user the ability to control their visibility in the user directory. |
There was a problem hiding this comment.
This seems like an odd piece of data to allow other users to query.
There was a problem hiding this comment.
Could this maybe go into account data instead? It only needs to be accessed by the local homeserver, right?
|
|
||
| We propose to introduce a reactive mechanism to allow the server to stream new results to the client. | ||
|
|
||
| #### POST /_matrix/client/v3/user_directory/search |
There was a problem hiding this comment.
Clients cannot control if the request is only local or not then?
| ```json | ||
| { | ||
| "limit": 10, | ||
| "search_term": "foo" |
There was a problem hiding this comment.
Is there guidance on how the search term is used? Is it the same as the current API?
| We first propose a new federation endpoint similar to the [current client API](https://spec.matrix.org/v1.12/client-server-api#post_matrixclientv3user_directorysearch). | ||
| It would be authenticated and rate limited. | ||
|
|
||
| #### `POST /_matrix/federation/v3/user_directory/search` |
There was a problem hiding this comment.
What are the valid error conditions?
There was a problem hiding this comment.
Tagging on to this, the profile federation API has a 403 to let server admins deny profile look-up. This might be good to have on the user directory API as well.
|
|
||
| All profile fields (cf [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133)) should be returned here. | ||
|
|
||
| When an user calls the client user search API, the server should send a federated user search request to all known servers. It would then receive the results and return them to the user. |
There was a problem hiding this comment.
This sounds really really expensive for the server.
There was a problem hiding this comment.
This could benefit from #4259 🙂
| - `restricted`: visible to any user sharing a room with | ||
| - `remote` (or federated or public ?): visible to users on local and remote homeservers | ||
|
|
||
| If no value is provided (or it is null), the user hasn't set a preference and the server should follow the current expected behavior (visible if sharing a room in common or in public room). |
There was a problem hiding this comment.
"visible if sharing a room in common or in public room" is actually the only the minimum requirement.
Rendered
This proposal has been thought and written by me and people listed below, all employed by the French state for the Tchap project.
@mcalinghee @odelcroi @yostyle @NicolasBuquet