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

Typing events

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.