Room namespace registrations are not considered when sending EDUs to Application Services

[anoadragon453]

Application Services can specify user, room ID and room alias namespaces in their registration file. The idea is such that any event that would involve either a user or a room specified by those namespaces would be sent to the homeserver.

In the case of Ephemeral Data Units (aka EDUs, like typing events, presence updates, read receipts etc), only the user namespace is taken into account when determining whether to forward an event to an application service. However, room ID and alias namespaces are not considered:

Read receipts

synapse/synapse/handlers/receipts.py

Lines 263 to 269 in eb9ddc8

	# Then filter down to rooms that the AS can read
	events = []
	for room_id, event in rooms_to_events.items():
	if not await service.matches_user_in_member_list(room_id, self.store):
	continue
	events.append(event)

Typing events

synapse/synapse/handlers/typing.py

Lines 479 to 482 in aa2c027

	if not await service.matches_user_in_member_list(
	room_id, handler.store
	):
	continue

As an example, if I read a message in room X (meaning I sent a read receipt for a message in that room) an appservice should receive that read receipt in 3 cases:

1. A user that lies within the appservice's user namespace is in the room.
2. The room's ID is in the appservice's room ID namespace.
3. The room's alias is in the appservice's room alias namespace.

As it stands, only 1. actually succeeds today. That means if an appservice has a room alias namespace which includes room X - yet none of the users in the room are in that appservice's user namespace - then that appservice will not receive the read receipt. It should have done, and MSC2409 states as such.

This is currently only an issue for read receipts and typing events (EDUs which are tied to a room). Presence updates aren't tied to a room, and are based on which users you share a room with. This logic is correct.