diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md
index 9146c457..fda81592 100644
--- a/proposals/3083-restricted-rooms.md
+++ b/proposals/3083-restricted-rooms.md
@@ -20,10 +20,12 @@ to trust for membership. For example:
         "join_rule": "restricted",
         "allow": [
             {
+                "type": "room-membership",
                 "room": "!mods:example.org",
                 "via": ["example.org"]
             },
             {
+                "type": "room-membership",
                 "room": "!users:example.org",
                 "via": ["example.org"]
             }
@@ -40,10 +42,14 @@ 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:
 
+* `type`: `"room-membership"` to describe that we are allowing access via room
+  membership. Future MSCs may define other types.
 * `room`: The room ID to check the membership of.
 * `via`: A list of servers which may be used to peek for membership of the room.
 
-Any entries in the list which do not match the expected format are ignored.
+Any entries in the list which do not match the expected format are ignored. Thus,
+if all entries are invalid, the list behaves as if empty and all users without
+an invite are rejected.
 
 When a homeserver receives a `/join` request from a client or a `/make_join` / `/send_join`
 request from a server, the request should only be permitted if the user has a valid
@@ -167,6 +173,17 @@ If you make a parent space invite-only, should that (optionally?) cascade into
 child rooms? This would have some of the same problems as inheriting power levels,
 as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
 
+### Additional allow types
+
+Future MSCs may wish to define additional values for the `type` argument, potentially
+restricting access via:
+
+* MXIDs or servers.
+* A shared secret (room password).
+
+These are just examples are not fully thought through for this MSC, but it should
+be possible to add these behaviors in the future.
+
 ## Footnotes
 
 <a id="f1"/>[1]: The converse restriction, "anybody can join, provided they are not members