wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Remove spaces summary changes.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-04 08:24:49 -04:00 • committed by Richard van der Hoff
parent ef02f82afb
commit 7994a1e85a
1 changed files with 0 additions and 86 deletions
Download patch file Download diff file Expand all files Collapse all files

86
proposals/3083-restricted-rooms.md
View file

@ -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> 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. 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 ## 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) See the [join rules](https://matrix.org/docs/spec/client_server/r0.6.1#m-room-join-rules)