Allow users to knock over and over, removing CS complexity

proposals/2403-knock.md

@@ -46,18 +46,10 @@ that user can be transitioned to the following possible states:
  - `invite`: In this case, the knock was accepted by someone inside the room
    and they are inviting the knocker into the room.
  - `leave`: In this case, similar to how kicks are handled, the knock has
-   been rejected.
+   been rejected. Alternatively, the knocking user has rescinded their knock.
  - `ban`: In this case, the knock was rejected and the user has been prevented
    from sending further knocks.
 
-Users are not allowed to change their membership once set to `knock`, in
-order to prevent users from being able to knock multiple times and spam a
-room.
-
-XXX: So if you knock on a room that's then abandoned that's in your `/sync`
-forever? Clients should have a way to tell their server to hide and show
-knocks.
-
 ## Client-Server API
 Two new endpoints are introduced in the Client-Server API (similarly to
 join): `POST /_matrix/client/r0/rooms/{roomId}/knock` and `POST
@@ -84,7 +76,7 @@ Content-Type: application/json
 
 #### Responses:
 ##### Status code 200:
-The user knocked successfully. Empty reply:
+The user knocked successfully. Example reply:
 ```json
 {}
 ```
@@ -235,7 +227,6 @@ If they deny, then a leave membership event is sent in the room, and the
 knocking user will be notified through existing flows (matching the behaviour
 of when an invite is recinded).
 
-
 ## Server-Server API
 Similarly to join and leave over federation, a ping-pong game with two new
 endpoints is introduced: `make_knock` and `send_knock`. Both endpoints must
@@ -414,5 +405,14 @@ essentially allow outsiders to send messages into the room.
 
 It is still theoretically possible for a server admin to create many users
 with different user IDs or display names, all spelling out an abusive
-message, and then having each of them knock in order. In this case, room
-admins should employ typical abuse mitigation tools, such as Server ACLs.
+message, and then having each of them knock in order. 
+
+Another abuse vector is allowed by the ability for users to rescind knocks.
+This is to help users in case they knocked on a room accidentally, or simply
+no longer want to join a room they've knocked on. While this is a useful
+feature, it also allows users to spam a room by knocking and rescinding their
+knocks over and over.
+
+In both cases, room admins should employ typical abuse mitigation tools, such
+as user bans and server ACLs. Clients are encouraged to ease employing these
+tools easy even if the offensive user or server is present not in the room.