We probably shouldn't be sending App Services events from every room we know about

[anoadragon453]

While undocumented in the Application Services API, Synapse's current behavior is to check on any event it sees for whether an app service is interested in it, and then send it off to that app service. We should further filter these by the rooms than an application service are a part of.

Without this constraint, for instance with Half-Shot's Discord Bridge, typing !discord in any channel causes about 10 different bots running on 10 different homeservers to try and answer. This also reportedly affects @turt2live's webhook bridge.

I plan to build the current loose functionality into Dendrite just to remain backwards compatible, but we really should change this unless anyone can give a reason why app services should get events from rooms they aren't in.

[turt2live]

fwiw, appservices can avoid this problem by not having @_webhook:.* as their regex. It requires a little bit of setup to reproduce, but can be easily observed:

• Create a room and invite your appservice (example being the webhook bridge here)
• On a different server, set up your webhook bridge but don't put it any rooms
• On that different server, join the room you created in step 1
• On either server, invoke something that causes the bridge to respond (!webhook for instance)
• Note that the original bridge responds happily, and the second bridge joins the room and sends a message

This is because the homeserver sees that a user matches the regex and forwards events to the bridge. The bridge then uses Intents to try and join the room before sending a message. Realistically, the homeserver shouldn't send events for .* domains unless the registration has a please_send_me_all_the_things flag set.

[turt2live]

So I may have come across a use case for having the existing functionality. If we do want to drop the behaviour, I think that's fine but we should include a flag for "yes I actually want to receive everything, thanks". Use case I found is: turt2live/matrix-monitor-bot#45