This means that a user must be a member of the `!mods:example.org` space or
`!users:example.org` space in order to join without an invite<supid="a2">[2](#f2)</sup>. Membership in
a single space is enough.
If the `allow` key is an empty list (or not a list at all), then no users are allowed to join without an invite. Each entry is expected to be an object with the
following keys, or a string representing the MXID of the user exempted:
*`space`: The room ID of the space to check the membership of.
*`via`: A list of servers which may be used to peek for membership of the space.
Any entries in the list which do not match the expected format are ignored.
*`restricted`: the same as `public` from the perspective of the auth rules, but
with the additional caveat that servers are expected to check the `allow` rules
before generating a `join` event (whether for a local or a remote user).
## Security considerations
The `allow` feature for `join_rules` places increased trust in the servers in the
room. We consider this acceptable: if you don't want evil servers randomly
joining spurious users into your rooms, then:
1. Don't let evil servers in your room in the first place
2. Don't use `allow` lists, given the expansion increases the attack surface anyway by letting members in other rooms dictate who's allowed into your room.
## Unstable prefix
The `restricted` join rule will be included in a future room version to ensure
that servers and clients opt-into the new functionality.
During development it is expected that an unstable room version of
### Kicking users out when they leave the allowed space
In the above example, suppose `@bob:server.example` leaves `!users:example.org`:
they should be removed from the room. One option is to leave the departure up
to Bob's server `server.example`, but this places a relatively high level of trust
in that server. Additionally, if `server.example` were offline, other users in
the room would still see Bob in the room (and their servers would attempt to
send message traffic to it).
Another consideration is that users may have joined via a direct invite, not via access through a space.
Fixing this is thorny. Some sort of annotation on the membership events might
help. but it's unclear what the desired semantics are:
* Assuming that users in a given space are *not* kicked when that space is
removed from `allow`, are those users then given a pass to remain
in the room indefinitely? What happens if the space is added back to
`allow` and *then* the user leaves it?
* Suppose a user joins a room via a space (SpaceA). Later, SpaceB is added to
the `allow` list and SpaceA is removed. What should happen when the
user leaves SpaceB? Are they exempt from the kick?
### Inheriting join rules
If you make a parent space invite-only, should that (optionally?) cascade into
child rooms? Seems to have some of the same problems as inheriting power levels, as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
## Footnotes
<aid="f1"/>[1]: The converse restriction, "anybody can join, provided they are not members
of the '#catlovers' space" is less useful since:
1. Users in the banned space could simply leave it at any time
2. This functionality is already somewhat provided by [Moderation policy lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1)
<aid="f2"/>[2]: Note that there is nothing stopping users sending and
receiving invites in `public` rooms today, and they work as you might expect.
The only difference is that you are not *required* to hold an invite when
joining the room. [↩](#a2)
<aid="f3"/>[3]: This is a marginal decrease in security from the current
situation. Currently, a misbehaving server can allow unauthorized users to join
any room by first issuing an invite to that user. In theory that can be
prevented by raising the PL required to send an invite, but in practice that is