Experimental join_rule for joining rooms in a space without an invite

[clokep]

For the Spaces project there needs to be a way to allow users to join a room based on membership in a space.

An approach for this is detailed in MSC3083.

The approach will be to:

• Create an experimental room version.
• Update the auth rules based on the join_rule / experimental room version to allow users to join based on the allowed key in the m.room.join_rules event.

Note that we want this to be in an experimental room version as it is unclear whether clients will need to make changes to support this.

[clokep]

I think we can use the term restricted fine (not name-spaced) since we'll put this into an experimental room version.

[richvdh]

I think we can use the term restricted fine (not name-spaced) since we'll put this into an experimental room version.

I'm not entirely sure that follows. @turt2live wdyt?

[clokep]

My thought process was that since the room version is experimental, then anything inside of it is essentially namespaced away from "stable" already, but maybe that doesn't make sense. 🤷 I'm happy to namespace if that seems clearer.

[turt2live]

uhh, I need a lot more context. Is there a short summary of the issue?

[clokep]

uhh, I need a lot more context. Is there a short summary of the issue?

There's a proposal to add a new join rule (restricted) as part of a new room version. While doing development work on this I plan to use an experimental room version (org.matrix.mscxxxx). The question is whether the join_rule value should also be namespaced (org.matrix.mscxxxx.restricted) or it being part of an unstable room version is enough.

[turt2live]

The intent of the process is that the restricted keyword would also be namespaced, though given the MSC's purpose and that the room version's namespace is clearly for that MSC, it would be fine to go without. Reason being that room versions aren't supposed to be used for doing arbitrarily custom things without namespacing, but when a room version is clearly identified for a given purpose, there's no point in us saying you must use extra complexity in representation.

Team mechanics might reveal other opinions, such as the restricted keyword popping up in the middle of the codebase without any reference in the official spec, but that's beyond my role 😄 (the widget-api and other various projects tend to make a deliberate effort to at least name the constants MSC2962_RESTRICTED = "restricted" to fix this problem).

[clokep]

An approach for this is detailed in MSC2962.

Note that this has been modified a bit, you can see a current draft at https://hackmd.io/zO0fQwo9TqurOt66mF5Qmg?view.