Calling PUT /_matrix/federation/v1/invite/{roomId}/{eventId} on a remote homeserver is redundant if they're already in the room

[anoadragon453]

PUT /_matrix/federation/v1/invite/{roomId}/{eventId} is useful, and its own endpoint, as homeservers that aren't yet participating in a room need to be directly notified when one of their users has been invited.

However, if a homeserver is already participating in a room, when one of their user is invited they'll receive both:

• The m.room.member invite event over the PUT /_matrix/federation/v1/send/{txnId} endpoint.
• A request to PUT /_matrix/federation/v1/invite/{roomId}/{eventId}.

Both of these tell the homeserver the same thing - and in practice developers tend to only implement event handling based on one of these. Typically /invite.

This also created subtle implementation bugs such as element-hq/synapse#18075 in Synapse - where Synapse notifies clients that they've been invited based on /invite - but doesn't actually consider the user invited until the corresponding m.room.member event comes in. If the user tries to join the room in this gap - they'll get an error that they haven't been invited.

It's also just unnecessary work - we don't need to notify a remote homeserver about an invite twice.

(credit to @MadLittleMods for originally pointing this out in the Synapse PR linked about.)

[richvdh]

IIRC, invite events are supposed to be signed by the invited homeserver, before they are sent out over PUT /_matrix/federation/v1/send/{txnId}. /v1/invite allows the target homeserver to return that signature.

You could argue that sending it again over PUT /_matrix/federation/v1/send/{txnId} to the target HS is redundant, but special-casing it is more work.