content/client-server-api/_index.md

@@ -4145,7 +4145,6 @@ systems.
 {{% cs-module name="SSO client login/authentication" filename="sso_login" %}}
 {{% cs-module name="Direct Messaging" filename="dm" %}}
 {{% cs-module name="Ignoring Users" filename="ignore_users" %}}
-{{% cs-module name="Invite permission" filename="invite_permission" %}}
 {{% cs-module name="Sticker Messages" filename="stickers" %}}
 {{% cs-module name="Reporting Content" filename="report_content" %}}
 {{% cs-module name="Third-party Networks" filename="third_party_networks" %}}
@@ -4161,3 +4160,4 @@ systems.
 {{% cs-module name="Recently used emoji" filename="recent_emoji" %}}
 {{% cs-module name="Threading" filename="threading" %}}
 {{% cs-module name="Reference relations" filename="reference_relations" %}}
+{{% cs-module name="Invite permission" filename="invite_permission" %}}

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

@@ -6,13 +6,13 @@
 Users may want to control who is allowed to invite them to new rooms. This module defines how
 clients and servers can implement invite permission.
 
-#### Account data
+#### Events
 
 {{% event event="m.invite_permission_config" %}}
 
 #### Client behaviour
 
-To reject invites from all users automatically, clients MAY add an [`m.invite_permission_config`](#minvite_permission_config)
+To reject invites from all users automatically, clients MUST add an [`m.invite_permission_config`](#minvite_permission_config)
 event in the user's [account data](#client-config) with the `default_action` property set to
 `block`. To stop rejecting all invites, the same event without the `default_action` property MUST be
 added to the account data.
@@ -20,8 +20,8 @@ added to the account data.
 When the `default_action` field is unset, other parts of the specification might still have effects
 on invites seen by clients, like [ignoring users](#ignoring-users).
 
-Attempting to send an invite to a user that blocks invites will result in an error response with the
+When sending an invite to a user that blocks invites, clients SHOULD receive an error response with
-`M_INVITE_BLOCKED` error code.
+the `M_INVITE_BLOCKED` error code.
 
 #### Server behaviour
 
@@ -38,8 +38,9 @@ is invited:
 * [`PUT /_matrix/client/v3/rooms/{roomId}/state/m.room.member/{stateKey}`](#put_matrixclientv3roomsroomidstateeventtypestatekey),
   when the `membership` is set to `invite`.
 
-In addition, invite events for this user already in the database, or received over federation, MUST
+In addition, existing events already in the database MUST NOT be served over client synchronisation
-NOT be served over client synchronisation endpoints such as [`GET /sync`](#get_matrixclientv3sync).
+endpoints such as [`GET /sync`](#get_matrixclientv3sync). Invite events received over federation
+should likewise not be served over `GET /sync` requests.
  
 Servers MAY return any suppressed invite events over `GET /sync` if invite blocking is later
 disabled.

data/api/client-server/third_party_membership.yaml

@@ -97,10 +97,6 @@ paths:
             - The invitee is already a member of the room.
             - The inviter is not currently in the room.
             - The inviter's power level is insufficient to invite users to the room.
-
-            {{% added-in v="1.18"%}} The `M_INVITE_BLOCKED` error code is used to
-            indicate that the homeserver rejected the invite due to
-            [invite blocking](/client-server-api/#invite-permission).
           content:
             application/json:
               schema: