MSC3869: Read event relations with the Widget API #3869
Conversation
…matrix room Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
dhenneke
force-pushed
the
nic/feat/widgetapi-read-relations
branch
from
22ad7b6
to
6d5a6a0
Compare
dhenneke
changed the title
dhenneke
changed the title
turt2live
added
proposal
| The `direction` parameter is used to specify the direction to search for relations. It has the same | ||
| semantic as defined by ([MSC2675](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/2675-aggregations-server.md)). |
There was a problem hiding this comment.
I'm failing to find the direction parameter in either MSC2675 or the specification.
There was a problem hiding this comment.
You're right. I mixed up the MSC numbers. I meant MSC3715.
It is available as an experimental option in synapse:
And also part of the fetchRelations function in the matrix-js-sdk where I come across it. Though the name of the query parameter doesn't match with the synapse implementation 🤔:
We don't have a real use case for this feature, yet. So we could as well skip it for now. It also seems like the MSC in question isn't final yet.
There was a problem hiding this comment.
Hm, well I guess it's ultimately up to you whether to include the parameter, since MSC3715 is fairly close to FCP
There was a problem hiding this comment.
Then let's keep it in and hope that it becomes stable in synapse and get's fixed in the matrix-js-sdk so we can actually use it. It is also useful because then the relations(...) endpoint in the RoomWidgetClient will also be fully functioning.
There was a problem hiding this comment.
And also part of the
fetchRelationsfunction in thematrix-js-sdkwhere I come across it. Though the name of the query parameter doesn't match with the synapse implementation 🤔:
This is element-hq/element-web#22501, I believe.
There was a problem hiding this comment.
This is vector-im/element-web#22501, I believe.
Looks quite like it. So if we are adding it to the widget api, it would probably best to then name it dir. The client can then decide whether to use the unstable or stable parameter.
Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
robintown
removed
the
needs-implementation
… was available in synapse Signed-off-by: Dominik Henneke <dominik.henneke@nordeck.net>
| If the widget doesn't have appropriate permission, or an error occurs anywhere along the send path, | ||
| a standardized widget error response is returned. | ||
|
|
||
| If the request was successful, the client sends the following response: |
There was a problem hiding this comment.
The client is obligated to return what the widget requested and also to fetch all new events?
I think that should be made extra clear because that is something which usually is not the case. The client does not need to fulfill any guarantees in the other MSC's
There was a problem hiding this comment.
You mean that the client could also respond to this with a local cache of the relations? I implied that it should always get it from CS-API because it's also how it is (and was already) implemented in the matrix-js-sdk/Element. But it might be a good idea to clarify it here.
|
|
||
| In an e2ee room, all the events must be decrypted in the client prior to applying the filters or | ||
| providing them to the widget. This can take a considerable amount of time. The widget should take | ||
| care that it selects a reasonable `limit` to not run into timeouts in the widget transport layer. |
There was a problem hiding this comment.
maybe we should mention that this is the first widget api call that can force the client to trigger new cs-api calls. (all other msc's are phrased in a way, that the client can decide if it does not send the events.)
(I also think it would be nice to be more explicit what the clients responsibilities are. see other comment)
| searched is minimized. | ||
|
|
||
| The same limitations would apply if we would consider to provide direct access to the | ||
| `GET /_matrix/client/v3/rooms/{roomId}/messages` endpoint. |
There was a problem hiding this comment.
Maybe another alternative could be listed. Just to track the idea, that if the client also is capable of setting filters + use /messages custom event types could be used for a similar optimization. But I am not sure how expensive setting filters is.
There was a problem hiding this comment.
Not sure what you mean here. Filters won't work for e2e encryption because one would need to read and decrypt every message in the room to decide it which is not practical. But we could add a comment to clarify it.
| If the widget doesn't have appropriate permission, or an error occurs anywhere along the send path, | ||
| a standardized widget error response is returned. | ||
|
|
||
| If the request was successful, the client sends the following response: |
There was a problem hiding this comment.
something along the lines of:
| If the request was successful, the client sends the following response: | |
| Widgets can rely on the complete relation lists. | |
| The client is responsible to fetch all missing events form the matrix server. | |
| If the request was successful, the client sends the following response: |
Rendered
Implementations