True if we have started the process of sending an m.key.verification.ready (but have not necessarily received
the remote echo which causes a transition to VerificationPhase.Ready.
The cancellation code e.g m.user which is responsible for cancelling this verification
returns whether the phase is PHASE_CANCELLED
The id of the user that cancelled the request, only defined when phase is PHASE_CANCELLED
the method picked in the .start event
True if we have started the process of sending an m.key.verification.cancel (but have not necessarily received
the remote echo which causes a transition to VerificationPhase.Cancelled).
returns whether the phase is PHASE_DONE
Whether this request was initiated by the syncing user. For InRoomChannel, this is who sent the .request event. For ToDeviceChannel, this is who sent the .start event
True if the other party in this request is one of this user's own devices.
once the phase is PHASE_STARTED (and !initiatedByMe) or PHASE_READY: common methods supported by both sides
The device id of the other party in this request, for requests happening over to-device messages only.
The user id of the other party in this request
whether this request has sent it's initial event and needs more events to complete
current phase of the request. Some properties might only be defined in a current phase.
Only set after a .ready if the other party can scan a QR code
returns whether the phase is PHASE_READY
The id of the user that (will) receive(d) the request
returns whether the phase is PHASE_REQUESTED
The key verification request event.
The request event, or falsey if not found.
The id of the user that initiated the request
For an in-room verification, the ID of the room.
returns whether the phase is PHASE_STARTED
Gets which device the verification should be started with given the events sent so far in the verification. This is the same algorithm used to determine which device to send the verification to when no specific device is specified.
The device information
The current remaining amount of ms before the request should be automatically cancelled
Unique ID for this verification request.
An ID isn't assigned until the first message is sent, so this may be undefined in the early phases.
The verifier to do the actual verification, once the method has been established. Only defined when the phase is PHASE_STARTED.
Alias for on.
Create a Verifier to do this verification via a particular method.
If a verifier has already been created for this request, returns that verifier.
This does not send the m.key.verification.start event - to do so, call Verifier.verify on the
returned verifier.
If no previous events have been sent, pass in targetDevice to set who to direct this request to.
the name of the verification method to use.
details of where to send the request to.
The verifier which will do the actual verification.
Use VerificationRequest#startVerification instead.
Cancels the request, sending a cancellation to the other party
the error code to send the cancellation with
the error reason to send the cancellation with
resolves when the event has been sent.
Synchronously calls each of the listeners registered for the event named
event, in the order they were registered, passing the supplied arguments
to each.
The name of the event to emit
Rest...args: Parameters<VerificationRequestEventHandlerMap[T]>Arguments to pass to the listener
true if the event had listeners, false otherwise.
Rest...args: Parameters<VerificationRequestEventHandlerMap[T]>Similar to emit but calls all listeners within a Promise.all and returns the promise chain
The name of the event to emit
Rest...args: Parameters<VerificationRequestEventHandlerMap[T]>Arguments to pass to the listener
true if the event had listeners, false otherwise.
Rest...args: Parameters<VerificationRequestEventHandlerMap[T]>Changes the state of the request and verifier in response to a key verification event.
the "symbolic" event type, as returned by the getEventType function on the channel.
the event to handle. Don't call getType() on it but use the type parameter instead.
whether this is an even received through sync or not
whether this is the remote echo of an event sent by the same device
whether this event is sent by a party that can accept and/or observe the request like one of our peers. For InRoomChannel this means any device for the syncing user. For ToDeviceChannel, just the syncing device.
a promise that resolves when any requests as an answer to the passed-in event are sent.
Returns the number of listeners listening to the event named event.
The name of the event being listened for
Returns a copy of the array of listeners for the event named event.
Alias for removeListener
Adds the listener function to the end of the listeners array for the
event named event.
No checks are made to see if the listener has already been added. Multiple calls
passing the same combination of event and listener will result in the listener
being added, and called, multiple times.
By default, event listeners are invoked in the order they are added. The prependListener method can be used as an alternative to add the event listener to the beginning of the listeners array.
The name of the event.
The callback function
a reference to the EventEmitter, so that calls can be chained.
Adds a one-time listener function for the event named event. The
next time event is triggered, this listener is removed and then invoked.
Returns a reference to the EventEmitter, so that calls can be chained.
By default, event listeners are invoked in the order they are added. The prependOnceListener method can be used as an alternative to add the event listener to the beginning of the listeners array.
The name of the event.
The callback function
a reference to the EventEmitter, so that calls can be chained.
Checks whether the other party supports a given verification method.
This is useful when setting up the QR code UI, as it is somewhat asymmetrical:
if the other party supports SCAN_QR, we should show a QR code in the UI, and vice versa.
For methods that need to be supported by both ends, use the methods property.
the method to check
to check even if the phase is not ready or started yet, internal usage
whether or not the other party said the supported the method
Adds the listener function to the beginning of the listeners array for the
event named event.
No checks are made to see if the listener has already been added. Multiple calls
passing the same combination of event and listener will result in the listener
being added, and called, multiple times.
The name of the event.
The callback function
a reference to the EventEmitter, so that calls can be chained.
Adds a one-timelistener function for the event named event to the beginning of the listeners array.
The next time event is triggered, this listener is removed, and then invoked.
The name of the event.
The callback function
a reference to the EventEmitter, so that calls can be chained.
Returns a copy of the array of listeners for the event named eventName,
including any wrappers (such as those created by .once()).
Removes all listeners, or those of the specified event.
It is bad practice to remove listeners added elsewhere in the code,
particularly when the EventEmitter instance was created by some other
component or module (e.g. sockets or file streams).
Optionalevent: EventEmitterEvents | ChangeThe name of the event. If undefined, all listeners everywhere are removed.
a reference to the EventEmitter, so that calls can be chained.
Removes the specified listener from the listener array for the event named event.
a reference to the EventEmitter, so that calls can be chained.
Start a QR code verification by providing a scanned QR code for this verification flow.
Validates the QR code, and if it is ok, sends an m.key.verification.start event with method set to
m.reciprocate.v1, to tell the other side the scan was successful.
See also VerificationRequest#startVerification which can be used to start other verification methods.
the decoded QR code.
A verifier; call .verify() on it to wait for the other side to complete the verification flow.
Send an m.key.verification.start event to start verification via a particular method.
This is normally used when starting a verification via emojis (ie, method is set to m.sas.v1).
the name of the verification method to use.
The verifier which will do the actual verification.
Can be used to listen for state changes until the callback returns true.
callback to evaluate whether the request is in the desired state. Takes the request as an argument.
that resolves once the callback returns true
StaticvalidateStateless validation logic not specific to the channel. Invoked by the same static method in either channel.
the "symbolic" event type, as returned by the getEventType function on the channel.
the event to validate. Don't call getType() on it but use the type parameter instead.
the client to get the current user and device id from
whether the event is valid and should be passed to handleEvent
State machine for verification requests. Things that differ based on what channel is used to send and receive verification events are put in
InRoomChannelorToDeviceChannel.Deprecated
Avoid direct references: instead prefer Crypto.VerificationRequest.