Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-30 20:48:37 +01:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Remove lost footnotes

Browse source 
These should have been part of MSC2962.
This commit is contained in:
Richard van der Hoff 2021-03-16 14:18:27 +00:00
parent bc1466206d
commit 62b9154fa7
1 changed files with 0 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
proposals/1772-groups-as-rooms.md
View file

@ -366,24 +366,3 @@ problems, including:
* e.g. Room Directories
* Groups are centralised, rather than being replicated across all
participating servers.
## Footnotes
<a id="f1"/>[1]: The converse, "anybody can join, provided they are not members
of the '#catlovers' space" is less useful since (a) users in the banned space
could simply leave it at any time; (b) this functionality is already somewhat
provided by [Moderation policy
lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1)
<a id="f2"/>[2]: Note that there is nothing stopping users sending and
receiving invites in `public` rooms today, and they work as you might
expect. The only difference is that you are not *required* to hold an `invite`
when joining the room. [↩](#a2)
<a id="f3"/>[3]: This is a marginal decrease in security from the current
situation with invite-only rooms. Currently, a misbehaving server can allow
unauthorized users to join an invite-only room by first issuing an invite to
that user. In theory that can be prevented by raising the PL required to send
an invite, but in practice that is rarely done. [↩](#a2)