Open erikjohnston opened 4 years ago
Out of interest, what's the rationale for using /invite
rather than just pushing a membeship event to the server when both servers are in the room? I couldn't figure that out from reading the spec.
@erikjohnston suggested that one possible solution is to not persist the event as an outlier if another local user is already in the room.
Out of interest, what's the rationale for using
/invite
rather than just pushing a membeship event to the server when both servers are in the room? I couldn't figure that out from reading the spec.
We require the invite is signed by the target server before it gets sent out (to stop servers from pretending they invited another server without telling them, thus blocking other servers from trying to invite it)
We require the invite is signed by the target server before it gets sent out
do we, though?
We require the invite is signed by the target server before it gets sent out
do we, though?
The spec doesn't seem to mention this, and I don't believe that synapse enforces it.
If
@alice:local
and@bob:remote
are in a room and@bob:remote
invites@charlie:local
, then@alice:local
may not see the invite come down sync.This is because the remote server sends an invite over
/invite
, which the local server persists as an outlier and forwards to Charlie. Alice does a/sync
, the invite does not get returned as it is an outlier. The remote server then sends the invite to the local server in a standard federation transaction, which then flips the outlier bit in the DB. When Alice does another/sync
they still won't get the event as their since token will be after the invite event.