MSC3902: Faster remote room joins over federation (overview)

[richvdh]

This proposal gives an overview of the changes required to support faster remote joins.

It supercedes MSC2775.

Rendered

[timokoesters]

Alternatives: #3883, or "interactive peeking"

Less complicated state res => easier to verify correctness of spec and implementation

[DMRobertson]

Is this correct? Suppose @alice:alice.com partially joins a room via bob.com. Before the resync completes, she is banned from that room by @chris:chris.com. Call the ban event B.

Is there some way that B can be an invalid event whilst appearing valid enough to alice.com? If so, that means we can't reliably answer requests about local users' membership(?): during resync we'd think Alice was banned, but post-resync we'd realise she wasn't.

[richvdh]

yes, that can certainly happen. "Reliably" here is doing a bit of heavy lifting: we actually don't know any of the state for certain during the resync (events may be accepted that should not have been, and they can also be rejected when they should not have been. I seem to remember writing complement tests for both cases). We may therefore tell clients about state that turns out to be wrong. In some ways this is an extension of matrix-org/matrix-spec#1209.

But still, membership events for local users are in the same bracket as, for example, m.room.topic events: we assume that our view of the state is good enough, and return the events to clients without waiting for the resync to complete.

[timokoesters]

An alternative would be to send the currently known members and send updates to this list over /sync's state. Then it also makes sense to include partial rooms in non-lazyloaded syncs. What do you think about that? I think that's better than blocking, especially when we don't know when or if the room ever fully loads.

[squahtx]

In the current implementation in Synapse, non-lazy_load_members syncs don't block but instead pretend the room has not been joined until the homeserver has the full state of the room available. Other endpoints, like /members, still block.

I'm not sure whether it's spec-compliant to initially send the known members over /sync (we can propose a change to the spec if it isn't) or how clients would interpret it. It might be that all clients are okay with it. We just haven't tested it.

[timokoesters]

if we have a ban for
a particular user, then their events will be rejected.

This seems to be the goal of soft failing and not the "state at event" check. Before fast remote joins, these banned user's events would still be accepted as outliers. To get the same behavior, we could remove the "state at event" auth check (unless there's a good reason to keep it?).

[squahtx]

The case we had in mind was where the "true" state of the room after event P has a ban for user @bad:some-homeserver.com and @bad:some-homeserver.com sends an event E, with {P} as its prev_events and citing its membership prior to the ban as an auth event. The faster joining homeserver may or may not have the ban for that user in its idea of the state after P. If it does, we want event E to be correctly rejected rather than trusting its auth events. To reject E, we have to run the "Passes authorization rules based on the (partial) state before the event" check. But the check would also reject most normal messages because their sender's memberships won't be in the partial state, so we combine the partial state with the auth events using state resolution.

In the soft fail case, where @bad:some-homeserver.com is banned in the current state of the room, but picks very old prev_events to send events with, the accept/reject behavior is unchanged.

[timokoesters]

This state resolution will be extremely expensive because nearly all events are conflicting

[squahtx]

I'm not very familiar with state resolution, but if we take the expected case where the auth events match those in the partial state, we'd be calculating state_res( partial_state={ create, power levels, name, topic, ... }, auth_events={ create, power levels, sender membership }).

You're right that the conflicted state set would include most state events in the room: {name, topic, ..., sender membership}
but wouldn't this set be small, since most memberships aren't in the room's partial state? I'd also expect the auth difference to be small because both sets of state contain the same create and power levels events in the common case.

[squahtx]

I can't remember the rationale for doing state res here. I think a way to combine the partial state with the auth events was needed and state resolution was the usual way we combine state. Something simpler, like filling in the gaps in partial state with the auth events, might be appropriate too, but I may be overlooking some considerations.

[richvdh]

I can't remember the rationale for doing state res here. I think a way to combine the partial state with the auth events was needed and state resolution was the usual way we combine state.

Yes, basically this. It was an attempt to enforce bans, as far as possible.

[timokoesters]

since most memberships aren't in the room's partial state

Wouldn't this fill up with time and when the room is almost fully synced include a lot of events?

[DMRobertson]

I think this line is redundant, now that the Synapse issue is closed (by this PR).

Suggested change

	(This is [pending implementation](https://github.com/matrix-org/synapse/issues/12989) in Synapse.)