Sign in with Quick Connect

[iderex]

The kickoff names Quick Connect. It is the route that matters most on a
television, where typing a password with a remote is the worst part of the
experience, and it is a different shape from the password route because it polls.

What this produces

Starting a Quick Connect attempt and getting back the code a person reads off the
screen.

Polling for the result, with the interval and the total time limit decided here
rather than by each client, and cancellation that actually stops the polling.

The three endings handled distinctly: approved, denied, and expired without an
answer. A client shows three different things.

What happens when the server does not offer Quick Connect at all, which follows
the missing-endpoint rule from #10.

Done when

All three endings are covered by tests against the fake server, the poll stops on
cancellation, and a server that does not offer the feature produces the named
answer from #10 rather than a hang. Blocked on #5, #10, #21.

[iderex]

One of the two numbers this issue says it will decide is refused by a landed
record, and by a second one that cites the first, so it is worth knowing before
somebody picks a value for it. Read at
da7d6c3f19c2c36dab1680ebd38ed48755cd3a1b.

What the body promises:

gh issue view 31 --json body --jq '.body' | tr '\n' ' ' | tr -s ' ' | grep -o 'Polling for the result[^.]*\.'
Polling for the result, with the interval and the total time limit decided here rather than by each client, and cancellation that actually stops the polling.

docs/decisions/0005-the-session-model.md places this route's wait outside what
the core bounds:

sed -n '87,92p' docs/decisions/0005-the-session-model.md
Quick Connect, in #31. The core asks the server to begin an exchange, receives a
short code for the client to show, and then waits for the server to say the
exchange was approved elsewhere. The core never sees a credential on this route.
What it must handle that the first route does not: a wait with no upper bound
imposed by the core, a code that expires, an exchange a person abandons, and the
fact that the person approving is doing so somewhere the client cannot see.

docs/decisions/0032-a-server-that-delegates-sign-in.md takes the same answer
for its own route and says where it came from:

sed -n '89,95p' docs/decisions/0032-a-server-that-delegates-sign-in.md
caller cancels it, or when the core stops under 0115, and it ends in exactly one
of those. There is no separate expiry and no number here for how long a person
may take, which is 0005's treatment of the wait in #31 arriving unchanged: a
person authenticating somewhere else is doing something the core cannot see and
has no business timing. The set of open attempts is therefore bounded by the
calls the caller is holding rather than by a rule of the core's, which is the
same bound every other outstanding call in the core has.

and it prices the alternative in the same terms, naming this issue:

sed -n '215,219p' docs/decisions/0032-a-server-that-delegates-sign-in.md
An expiry on an attempt, so that the set of open attempts cannot grow. It bounds
something and it sounds careful. The number would be invented rather than
measured, it is a number about how long a person takes at somebody else's
website, and 0005 already refuses the same number for #31 for the same reason. An
attempt tied to the caller's call is bounded by something the caller already

So a total time limit set here is a supersession of 0005 rather than a number
this issue is free to choose, and taking one would put the core in the position
of ending an exchange a person is part way through at somebody else's screen.

What is left of that bullet is not empty. The poll interval is undecided and no
landed record fixes one, so it is still this issue's. Cancellation stopping the
polling is still this issue's. What ends a wait without either of those is the
code expiring, which is the server's own limit and is already the third of the
three endings this issue lists, so the ending a total limit was reaching for is
covered by something the server states rather than something the core invents.

I have changed no condition. The three conditions here are untouched, and they
are statements about running code: all three endings covered by tests against the
fake server, the poll stopping on cancellation, and a server that does not offer
the feature producing the named answer rather than a hang. There is no language
chosen, no build and no test command in this tree, and #21 is open.

[iderex]

The rule this issue owes docs/decisions/ landed as
docs/decisions/0031-the-quick-connect-route.md, on
7c41f7e. The bullet the comment above split in
two was taken in opposite directions, and this says which way each half went
rather than leaving it to be read off the diff.

The poll interval is decided and is the core's: five seconds between one
question and the next, measured on the steady clock 0102 fixes, fixed rather
than doubling and not drawn from a range.

git show 7c41f7e7f084c140878ec64694dc2e249c478a51:docs/decisions/0031-the-quick-connect-route.md | sed -n '74,76p'
Five seconds between one question and the next, measured on the steady clock 0102
fixes for an interval inside one run. Fixed, not doubling, and not drawn from a
range.

The number is chosen and not measured, and the record says so in its own text
instead of implying a run behind it. What would replace it with a measured one
is a supported server line refusing polls at that cadence, read off the
diagnostic events in #100.

The total limit is not taken, for the reason the comment above gives, and the
record states the cost of not taking it rather than leaving it implied: where
the server is gone for good, the core cannot learn that the code expired,
because the only party who knows is not answering, so the call sits polling
until the caller ends it.

The three endings this issue asks a client to show are three without the
vocabulary growing. Denied and expired are answers on the call rather than kinds
in 0004, and the record prices both alternatives it refused: two more kinds is
a sixteenth and a seventeenth for conditions that are not failures, and one
shared kind would leave a client unable to tell them apart.

What is not answered here is which requests carry any of this. That needs the
server surface enumerated, #10 is open, and the record names none. The
capability-absent answer for a server that does not offer the route is stated
against #10's capability set, and the record carries the reversal for the case
where #10 turns out to say that the route cannot be read as offered before an
exchange is started.

The three conditions above are untouched, and each is a statement about running
code.