The 14-to-15 state migration was released in urbit-os-v2.142
so we add a new ames-state-16 to account for the removal of
.num-live from $pump-metrics.
This also adds several `$+` shorthand type name for better
prettyprinting in nest-fails situations, all related to the types in
$ames-state.
(note: ames states 14 and 15 are the same, ane tha migration
just re-retrieved our own %rift—first introduced in state-12-to-13)
The %kroc task was introduced in ames-state-10. The way the
migration works, is that queued-events are transformed right
away into the latests version, and the state is done step-wise in
different arms, but in one go as part of the +molt arm.
This means that all states from %10 need to handle cleaning up
the %kroc task, with the addition that we were already handling
another tasks, %snub, from ames-state-9 until ames-state-11.
This means that we need to handle both tasks in two different
ames-states, and from them only the %kroc task.
This also adds several $+ to the ames types, that make nest-failures
easier to read.
The fact that the target bone of a flow that we have received is a
naxplanation doesn't guarantee that there will be a naxplanation
flow (i.e. we have actually sent one) so instead of crashing, we just
continue processing the next bone.
Instead of doing formal network traffic on the host-side whenever a
login attempt gets initiated, we now do it no earlier than when we're on
the client-side. This has the important property that network traffic
can only be initiated by authenticated HTTP requests. The previous
implementation, where hosts sent pleas when an unauthenticated HTTP
client said then wanted to log in, was vulnerable to abuse.
So now, formally, the eauth flow starts at the client's confirmation
screen. There is an optional step preceding this, where an attempt is
started on the host (and data is still stored for this), but to get the
redirect target, the host uses remote scry to get the eauth URL out of
the client ship.
Hosts now also give attempt-specific return URLs, useful in case they
are accessible (or even serving different content) from different
hostnames.
+on-kroc was cluttered with ad-hoc logic to indentify stale flows from
failed resubscriptions that were not properly %corked. Here we move
that logic to a generator that, if not in dry mode, will call %ames with a
(list [ship bone]) to %cork them.
Another option would be to move the logic in the generator to a state
update in ames, which will trigger possibly thousands of %ames messages
to be sent, on every ship that runs the state migration—these flows are
not causing a problem that neds to be addressed, and only take extra
space.
If we decide that this needs to be run by everyone, one solution could be
to set up a timer (maybe taking advantage of the fact that ships don't get
the OTA a the same time) that will eventually poke %hood with a
%helm-ames-kroc task.
