Rescinding or declining a room join request over federation is not implemented

[jmartinesp]

Description

While working on the room knocking feature in a client I realised I wasn't receiving any feedback after either cancelling a knock request or declining it over federation, only accepting one (sending an invite) seemed to work.

After taking a look at Synapse's code I found:

synapse/synapse/handlers/room_member.py

Lines 2022 to 2025 in eedab12

	# TODO: We don't yet support rescinding knocks over federation
	# as we don't know which homeserver to send it to. An obvious
	# candidate is the remote homeserver we originally knocked through,
	# however we don't currently store that information.

This mentions only rescinding (aka cancelling) knocks over federation, but the code that calls this function will be triggered when effective_membership_state == Membership.LEAVE and this will also happen when kicking a knock member (declining an invite).

I did some tests with element.io and matrix.org members in a room with knock join rule and they seemed to confirm my suspicions: neither cancelling a knock request nor declining it seems to work over federation.

Maybe this needs matrix-org/matrix-spec-proposals#4233 ?

Steps to reproduce

• Create a room with knock join rule in a homeserver (HS1).
• Request to join the room with an user in another homeserver (HS2).
• As the user in HS2, cancel the request to join. The user in HS1 will still see the knock membership after reloading the room members.
• Now decline the knock request in HS1. The user in HS2 won't receive any membership updates in the /sync methods and will still think his knock request is pending.

Homeserver

matrix.org, element.io

Synapse Version

1.120.2

Installation Method

I don't know

Database

Not sure they're not my HS

Workers

I don't know

Platform

Not sure.

Configuration

No response

Relevant log output

AFAICT there was no relevant log output, as no action is done.

Anything else that would be useful to know?

No response

[anoadragon453]

@jmartinesp Yes, that MSC being implemented in the homeserver help with being able to rescind knocks (more) reliably over federation. It calls on homeservers to track which other homeservers it sent the original knock event through, and communicate that to the client.

However, MSC4233 is mostly about joining a room after knocking, rather than leaving the room (aka rescinding a knock). It puts the onus on clients to tell the homeserver in the POST /_matrix/client/v3/join/{roomIdOrAlias} request by setting the via query parameter.

You'll notice that the POST /_matrix/client/v3/rooms/{roomId}/leave endpoint has no via query parameter. This is because before knocking, you must be joined to a room in order to call this endpoint. But knocking changes this fundamental assumption - this seems like an oversight in the knocking MSC, and is something that MSC4233 could be well-placed to fix. I've left a comment on the MSC with two potential ways forward.

Note that MSC4233 helps by tracking the servers we knocked through - though it's not guaranteed that those homeservers will be reachable when it comes time for a user to rescind their knock. The client must still handle errors similar to those today - they will just be much less common.

cc @manuroe @wrjlewis for progress tracking.