Says what this product can do with a scannable code.
Nothing is claimed until you call this, and a build that never does says
on the wire exactly what it said before codes existed here. Nothing
about a consumer's verifications changes because this library grew a
feature they do not use. Answering is a few lines and they are yours to
write, because the two claims a code makes are claims about the product:
it owns the camera, the screen and the scanner, and this library cannot
know whether you built any of them.
See CodeCapabilities for what each field means, why there are two
of them, and which of the two mistakes is the expensive one.
That is the truthful answer for most products, and it used to be
unsayable. Saying it removes a choice from the far side: told this one has
no camera, a peer cannot decide to show its own code and wait, so it scans
or the two of you compare the short string. Claiming a camera you do not
have leaves a person holding a phone in front of a square nothing will
ever read, with no error reaching either product, until the protocol's
own ten-minute timeout retires the flow.
Withholding a half does more than stay quiet
canShow: false makes a code unavailable rather than merely
unadvertised, in both directions, and that is not this library's choice: a
code exists only if the side drawing it announced showing and the side
reading it announced scanning. So with both halves off, the peer's own
client produces no code either and falls through to the short string,
exactly as it did against every earlier release.
When to call it
Before opening or answering any flow a code might be used on. What a flow
announces is fixed when that flow is created or agreed to, so calling this
afterwards changes nothing about a verification already under way. Once at
start-up, next to createCryptoMachine, is the usual place.
It applies to the whole process rather than to one flow, because it
describes the product, and a product does not have a camera on some of its
verifications and not others.
Not asynchronous, unlike almost everything else here. It sets one
process-wide value and cannot fail, and the shape is deliberate: an
awaitable call that a caller forgot to await could land after the flow it
was meant to affect had already said what it can do.
Says what this product can do with a scannable code.
Nothing is claimed until you call this, and a build that never does says on the wire exactly what it said before codes existed here. Nothing about a consumer's verifications changes because this library grew a feature they do not use. Answering is a few lines and they are yours to write, because the two claims a code makes are claims about the product: it owns the camera, the screen and the scanner, and this library cannot know whether you built any of them.
See CodeCapabilities for what each field means, why there are two of them, and which of the two mistakes is the expensive one.
A product with a screen and no scanner
That is the truthful answer for most products, and it used to be unsayable. Saying it removes a choice from the far side: told this one has no camera, a peer cannot decide to show its own code and wait, so it scans or the two of you compare the short string. Claiming a camera you do not have leaves a person holding a phone in front of a square nothing will ever read, with no error reaching either product, until the protocol's own ten-minute timeout retires the flow.
Withholding a half does more than stay quiet
canShow: falsemakes a code unavailable rather than merely unadvertised, in both directions, and that is not this library's choice: a code exists only if the side drawing it announced showing and the side reading it announced scanning. So with both halves off, the peer's own client produces no code either and falls through to the short string, exactly as it did against every earlier release.When to call it
Before opening or answering any flow a code might be used on. What a flow announces is fixed when that flow is created or agreed to, so calling this afterwards changes nothing about a verification already under way. Once at start-up, next to createCryptoMachine, is the usual place.
It applies to the whole process rather than to one flow, because it describes the product, and a product does not have a camera on some of its verifications and not others.
Not asynchronous, unlike almost everything else here. It sets one process-wide value and cannot fail, and the shape is deliberate: an awaitable call that a caller forgot to await could land after the flow it was meant to affect had already said what it can do.