Vault Manager v0.6.10

Vault Manager v0.6.10

The post-reboot wait is short again, an app card stops contradicting itself about its tender's
version, the self-host toggle warns you before it can hide your files, and there's a new way to add a
phone or computer to your node — a QR you scan, no code to type.

After a reboot, apps come back in about a minute now — not 45

Earlier versions warned that a node's hosted apps could take up to about 45 minutes to come back
after a reboot. That was true, and it was a vault-node bug — the conductor waited out a long network
timeout before starting the apps. That bug is fixed and measured: a reboot on a current node now
brings both apps back in about 41 seconds.

So the copy is corrected everywhere it appeared — the reboot confirmation, the "coming back" badges,
and the "installed but not running" verdict now say the honest window is about a minute or two,
not the alarming figure that no longer applies. (These screens read the node's live state, so if a
node is on older software they still reflect what it actually reports.)

An app card no longer shows two versions that disagree

An app's tender — the small companion service that runs beside it on your node — reports its version
in two places, and they could disagree by three releases: the running binary said one number while
your node's last verified install record said another. Two bare contradictory numbers side by side
told you nothing except that something looked wrong.

Now, when those two disagree, Vault Manager shows one labelled line instead —
"tender reports 0.5.7 · installed from release v0.6.2" — with a note explaining the two most likely
reasons: usually the tender simply did not move its own version label for that release (the install
was still checked against the release's checksum, so the current bytes are the ones you asked for),
and less often the update did not take, in which case re-running "Update this app's tender" and
watching this line is the thing to do. (VaultDrive's tender now stamps its version from the release it
shipped in, so from here on a match is the normal case and a mismatch is a real signal.)

Turning on self-hosting now warns you first

When you self-host your node's networking, the node moves to its own bootstrap and relay — but your
other devices don't yet switch over to route through it, so until they're updated a file saved on
the node can stop showing up on them. The self-host toggle now says this, both where it shows the
current state and at the moment you turn it on: if a phone or second computer is missing recent
changes, switch back to public networking to reunite them.

Add a device to your node — scan a QR, no code to type

There's a new "Add a device to this node" panel. It connects a new phone or computer to your node
at app access — it can use your node, never manage or reset it — so you don't need your recovery
key for this.

• Show a pairing QR (the main way): your node makes a one-time QR; scan it on the new device and
  it connects straight away, nothing to type.
• A waiting-list for when a device can't scan — no camera, or it isn't with you: it asks to pair
  from a distance and shows a short code, and you approve the row whose code matches.

⚠ This needs a newer node than the current release, and it says so. The node side of device
pairing is the next Vault Node release; until your node has it, every control in this panel answers
honestly that "device pairing arrives in a later Vault Node release — update the node's software"
rather than looking broken. When the node ships it, the panel starts working with no update to Vault
Manager needed.

What it does and doesn't touch

The version line is display only. The self-host warning is copy only. The pairing panel asks the node
to make an invite or admit a device and reports what the node says — it changes no data of yours, and
a paired device is only ever given plain app access, never the owner credential.

Verification

210 unit tests (nine new), plus the call-site and page-structure guards. The recovery-copy guard
now pins the honest short window and forbids a regression back to "45 minutes" / "20 minutes" /
"seconds". The tender-version mismatch is decided in Rust and unit-tested (mismatch, agreement modulo
a v prefix, no-comparison-basis, and absence). The pairing panel's wiring, its honest-404 handling,
and its list/age/fingerprint helpers are unit-tested and pinned.

⚠ Device pairing is not verified against a live node — by construction: the node's /pair/*
endpoints do not exist yet (they're vault-node's next slice), so on any current node every call
returns the honest "not yet — update the node" message. The client side is built to the posted wire
contract and lights up when the node ships it; there was nothing live to test it against this round.
The recovery-copy correction reflects vault-node's certified fix (a reboot in ~41 s on v0.2.4-rc.1).

Downloads

Published under both VaultManager-* and VaultFlasher-* names; the bytes are identical.

NSIS setup.exe  sha256  731fef1ef700b551041be20d6e3df28ba3e674b1e0f92d30ebade2dd93699c1e
MSI             sha256  e8dea695610ac51014bda5da1aac45a94cbecfba985c3d439cdbadb2683470dc

⚠ Compare hashes, not sizes.