Open Half-Shot opened 3 months ago
The homeserver may only be caching details of local members rather than all members, though this performance hit is likely acceptable for appservice users when querying remote members.
Yeah, no doubt. It's probably still quicker for the HS to determine visibility though event caches / access to "raw" data in the database than a client asking for all the state to determine it.
The reason being if I am doing some operation that involves me sending information about a prior event to a user, I would like to be able to determine if that user can access the event in question.
Currently, the spec only has one mechanism to determine when a user joined a room and that is to use the
/state
endpoint, which is quite heavy. There isn't another way to pull down the send time of am.room.member
event for a joined user. There are ways to avoid some of the costs by caching, but it's not ideal to hold a local copy of everyones join times.Ideally, I'd like a way to ask the homeserver if user X has access to event Y based on it's knowledge of the room and therefore know if the action I am taking should continue. The homeserver should know this information, and will likely have cached the relevant info already as knowing event visibility for a user is central to a lot of operations on a homeserver.
Something akin to
GET /_matrix/client/v3/rooms/{roomId}/event/{eventId}/visible?target=@theuser:foobar.com