-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3973: Search users in the user directory with the Widget API #3973
base: main
Are you sure you want to change the base?
Changes from all commits
4d12d9f
2f1ea0a
b56dcb7
83f6728
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
# MSC3973: Search users in the user directory with the Widget API | ||
|
||
[MSC2762](https://github.com/matrix-org/matrix-spec-proposals/pull/2762) specifies a Widget API that | ||
is able to receive events from and write events to the room that is loaded in the client. This includes | ||
the support to invite users into a room by creating membership events. However, in order for this to | ||
work properly, the widgets needs to be able to discover users from the user directory of the server. | ||
That allows them to show the user a custom UI which might be useful in different applications such | ||
as a meeting planner. | ||
|
||
This proposal aims to bring the functionality of searching in the user directory into the widget | ||
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. | ||
|
||
## Proposal | ||
|
||
The widget API is extended with a new interface to search users in the user directory. The user must | ||
manually approve the following capability before the action can be used: | ||
|
||
- `m.user_directory_search`: Let the widget access the user directory. | ||
|
||
To trigger the action, widgets will use a new `fromWidget` request with the action | ||
`user_directory_search` which takes the following shape: | ||
|
||
```json | ||
{ | ||
"api": "fromWidget", | ||
"widgetId": "20200827_WidgetExample", | ||
"requestid": "generated-id-1234", | ||
"action": "user_directory_search", | ||
"data": { | ||
"search_term": "foo", | ||
"limit": 10 | ||
} | ||
} | ||
``` | ||
|
||
Under `data`, all keys are a mirrored representation of the original `/_matrix/client/v3/user_directory/search` | ||
API. The `limit` field is optional and defaults to whatever the homeserver implementation uses. | ||
|
||
If the widget did not get approved for the capability required to send the event, the client MUST | ||
send an error response (as required currently by the capabilities system for widgets). | ||
|
||
The client SHOULD NOT modify the data of the request. | ||
|
||
If the event is successfully sent by the client, the client sends the following response: | ||
|
||
```json | ||
{ | ||
"api": "fromWidget", | ||
"widgetId": "20200827_WidgetExample", | ||
"requestid": "generated-id-1234", | ||
"action": "user_directory_search", | ||
"data": { | ||
"search_term": "foo", | ||
"limit": 10 | ||
}, | ||
"response": { | ||
"limited": false, | ||
"results": [ | ||
{ | ||
"avatar_url": "mxc://bar.com/foo", | ||
"display_name": "Foo", | ||
"user_id": "@foo:bar.com" | ||
} | ||
] | ||
} | ||
} | ||
``` | ||
|
||
The `limited` and `results` fields of the `response` are required and are a mirrored representation | ||
of the original `/_matrix/client/v3/user_directory/search` API. | ||
|
||
## Security considerations | ||
|
||
The same considerations as in [MSC2762](https://github.com/matrix-org/matrix-spec-proposals/pull/2762) | ||
apply. This feature will allow the widget to be able to receive information about who is present on | ||
the homeserver / in the user directory. This information could be used by the widget to send it to | ||
a third-party server to store or misuse it. However, the access will only be possible when the user | ||
accepts the capability and grant access if the widget is trusted by the user. | ||
|
||
## Unstable prefix | ||
|
||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not necessarily. So far, actions in the Widget API (like |
||
- Use `org.matrix.msc3973.user_directory_search` in place of `user_directory_search` for the action type in the | ||
`fromWidget` requests. | ||
- Only call/support the `action`s if an API version of `org.matrix.msc3973` is advertised. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two options to solve this:
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.