Add m.federate into the auth rules

[neilalexander]

This is apparently something that we've been doing since the beginning of time in both Synapse and Dendrite and somehow it never made it into the spec.

There's a discussion point here though, as Synapse and Dendrite are doing very slightly different things. Synapse compares the event sender domain to the domain part of the room_id in the create event, whereas Dendrite compares to the domain part of the sender in the create event.

Happy to take advice on whether we think it's better to spec sender vs sender (on the basis that the domain should never have been different to the one in the room ID anyway) or whether we want to spec sender vs room_id (on the basis of being exactly what Synapse does).

Preview: https://pr1103--matrix-spec-previews.netlify.app

[turt2live]

generally lgtm.

I don't think we need to worry too much about sender vs room_id or vs sender of the create event because the auth rules also state:

1. If type is m.room.create:
   1. [...]
   2. If the domain of the room_id does not match the domain of the sender, reject.

effectively: if you compare to either, you're covered by another rule. For the spec though, let's do what Synapse does as it further implies that an unfederated room is "on" the given server, rather than being implied through other auth rules.

[turt2live]

Suggested change

	Auth rules: Clarify behaviour around the `m.federate` field in `m.room.create` events.
	For all room versions: Add `m.federate` to the authorization rules, as originally intended.

[turt2live]

this PR will also need adapting for v10 if we expect it to be included in Matrix 1.3 (otherwise it'll still need adapting, but with less urgency)

[richvdh]

lgtm but please add it to https://github.com/matrix-org/matrix-spec/blob/main/content/rooms/v10.md too (sorry!)

[neilalexander]

@richvdh Done!

[richvdh]

thanks!

[richvdh]

belatedly, a thought occurs to me: this is unclear about which create event we are talking about here. Do we mean the create event in the auth events (as mentioned on the line above), or the create event in the state at that point in the DAG (which is what the rest of the auth rules use).

I mean, if the two are different, we have a problem too, but we should really be explicit here.

[richvdh]

see also #1048