The short authentication string for this flow, once there is one.
Show it to a person and ask whether it matches what the person at the
other device sees, over a channel this flow did not establish. See
SasMaterial, including why the value is secret while the flow is
open.
'material_not_ready' has two causes, and they need opposite things
done about them. Retrying this call alone fixes neither. Read
getVerificationStage to tell them apart, because doing the wrong
one waits forever:
The peer opened the comparison and you have not answered it. The
stage is 'started' and you never called
startVerificationComparison. Their start is a question; call
acceptVerification a second time, and the exchange proceeds.
This is the ordinary receiving side against a client that starts
directly, matrix-nio among them -- it is not an edge case, and
nothing you pump will move it.
You drained the pump and never called markRequestSent. The
underlying state machine advances from "accepted" to "keys exchanged"
on that report and on nothing else, so a caller that skips it parks the
flow permanently with no error and no timeout anywhere else. This call
names that state instead of resolving with an empty record or hanging.
Supplying the missing report, and nothing else, completes the exchange.
The other failure kind is worth keeping apart from both:
'wrong_stage' -- it never will: the flow is over, or no comparison was
ever started on it. A flow proceeding by a scanned code arrives here,
and it is neither over nor stuck: there is no string on such a flow and
there never will be. A product that chose codes knows which it has, so
this is not folded into a kind of its own; a product that offers both
knows which call it made.
Note that a code flow reads 'started' from getVerificationStage
until somebody scans, so before that the stage does not tell that case
apart from the two causes above; after it, 'code-scanned' does. Neither
matters here, because the kind already tells them apart: those two arrive
as 'material_not_ready' and a code flow arrives as 'wrong_stage' at
every stage it passes through.
The short authentication string for this flow, once there is one.
Show it to a person and ask whether it matches what the person at the other device sees, over a channel this flow did not establish. See SasMaterial, including why the value is secret while the flow is open.
'material_not_ready'has two causes, and they need opposite things done about them. Retrying this call alone fixes neither. Read getVerificationStage to tell them apart, because doing the wrong one waits forever:'started'and you never called startVerificationComparison. Their start is a question; call acceptVerification a second time, and the exchange proceeds. This is the ordinary receiving side against a client that starts directly,matrix-nioamong them -- it is not an edge case, and nothing you pump will move it.The other failure kind is worth keeping apart from both:
'wrong_stage'-- it never will: the flow is over, or no comparison was ever started on it. A flow proceeding by a scanned code arrives here, and it is neither over nor stuck: there is no string on such a flow and there never will be. A product that chose codes knows which it has, so this is not folded into a kind of its own; a product that offers both knows which call it made.Note that a code flow reads
'started'from getVerificationStage until somebody scans, so before that the stage does not tell that case apart from the two causes above; after it,'code-scanned'does. Neither matters here, because the kind already tells them apart: those two arrive as'material_not_ready'and a code flow arrives as'wrong_stage'at every stage it passes through.