MSC3973: Search users in the user directory with the Widget API #3973
Conversation
…rectory Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
turt2live
added
proposal
| specification. It should provide the same features that the | ||
| [“User Directory search” endpoint](https://spec.matrix.org/v1.6/client-server-api/#post_matrixclientv3user_directorysearch) | ||
| of the Client-Server API provides. It should further provide the same results as the invite dialog of | ||
| the hosting client (e.g. Element) so the same search terms lead to the same results in all components. |
There was a problem hiding this comment.
There are two options to solve this:
- Just return the response from the CS-API.
- Return whatever the client is doing to provide the user list in their invite dialogs (and injecting them transparently into the results list without the widget noticing).
For 2., Element does many additional things that is currently implemented in the InviteDialog. If we would want to provide the client-enhanced list instead of the raw server response, this would require refactoring in the react-sdk. But for the long term (if MSC3008 becomes a reality) it might be questionable how useful that would be. It could for example be an option to move the code to the js-sdk and expecting that future widgets will keep using that one. If the MSC is formulated openly enough, it could also leave other client authors the option to not do any additional processing here.
There was a problem hiding this comment.
I agree with the thought, that the widget api should not be unnecassarly complex to implement for other clients. I think the better solution for a better user list would be to use the js-sdk for the widget and run the user list modifications to be done inside the widget.
|
|
||
| ## Proposal | ||
|
|
||
| We will add a new interface to the widget API to search users in the user directory. We will introduce |
There was a problem hiding this comment.
I am wondering if using "we" is common in MSC's. I have not seen it before. I am not aware if there are any rules. But I think rephrasing without "we" would not hurt?
There was a problem hiding this comment.
Good point. I'm used to write ADRs for our own products which are written from our teams perspective. I will rewrite it later to better fit the MSC styling
Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
| send an error response (as required currently by the capabilities system for widgets). | ||
|
|
||
| The client SHOULD NOT modify the data of the request. The widget is responsible for producing valid | ||
| events - the client MUST pass through any errors, such as permission errors, to the widget using the |
There was a problem hiding this comment.
This looks like it was copied from MSC2762 but doesn't quite fit here. Maybe the sentence "The widget is responsible..." should be removed completely?
There was a problem hiding this comment.
This is is a copy from MSC2762 because it asks for the same behavior. MSC2762 is mainly defining the actions read_event and send_event but I would de-facto see it as a more general that kind-of defines the general behavior of the contract between the homeserver, the client, and the widget. But I'm fine with skipping it in this proposal.
|
|
||
| While this MSC is not present in the spec, clients and widgets should: | ||
|
|
||
| - Use `org.matrix.msc3973.` in place of `m.` in all new identifiers of this MSC. |
There was a problem hiding this comment.
Is this needed? Doesn't the following bullet point cover everything? (Or is this a standard sentence we include in this section?)
There was a problem hiding this comment.
Not necessarily. So far, actions in the Widget API (like read_event, send_event, ...) are not prefixed with m.*, so the second point would not apply here. The first point mainly references the new permission m.user_directory_search while the second references the action user_directory_search.
Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
Rendered
Implementations