Vault Manager v0.6.9

Vault Manager v0.6.9

Two node controls that finally tell you the truth, plus an honest correction to a number. After a
reboot your node's apps take a while to come back — now there's a button to try to hurry them, the
screens say how long the wait really is, and the "self-host your networking" toggle stops being a
mystery button.

"Re-host apps now" — the button to skip the post-reboot wait

When a node reboots, the apps it hosts come back on their own — but on today's nodes that has been
measured at up to about 45 minutes (a vault-node bug, still being fixed, where the conductor
waits on a network timeout before starting apps). That's a long time to stare at "not hosting any
apps".

The new Re-host apps now button (on the managed-node panel, under Reboot) asks the node to bring
its apps back immediately, instead of waiting out the window.

⚠ And it's honest about its limits: on a node that's still mid-recovery, the node can accept the
request and still not start the apps until its own internal gate opens — so the button never claims
success from the node's acknowledgement. It reads the apps' real state back and shows you that:
"Coming back…", "installed but not running", or "working". A node older than the release that added
this (vault-node rc.9) says so plainly instead of doing nothing.

The reboot-recovery wait now says the real number

v0.6.7 told you to expect "up to ~20 minutes" after a reboot. Field measurement across four boots put
it at ~40–46 minutes on current nodes, so the reboot confirmation and the recovery messages now
say up to about 45 minutes — the honest upper bound — and point you at the Re-host button. (When
the underlying node bug is fixed and recovery is fast again, these screens read the node's live state,
so they'll reflect that.)

"Self-host this node's networking" is a real toggle now

The self-hosting control was a stateless mystery button: two look-alike buttons, no visible on/off
state, no acknowledgement when pressed, and — worst — it could show "✅ self-hosting" and "being
enabled…" at the same time while you were trying to turn it off. Pressing it repeatedly silently
re-sent the same request.

Now it's an explicit two-state toggle:

• It names the current state — "Currently: ✅ self-hosting" or "Currently: 🌐 public networking" —
  read from the node's own report.
• It locks the button that matches the current state, so the only action is the other state —
  no more accidentally re-sending "turn on" when it's already on.
• Pressing it shows a distinct "applying…" state that holds until the node confirms the change
  in its own state (polled), so a second press can't stack another request, and success is only
  ever shown once the node actually did it — never from the acknowledgement alone.

What it does and doesn't touch

The Re-host button and the self-hosting toggle both ask the node to do something and then report
what the node itself says happened — they read and render node state, and change no data. The
recovery-time text is copy only.

Verification

201 unit tests (two new): that the Re-host button is wired to the node's re-host route and reads
happs[].state back rather than trusting the acknowledgement; that the self-hosting control names the
current state, locks the matching button, holds a pending state, and confirms from the node's own
self_hosted (polled) — the placebo-control class this app refuses on principle. The reboot-lag guard
was updated to the ~45-minute measured figure and to forbid a regression to "seconds" or "~20 min".

⚠ Not verified against a live node in these exact states — a node mid-recovery, or the toggle
bringing a relay up/down — reproducing those needs the node held in that condition, and workers do
not drive the production node autonomously. The wiring and the honesty rules are unit-tested and
pinned in the source; the node-side routes (POST /rehost, POST /owner/reachability) are the ones
vault-node published and confirmed.

Downloads

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

NSIS setup.exe  sha256  9535c5dd5748960b07dab15658a772af1d483f8bed08be492b9e1aedeea3a35d
MSI             sha256  301f0fc4393f8dabec04d508a10a8fd91b68aae6ed68ed3895c9cf80e6f509bb

⚠ Compare hashes, not sizes.