Add parameter to control whether we do a faster join

[squahtx]

When the local homeserver is already joined to a room and wants to
perform a remote join, we may find it useful to do a non-partial state
join if we already have the full state for the room.

Signed-off-by: Sean Quah [email protected]

[DMRobertson]

When the local homeserver is already joined to a room and wants to
perform a remote join, we may find it useful to do a non-partial state
join if we already have the full state for the room.

Can you remind me of the scenario we had in mind here?

IIRC we talked about a join-via-space-membership ("restricted join") where we are already fully joined to the room but lack a local user in that space. Was the idea to request a partial join in that situation?

[squahtx]

When the local homeserver is already joined to a room and wants to
perform a remote join, we may find it useful to do a non-partial state
join if we already have the full state for the room.

Can you remind me of the scenario we had in mind here?

The idea is to do a full join if we are in the room and have full state. Conversely, we will do a partial join when not in the room or we have partial state.

IIRC we talked about a join-via-space-membership ("restricted join") where we are already fully joined to the room but lack a local user in that space. Was the idea to request a partial join in that situation?

In that situation, we have to do a full join if fully joined, since we aren't allowed to persist a partial state event in a full state room.

[DMRobertson]

The idea is to do a full join if we are in the room and have full state. Conversely, we will do a partial join when not in the room or we have partial state.

I was just a bit surprised by this: if we have the full state, then we hopefully don't need the full list of auth events and state events from the /send_join response---we already have them, and can request them via the usual mechanisms if not.

Perhaps that sort of thing would be a premature optimisation though.

[squahtx]

The idea is to do a full join if we are in the room and have full state. Conversely, we will do a partial join when not in the room or we have partial state.

I was just a bit surprised by this: if we have the full state, then we hopefully don't need the full list of auth events and state events from the /send_join response---we already have them, and can request them via the usual mechanisms if not.

Perhaps that sort of thing would be a premature optimisation though.

That's true, we could run the regular incoming event logic somehow. I guess I see doing a full join as the simplest route to doing something acceptable for restricted join rooms.