Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 90 additions & 0 deletions proposals/3973-widgetapi-user-directory-search.md
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.
Comment on lines +11 to +14
Copy link
Author

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:

  1. Just return the response from the CS-API.
  2. 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.

Copy link

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.


## 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.
Copy link
Member

Choose a reason for hiding this comment

The 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?)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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.