Vault Manager v0.7.6

Vault Manager v0.7.6

Self-hosting your node's networking now has the two steps it always needed — and the toggle finally
tells the truth about which one is on. You can self-host your node's discovery (no name, no
certificate) or go all the way to discovery and relay behind your own certificate (one DNS name,
one open port). And the local-file "Upgrade version…" button no longer risks wedging an older node by
re-pushing bytes it already runs.

Self-hosting: a real two-step control, honest about what's actually in effect

vault-node's newest release (v0.2.5-rc.7) added a way for your node to run its own relay behind a real
certificate — the last step that removes every third party from your family's path. Vault Manager
could not drive it, because the toggle had nowhere to type the DNS name a certificate is issued for.
Now it does:

• Self-host discovery — your node runs its own peer directory. Needs no name and no certificate;
  the relay hop stays the public one (a self-signed relay would refuse every app that connects, so this
  step deliberately stops short of it).
• Self-host with a certificate — your node runs its own directory and its own relay behind its
  certificate. This reveals a field for your node's DNS name, checked as you type against the exact
  rule the node applies — a mistyped name, an IP address, or a private-network name that no certificate
  authority will ever issue for is caught here, before anything is sent, with a sentence about the
  name instead of a bare error from the node.

The status line was lying, and this is why

The old toggle confirmed self-hosting by watching one flag (self_hosted) that means both hops are
your node's own. But a discovery-only node keeps the public relay by design — so that flag stayed
off on a node where self-hosting was working perfectly, and the toggle timed out as "unconfirmed" while
the status line went on calling a self-hosting node "public". Vault Manager now reads the node's actual
mode from the fields that carry it, decided in one place (Rust, unit-tested), and each change is
confirmed by the hop that mode changes — so turning on discovery is confirmed by discovery coming up,
not by a relay flag it never sets.

Everything the earlier toggle got right is kept: it names the current mode, locks the button that
matches it (so the only live action is a change), holds a distinct "applying…" state so a second press
cannot silently re-send, confirms from the node's own report rather than the 202, and warns — the whole
time self-hosting is on — that other devices may stop seeing new files until they, too, are updated to
route through this node.

Turning self-hosting on end-to-end still needs a node reachable from the outside (a public address or
forwarded port), and the certificate step additionally needs the node's name to point at it with port
443 open — it can never be issued behind CGNAT. The status line says which is actually in effect, so
"I turned it on and nothing happened" always names its cause.

"Upgrade version…" no longer re-pushes bytes your node already runs

Picking a local .happ that is byte-for-byte the version already installed used to send it anyway.
On a node older than vault-node v0.2.5-rc.7 that ran a real uninstall-and-reinstall for no change —
the exact operation that wedged a node's conductor twice before. Vault Manager now hashes the file
first and, if a healthy app is already running those exact bytes, says so and sends nothing. (A
broken or not-installed app is left alone — reinstalling the same bytes is the repair there, so that
push still goes through; and "Reinstall" is still the way to deliberately reinstall an app as it is.)

Verification

• 238 unit tests (16 new), covering: a discovery-only node reads as direct, not public (the
  exact defect); each mode settles on the field it changes; the DNS-name check mirrors the node's own
  rule and warns on names no certificate authority will issue for; a pasted https://…/ URL reduces to
  the bare name the node wants; and the local-file same-sha skip fires on identical bytes for a healthy
  app while still letting a broken app be repaired.
• The DNS-name check and the mode/confirmation logic live in Rust as the single source of truth; the
  page renders the verdict rather than re-deriving one, which is what let the two drift in the first
  place.
• The three JS guards for the self-hosting toggle were updated to pin the new correct behaviour
  (confirm from the node's own mode via the per-mode settle, not a single flag).
• Live-driven on the built binary: the release vault-manager.exe was launched and driven to the
  self-hosting panel — the two-step control renders (discovery + certificate), the certificate button
  reveals its DNS-name field, and the domain check answered live (a good name accepted, an IP address
  and a .local name refused with a sentence about the name), all against no node.

The end-to-end certificate turn-on against a live node is Mark's cert once his node has a DNS name and
inbound 443 — it needs hardware this build cannot stand up. The client half (the control, the domain
check, the honest confirmation) is complete and tested.

Downloads

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

NSIS setup.exe  sha256  97ed39462d10ce2accee2d76e46c0a8a5489f21bbcd2fd3d6ed86254d6fb0416
MSI             sha256  49bf70840f5dcba5ee19a476a299cdc1ee9e1741c7de6cfb354a6f4c573cf00b