MSC4185: Event Visibility API - #4185
Conversation
Half-Shot
left a comment
Half-Shot
left a comment
There was a problem hiding this comment.
Looks very sensible to me and fixes a long standing issue we've had with visibility overall. I'd be curious to hear from the homeserver developer community if there are pitfalls with requesting this information frequently.
|
|
||
| While the homeserver is likely to have event visibility information cached for its local users, | ||
| the operation could be end up costly when performed for remote users. | ||
| Still, even for that case, the homeserver is probably in the best position to calculate this. |
There was a problem hiding this comment.
I wonder if caching is a thing we should mention, or whether that's an implementation detail?
turt2live
added
proposal
tulir
removed
the
needs-implementation
|
|
||
| GET /_matrix/client/v1/can_user_see_event/<room_id>/<user_id>/<event_id> | ||
|
|
||
| That responds with a boolean, revealing if `<user_id>` has access to `<event_id>` in `<room_id>`. |
There was a problem hiding this comment.
What determines if a user has access to an event?
I assume this has to do with room membership and history visibility but I feel we should probably explain this explicitly.
And for example, room encryption has nothing to do with this since that happens out of band on the client. (or redactions, etc)
| the operation could be end up costly when performed for remote users. | ||
| Still, even for that case, the homeserver is probably in the best position to calculate this. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
One alternative would be to just try fetching the event GET /_matrix/client/v3/rooms/{roomId}/event/{eventId}.
Responses
Status Description 200The full event. 404The event was not found or you do not have permission to read this event.
Application services can already request on the behalf of another user using the ?user_id=@example:example.org query parameter.
There was a problem hiding this comment.
I think that would indeed solve the problem for ASes. As the MSC notes, however, it excludes potential integrations that are not ASes (bots, for instance). Perhaps that's a YAGNI though, and this is worth setting aside until such need arises, if at all.
There was a problem hiding this comment.
Plugging this for the record: https://spec.matrix.org/v1.11/application-service-api/#identity-assertion
I don't think it will work for us in the general case. This can only apply to users in Appservice's control, which won't work for remote users even with very generous configuration.
5 participants
Rendered
Fixes matrix-org/matrix-spec#1747
Synapse implementation: element-hq/synapse#17973
IRC bridge implementation: matrix-org/matrix-appservice-irc#1833