# 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.
This makes it harder for more experienced users who wish to guide less
experienced users through the verification process, especially if they are not
verifying in-person, but are using a trusted but remote channel of verification
(such as telephone or video conference).

## Proposal

A new event type is added to the key verification framework:
`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.ready`
  message
- `methods`: an array of verification methods that the device supports

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.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
smallest is used, and the other `m.key.verification.start` event is ignored.
In the case of a single user verifying two of their devices, the device ID is
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.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.

## Potential issues

There are now three possible ways that a key verification can be performed:

1. A device begins a verification by sending an `m.key.verification.start`
   event.  This is only possible for to-device verification.
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.ready` event, and which point, either
   device can send an `m.key.verification.start` event to begin the
   verification.

This increases the complexity of implementations.