the matrix client, to send messages with and get current user & device from.
id of the room where verification events should be posted in, should be a DM with the given user.
Optional userId: stringid of user that the verification request is directed at, should be present in the room.
Private Readonly clientthe matrix client, to send messages with and get current user & device from.
Private Optional requestReadonly roomid of the room where verification events should be posted in, should be a DM with the given user.
Optional userid of user that the verification request is directed at, should be present in the room.
The transaction id generated/used by this verification channel
Add all the fields to content needed for sending it over this channel. This is public so verification methods (SAS uses this) can get the exact content that will be sent independent of the used channel, as they need to calculate the hash of it.
the complete content, as it will be sent.
the event type
the (incomplete) content
Adds the transaction id (relation) back to a received event
so it has the same format as returned by completeContent before sending.
The relation can not appear on the event content because of encryption,
relations are excluded from encryption.
the content object with the relation added again
the received event
the timestamp when the event was sent
the event to get the timestamp of
Changes the state of the channel, request, and verifier in response to a key verification event.
a promise that resolves when any requests as an answer to the passed-in event are sent.
to handle
the request to forward handling to
whether this is an even received through sync or not
Send an event over the channel with the content not having gone through completeContent.
the promise of the request
the event type
the (incomplete) content
Static canStatic getAs m.key.verification.request events are as m.room.message events with the InRoomChannel to have a fallback message in non-supporting clients, we map the real event type to the symbolic one to keep things in unison with ToDeviceChannel
the "symbolic" event type
the event to get the type of
Static getStatic getExtract the transaction id used by a given key verification event, if any
the transaction id
the event
Static validateChecks whether this event is a well-formed key verification event.
This only does checks that don't rely on the current state of a potentially already channel
so we can prevent channels being created by invalid events.
handleEvent can do more checks and choose to ignore invalid events.
whether the event is valid and should be passed to handleEvent
the event to validate
the client to get the current user and device id from
Generated using TypeDoc
A key verification channel that sends verification events in the timeline of a room. Uses the event id of the initial m.key.verification.request event as a transaction id.