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

Do not require identity assertion when trying to read an event from a room that an appservice user is in #944

Open
Half-Shot opened this issue Dec 6, 2021 · 2 comments
Labels
A-Application-Services Issues affecting the AS API feature Suggestion for a significant extension which needs considerable consideration

Comments

@Half-Shot
Copy link
Contributor

Currently, the spec requires (or synapse requires, unsure at this point) that when reading something from a room (e.g an event) that an appservice must masquerade as a user within that room. This is unhelpful if the appservice isn't aware of who is in the room, only that one of it's users are in there.

If an appservice has any users joined to a room, it should be able to query event information from that room without having to supply a user_id parameter.

@Half-Shot Half-Shot added feature Suggestion for a significant extension which needs considerable consideration A-Application-Services Issues affecting the AS API labels Dec 6, 2021
@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 2, 2022
@jaller94
Copy link
Contributor

jaller94 commented Aug 7, 2022

This doesn't sound trivial, if we want to honour m.room.history_visibility for the appservice.

In rooms with m.room.history_visibility set to "history_visibility": "invited" or "history_visibility": "joined" the homeserver may have to calculate the earliest message an appservice is allowed to read.

@AndrewFerr
Copy link
Member

Is it sufficient that /joined_members already behaves this way? Even if the other endpoints retain their stricter auth, it's possible to use joined_members to find the appservice members in the target room & use them for masquerading, so maybe it's not much of an issue in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Application-Services Issues affecting the AS API feature Suggestion for a significant extension which needs considerable consideration
Projects
None yet
Development

No branches or pull requests

3 participants