s/accept/ready/ because we already have an m.key.verification.accept

proposals/2366-key-verification-accept.md

@@ -1,4 +1,4 @@
-# Key verification flow addition: `m.key.verification.accept`
+# Key verification flow addition: `m.key.verification.ready`
 
 The current key verification framework is asymmetrical in that the user who
 requests the verification is unable to select the key verification method.
@@ -10,11 +10,11 @@ verifying in-person, but are using a trusted but remote channel of verification
 ## Proposal
 
 A new event type is added to the key verification framework:
-`m.key.verification.accept`, which may be sent by the target of the
+`m.key.verification.ready`, which may be sent by the target of the
 `m.key.verification.request` message, upon receipt of the
 `m.key.verification.request` event.  It has the fields:
 
-- `from_device`: the ID of the device that sent the `m.key.verification.accept`
+- `from_device`: the ID of the device that sent the `m.key.verification.ready`
   message
 - `methods`: an array of verification methods that the device supports
 
@@ -22,7 +22,7 @@ It also has the usual `transaction_id` or `m.relates_to` fields for key
 verification events, depending on whether it is sent as a to-device event
 or an in-room event.
 
-After the `m.key.verification.accept` event is sent, either party can send an
+After the `m.key.verification.ready` event is sent, either party can send an
 `m.key.verification.start` event to begin the verification.  If both parties
 send an `m.key.verification.start` event, and they both specify the same
 verification method, then the event sent by the user whose user ID is the
@@ -32,7 +32,7 @@ compared instead.  If both parties send an `m.key.verification.start` event,
 but they specify different verification methods, the verification should be
 cancelled with a `code` of `m.unexpected_message`.
 
-The `m.key.verification.accept` event is optional; the recipient of the
+The `m.key.verification.ready` event is optional; the recipient of the
 `m.key.verification.request` event may respond directly with a
 `m.key.verification.start` event instead.  This is for compatibility with the
 current version of the spec.
@@ -46,7 +46,7 @@ There are now three possible ways that a key verification can be performed:
 2. A device sends an `m.key.verification.request` event and the recipient
    replies with an `m.key.verification.start` event.
 3. A device sends an `m.key.verification.request` event and the recipient
-   replies with an `m.key.verification.accept` event, and which point, either
+   replies with an `m.key.verification.ready` event, and which point, either
    device can send an `m.key.verification.start` event to begin the
    verification.