archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix typos.

Browse Source 
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
pull/3368/head
Patrick Cloke 3 years ago committed by Richard van der Hoff
parent 72961e6f29
commit d399653cab
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File

12
proposals/3083-restricted-rooms.md
Unescape Escape View File

@ -57,7 +57,7 @@ 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 if all entries are invalid, the list behaves as if empty and all users without
an invite are rejected. an invite are rejected.
When an homeserver receives a `/join` request from a client or a `/make_join` / When a homeserver receives a `/join` request from a client or a `/make_join` /
`/send_join` request from another homeserver, the request should only be permitted `/send_join` request from another homeserver, the request should only be permitted
if the user is invited to this room, or is joined to one of the listed rooms. If if the user is invited to this room, or is joined to one of the listed rooms. If
the user is not a member of at least one of the rooms, the homeserver should return the user is not a member of at least one of the rooms, the homeserver should return
@ -102,7 +102,7 @@ caveat that servers must ensure that:
* The auth chain of the join event needs to include events which prove * The auth chain of the join event needs to include events which prove
the homeserver can be issuing the join. This can be done by including: the homeserver can be issuing the join. This can be done by including:
* The `m.room.power_levels` event * The `m.room.power_levels` event.
* The join event of the user specified in `join_authorised_via_users_server`. * The join event of the user specified in `join_authorised_via_users_server`.
It should be confirmed that the authorising user is in the room. (This It should be confirmed that the authorising user is in the room. (This
@ -182,7 +182,7 @@ generating a join event. Peeking over federation, as described in
could be used to establish if the user is in any of the proper rooms. could be used to establish if the user is in any of the proper rooms.
This would then delegate power out to a (potentially) untrusted server, giving that This would then delegate power out to a (potentially) untrusted server, giving that
the peek server significant power. For example, a poorly chosen peek peek server significant power. For example, a poorly chosen peek
server could lie about the room membership and add an `@evil_user:example.org` server could lie about the room membership and add an `@evil_user:example.org`
to an allowed room to gain membership to a room. to an allowed room to gain membership to a room.
@ -193,7 +193,7 @@ the requesting homeserver to retry via another homeserver.
In the above example, suppose `@bob:server.example` leaves `!users:example.org`: In the above example, suppose `@bob:server.example` leaves `!users:example.org`:
should they be removed from the room? Likely not, by analogy with what happens should they be removed from the room? Likely not, by analogy with what happens
when you switch the join rules from public to invite. Join rules currently govern when you switch the join rules from `public` to `invite`. Join rules currently govern
joins, not existing room membership. joins, not existing room membership.
It is left to a future MSC to consider this, but some potential thoughts are It is left to a future MSC to consider this, but some potential thoughts are
@ -209,7 +209,7 @@ Another consideration is that users may have joined via a direct invite, not via
access through a room. access through a room.
Fixing this is thorny. Some sort of annotation on the membership events might Fixing this is thorny. Some sort of annotation on the membership events might
help. but it's unclear what the desired semantics are: help, but it's unclear what the desired semantics are:
* Assuming that users in an allowed room are *not* kicked when that room is * Assuming that users in an allowed room are *not* kicked when that room is
removed from `allow`, are those users then given a pass to remain removed from `allow`, are those users then given a pass to remain
@ -236,7 +236,7 @@ restricting access via:
* MXIDs or servers. * MXIDs or servers.
* A shared secret (room password). * A shared secret (room password).
These are just examples are not fully thought through for this MSC, but it should These are just examples and are not fully thought through for this MSC, but it should
be possible to add these behaviors in the future. be possible to add these behaviors in the future.
### Client considerations ### Client considerations

Write Preview
Loading…
Cancel
Save