Faster joins: Creating events from local users: Answer queries over federation where we are obligated to answer #14059
Description
Part of #12997.
When we send a PDU out over federation, there are some queries that we are obligated to answer if the destination makes them.
This includes being able to give back the prev_events
of the events that we send. (This is why we can only send events in a safe chain (c.f. #14057) — we don't want to risk leaking other servers' messages as part of our obligations here.)
There may be other obligations; we'll have to look into these.
Obviously we can't answer /state
and /state_ids
, which is something that out-of-the-loop homeservers can and will request. We could proxy it from a fully-resident server, but this amounts to downloading the entirety of state, which is what we hoped to avoid in /send_join
by introducing partial joins in the first place.
In these cases, we'll just have to error out (perhaps with MSC3895 'Unable'). We are happy to accept that we can't send PDUs to out-of-the-loop homeservers. Besides, since we're syncing with another active homeserver, the out-of-the-loop homeserver is still able to catch up from somewhere anyway.
Related:
- Server-Server API does not specify that sending servers need to be able to give
prev_events
for the events that they send matrix-spec#1228 (Let's also document these obligations into the spec as we dig them up.)
Tasks:
- answer
/get_missing_events
with events from the safe chain - figure out if we ever need to answer backfill?
- bail out on
/state
and/state_ids
(I think this is already done as of Faster Remote Room Joins: tell remote homeservers that we are unable to authorise them if they query a room which has partial state on our server. #13823, but should check!)- figure out what the consequences of not answering
/state
are
- figure out what the consequences of not answering
- put together some Complement tests to ensure this is all enough and that the server is doing the right thing
- MSC3895 defines the error that we can use as an excuse for not answering, but we also need to update MSC3895 to clearly define the obligations where you can't use it as an excuse.