Thoughts on mixing restricted rooms with knocking capabilities

[turt2live]

It's somewhat desirable to have both knocking and MSC3083-style restricted rooms so that members can be graced entry with a knock/invite, regular invite, or based upon room membership elsewhere. At the moment, both join mechanisms are at odds with each other due to shared use of the join_rules.

A not-very-thought-through idea is to mimic the guest access approach for allow lists (MSC3083), making the restriction set independent of the join_rules entirely. This can mean that someone could have whatever join rule and still apply an allow list on top of it.

There are a number of challenges with this approach though, namely:

• Defining the interactions with join_rules is painful beyond high-level thinking.
• The existing confusion about "invite only but guests can join" is inherited.
• Splitting out restricted from the join rules feels a bit arbitrary: why not split out knocking? or even all of the rules?

An alternative would be to revamp join rules entirely, reimagining how that subsystem could work to support mixing of concerns (conditions) without interfering with itself. This may very well be a better approach.

More thought is definitely needed, but just dumping this here for posterity.

[turt2live]

for the record, I'm (as of writing) more convinced in the alternative of doing something to join rules to make it support mixing of different conditions, though have no idea what that'd look like.

[kevincox]

A reproduction of: matrix-org/matrix-spec-proposals#3083 (comment)

I think we can follow the pattern below. We have allow for joining but I think the simplest thing is adding allow_knock for knocking. If we have other things that require some sort of permission we can do that.

---

We can continue using a restricted event type but add a allow_knock field. Something like this:

{
    "type": "m.room.join_rules",
    "state_key": "",
    "content": {
        "join_rule": "restricted",
        "allow": [{
            "type": "m.room_membership",
            "room_id": "!users:example.org"
        }],
        "allow_knock": [{
            "type": "m.any"
        }]
    }
}

You could even compose these to allow members of a (bigger) space to knock.

{
    "type": "m.room.join_rules",
    "state_key": "",
    "content": {
        "join_rule": "restricted",
        "allow": [{
            "type": "m.room_membership",
            "room_id": "!mods:example.org"
        }],
        "allow_knock": [{
            "type": "m.room_membership",
            "room_id": "!users:example.org"
        }]
    }
}

Hopefully we can then deprecate the knock join_rule. Maybe even get rid of public and invite at the same time.

[kevincox]

I'm not sure what you mean by mixing conditions. In my mind the set of people who can join directly and the set of people who can knock are entirely separate. We just define each set (as shown above) and we are good to go. Of course someone could be in both sets but that is fine, they just join. They could knock if they want according to the protocol, but there isn't really a reason. (Maybe it could be a form of politeness? But probably best just to recommend that clients don't offer UI for that.

[turt2live]

I feel like the title of this is addressed, but if there's parts not already covered by one of the MSCs linked to this issue then let's open a new issue.