The selfie / identity-verification wizard of the UFAC flow: Instagram asks the
person to record a short video selfie and, when the flow requires it, to
upload an identity-verification photo, then the client long-polls until the
server accepts or rejects. The screen keeps the UFAC state accumulated so far;
its requests derive their parameters from it, exactly as the legacy screen
did.
Reached only as an interruption of a request (OpenChallenge(error)): the
challenge's classification fetched the UFAC controller before this screen
opened, so its enter sends nothing. It has no back and is no step of a
trail.
Its actions:
startVideoSelfie() fires the IXT trigger the app sends when the person
taps "Start video selfie", and continues into the payload the answer is —
the same wizard with fresh state, or the next UFAC step.
uploadIdentityVerificationPhoto(image) uploads the captured image (a
base64 string or raw bytes) to the wizard's identity-verification action,
unchanged, and continues into the answer's step.
checkReviewStatus() is one tick of the review poll. While the wizard is still active
it answers { status: 'still-waiting' } and leaves this screen on top; the
caller decides the pace, exactly as the two-factor checkApproval() asks.
Once the answer is no longer the wizard, it continues into that step.
A missing piece of the accumulated state is the existing typed
UfacAuthenticityWizardMissingStateError, and a payload the library does not
model is ChallengeStepNotModelledError. Every action runs only while this
screen is on top; the interrupted action is never retried.
Ships without a screenshot: the old class had none.
Unverified by recording. No recording of the Android 451 app on this step
exists, and the challenge module has no sample of this step in the library's
own sources. A recording of the Android app on the wizard would settle the
trigger, the upload and the poll's cadence.
The selfie / identity-verification wizard of the UFAC flow: Instagram asks the person to record a short video selfie and, when the flow requires it, to upload an identity-verification photo, then the client long-polls until the server accepts or rejects. The screen keeps the UFAC state accumulated so far; its requests derive their parameters from it, exactly as the legacy screen did.
Reached only as an interruption of a request (
OpenChallenge(error)): the challenge's classification fetched the UFAC controller before this screen opened, so itsentersends nothing. It has nobackand is no step of a trail.Its actions:
startVideoSelfie()fires the IXT trigger the app sends when the person taps "Start video selfie", and continues into the payload the answer is — the same wizard with fresh state, or the next UFAC step.uploadIdentityVerificationPhoto(image)uploads the captured image (a base64 string or raw bytes) to the wizard's identity-verification action, unchanged, and continues into the answer's step.checkReviewStatus()is one tick of the review poll. While the wizard is still active it answers{ status: 'still-waiting' }and leaves this screen on top; the caller decides the pace, exactly as the two-factorcheckApproval()asks. Once the answer is no longer the wizard, it continues into that step.A missing piece of the accumulated state is the existing typed
UfacAuthenticityWizardMissingStateError, and a payload the library does not model isChallengeStepNotModelledError. Every action runs only while this screen is on top; the interrupted action is never retried.Ships without a screenshot: the old class had none.
Unverified by recording. No recording of the Android 451 app on this step exists, and the challenge module has no sample of this step in the library's own sources. A recording of the Android app on the wizard would settle the trigger, the upload and the poll's cadence.