diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md
index 76852998..c21e4078 100644
--- a/proposals/3083-restricted-rooms.md
+++ b/proposals/3083-restricted-rooms.md
@@ -59,92 +59,6 @@ checked cannot be enforced over federation by event authorization, so servers in
 the room are trusted not to allow invalid users to join.<sup id="a3">[3](#f3)</sup>
 However, user IDs listed as strings can be properly checked over federation.
 
-### Discovery of restricted rooms
-
-The discovery of rooms in a space, as discussed in
-[MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946): spaces summary,
-must be updated to allow for discovery of restricted rooms.
-
-MSC2946 defines that a room should be included in the spaces summary if it is
-accessible (world-readable or if the user is already in the room). [MSC3173](https://github.com/matrix-org/matrix-doc/pull/3173)
-declares that if a user can view the stripped state of a room if they are *able*
-to join the room. Combining these two MSCs, the spaces summary should include
-rooms with restricted join rule which a user is able to join (i.e. they're a
-member of one of the spaces declared in the join rule).
-
-The server-server API discussed in [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946)
-does not know the user who is requesting a summary of the space, but should divulge
-the above information if any member of a server could see it. It is up to the
-calling server to properly filter this information.
-
-Trust is placed in the calling server: if there are any users on the calling
-server in the correct space, that calling server has a right to know about the
-rooms in that space and should return the relevant summaries, along with enough
-information that the calling server can then do some filtering, thus an
-additional field is added to the server-server response of the spaces summary:
-
-* `allowed_spaces`: A list of space IDs which give access to this room.
-
-This would modify the example response given to:
-
-```jsonc
-{
-    "rooms": [
-        {
-            "room_id": "!ol19s:bleecker.street",
-            "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
-            "guest_can_join": false,
-            "name": "CHEESE",
-            "num_joined_members": 37,
-            "topic": "Tasty tasty cheese",
-            "world_readable": true,
-            "room_type": "m.space",
-            "allowed_spaces": ["!mods:example.org", "!users:example.org"]
-        },
-        { ... }
-    ],
-    "events": [
-        {
-            "type": "m.space.child",
-            "state_key": "!efgh:example.com",
-            "content": {
-                "via": ["example.com"],
-                "suggested": true
-            },
-            "room_id": "!ol19s:bleecker.street",
-            "sender": "@alice:bleecker.street"
-        },
-        { ... }
-    ]
-}
-```
-
-Consider that Alice and Bob share a server; Alice is a member of a space, but Bob
-is not. The remote server will not know whether the request is on behalf of Alice
-or Bob (and hence whether it should share details of restricted rooms within that
-space).
-
-Consider the above with a restricted room on a different server which defers
-access to the above space. When summarizing the space, the homeserver must make
-a request over federation for information on the room. The response would include
-the room (since Alice is able to join it), but the calling server does not know
-*why* they received the room, without additional information the server cannot
-properly filter the returned results.
-
-Note that there are still potential situations where each server individually
-doesn't have enough information to properly return the full summary, but these
-do not seem reasonable in what is considered a normal structure of spaces. (E.g.
-in the above example, if the remote server is not in the space and does not know
-whether the server is in the space or not it cannot return the room.)
-
-(The alternative, where the calling server sends the requesting `user_id`, and
-the target server does the filtering, is unattractive because it rules out a
-future world where the calling server can cache the result.)
-
-This does not decrease security since a server could lie and make a request on
-behalf of a user in the proper space to see the given information. I.e. the
-calling server must be trusted anyway.
-
 ## Summary of the behaviour of join rules
 
 See the [join rules](https://matrix.org/docs/spec/client_server/r0.6.1#m-room-join-rules)