Merge 95abf08701 into 8a2c58b1b1

* Typo "not" -> "no"

Signed-off-by: Andy Balaam <andy.balaam@matrix.org>

---------

Signed-off-by: Andy Balaam <andy.balaam@matrix.org>

changelogs/client_server/newsfragments/2107.clarification

@@ -0,0 +1 @@
+"Public" rooms have no specific meaning with respect to moderation policy lists.

changelogs/client_server/newsfragments/2121.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

content/client-server-api/modules/moderation_policies.md

@@ -18,8 +18,9 @@ the entity making the decisions on filtering is best positioned to
 interpret the rules how it sees fit.
 
 Moderation policy lists are stored as room state events. There are no
-restrictions on how the rooms can be configured (they could be public,
-private, encrypted, etc).
+restrictions on how the rooms can be configured in terms of
+[join rules](#mroomjoin_rules), [history visibility](#room-history-visibility),
+encryption, etc.
 
 There are currently 3 kinds of entities which can be affected by rules:
 `user`, `server`, and `room`. All 3 are described with

content/client-server-api/modules/secrets.md

@@ -58,7 +58,7 @@ available on all their clients. Unless the user specifies otherwise,
 clients will try to use the default key to decrypt secrets.
 
 Clients that want to present a simplified interface to users by not supporting
-multiple keys should use the default key if one is specified. If not default
+multiple keys should use the default key if one is specified. If no default
 key is specified, the client may behave as if there is no key is present at
 all. When such a client creates a key, it should mark that key as being the
 default key.