-
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 1 commit
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 | ||
|
||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (this is very nitpicky indeed...) 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. 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 |
||
a new capability that the user must manually approve: | ||
|
||
- `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. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is is a copy from MSC2762 because it asks for the same behavior. MSC2762 is mainly defining the actions |
||
standard error response in the Widget API. | ||
|
||
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. The widget will be able to receive information about who is present on the homeserver / user | ||
directory. | ||
|
||
## 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.