|
|
|
@ -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)
|
|
|
|
|