Vault Manager v0.7.7

Vault Manager v0.7.7

You can now name the devices asking to join a space, so you can tell which is which. When two
devices are waiting for you to approve them, the node often labels them identically (or not at all) —
so approving the right one meant comparing raw keys. Now you give each one your own name once, and it
shows under that name every time it appears.

Name a device on the space-join screen

Every device waiting to join a space gets a "Name this device" button (it reads "Rename" once
you've named it). Click it, type something you'll recognise — "Mark's phone" — and Save.

• The name shows in place of whatever the node called the device, with the device's full key still
  underneath for the character-by-character check, and the name the device gave itself kept faintly
  beside yours.
• It follows the device — the same device shows the same name across refreshes and across every
  space it asks to join.
• It is kept on this computer only. Naming a device changes nothing about the device and does not
  grant it any access — the node has no way to set these labels, so this is Vault Manager's own note
  to you. (It deliberately does not follow a re-paste: re-opening an invite makes a brand-new key, and
  Vault Manager never pretends two keys are the same device — the same reason it warns you about
  superseded requests.)

Verification

• 242 unit tests (4 new): the name renders by agent key; it follows one key across spaces but a
  different key (a re-paste) carries no name; an empty key is never named; and the name is trimmed,
  bounded to 60 characters, and cleared by a blank.
• The naming, keying and normalisation live in Rust as the single source of truth; the screen renders
  the result, and the invoke-args guard confirms the page and the command agree.
• Live-driven on the built binary: the release vault-manager.exe was launched and the naming
  command exercised against the real local store — a name is trimmed and persisted under the device's
  key, a blank clears it, a long name is capped at 60, and a keyless request is refused with a reason.
  7/7, against no node.

The one thing still owed is the button-click-through against a real pending join request, which needs
a device actually asking to join one of your spaces — the same live cert as the screen's other actions.
The naming itself is complete and tested.

Downloads

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

NSIS setup.exe  sha256  fd6b8e2d311e208c223c6b61236db9386a84ef1031a269203e6040c6bd61f1e3
MSI             sha256  f18dc2ac80d064126f8e015c9de7948c8fd25fef942e7cdf606e04f0761ea327

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

Vault Manager v0.7.5

Vault Manager v0.7.5

Owner-signed hApp updates: a computer that owns your node can push an app update without a pairing
code. If you owned your node from this computer and tried to update an app, the push could fail with
"owner pairing required: enter the code shown on the node's screen" — a screen a headless node does
not have. That dead end is gone.

What was wrong

Uploading a new app version to your node (POST /happ) insisted on a pairing secret first — a
credential the node only hands to a computer with an active management pairing. A computer that
genuinely owns the node but had no live pairing (for example, one that redeemed an owner code after
its saved credentials were lost) could sign a request with its own key, but Vault Manager stopped
before sending it, because it could not first mint that secret. The node's stock refusal then told
the owner to read a code off the node's console — which, on the headless boxes these nodes usually
run on, does not exist.

Mark ruled it plainly (2026-08-22/23): any computer that holds owner on a node may push app updates
— the same standing as re-enrolling the app, and no pairing ceremony required.

The fix

Vault Manager already signs every upload with this computer's key. It now sends that signed request
even when it cannot mint a pairing secret, so a computer that owns the node is no longer stopped
before it can try:

• The pairing secret is now best-effort. It rides along when the node gives us one (older nodes still
  gate on it), but its absence no longer aborts an owner-signed push.
• Every push carries the signed challenge unconditionally — the exact shape the node already accepts
  for reinstalls. A node that honours owner-signed pushes accepts it on the signature alone.
• Nothing changes for a fully-paired computer: it still sends the secret and the owner token
  alongside the signature, exactly as before.

And the error, when a push is refused, no longer sends a headless-node owner hunting for a console
code. On the update path it now says the truth: this refusal means the node's own software predates
owner-signed pushes — update the node's software (Manage node → "Update the node software") and try
again. Nothing to type, nothing to read off a screen the node does not have.

This is the client half of a two-part fix. The matching node change (vault-node, which makes
POST /happ accept an owner-signed request and rewrites the same refusal at its source) is committed
in that project; the end-to-end push against a live node is verified once both halves are on the same
node.

Verification

• 222 unit tests, including the two new ones for this fix: the update-path refusal is turned into
  "update the node's software" and never into a console-code instruction, and an unrecognised error is
  passed through untouched. The explainer guard was checked by asserting the old dead-end wording can
  never reappear (no pair_code, no cat …, and the screen the stock error names is explicitly
  denied).
• The client's signing convention was confirmed against the node's own committed contract, not
  assumed: the node accepts a §4 signed challenge at manage scope signed over the .happ bytes, same
  auth as /happ/reinstall — which is exactly what this build sends.
• Clean-room launch cert: the published installer, downloaded anonymously, was installed and
  launched inside a fresh Windows Sandbox (a pristine Windows 11 VM with no build tools) — the app
  rendered its full UI, not a blank window. This is the launch that a machine which can build the app
  can never honestly perform for a customer.

The fully paired update path is byte-for-byte unchanged; only a computer that could sign but not mint a
pairing secret behaves differently — and it went from "stopped before it tried" to "sends an
owner-signed push", which is strictly better.

Downloads

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

NSIS setup.exe  sha256  75ab43df8c268683c7f11f169ef3028ad68367cba569e7c6a435e1b8de22ff30
MSI             sha256  2ff9b51e2f3fac49659d5223c4ac4bcac50d6ac68b20ab9273bf810ae3867a53

Vault Manager v0.7.4

Vault Manager v0.7.4

"Become the owner" now appears when you actually need it. If a node already has an owner and this
computer is not one of them, the box for redeeming an owner code was hidden — which is precisely the
situation it exists for.

What was wrong

Vault Manager decided whether to show that box by asking does this node have an owner? — when the
question it meant was does this computer hold owner on it? Those are different, and the difference
hid the control on every node that already had an owner.

That made the app's own instructions impossible to follow. When you create an owner code for a second
computer, Vault Manager tells you: "On the other device, open 'Become the owner' and paste this code
there." That other computer would ask the node, be told it already has an owner, and hide the very
panel it had just been sent to.

So there was no way through the app to:

• add a second computer as an owner of your node, or
• get back in on a computer whose credentials were lost, using an owner code.

The fix

The panel now appears whenever the node is claimed and this computer is not already an owner of
it — including on a computer that holds no record of the node at all, which is the case that surfaced
this.

The wording changed with it. Telling someone their node "has no owner yet" when it plainly has one
reads as a fault and teaches people to distrust the screen. When the node does have an owner, it now
says so and names the two real ways forward: an owner code created on a computer that is an owner,
or your recovery key.

If you have lost every owner device

That case does not need an owner code and never did — use "Lost access to a node you own?" under
Identity & ownership with your recovery key. It has always been there, but it sits inside a
collapsed section, which is easy to walk past.

Verification

220 unit tests, the call-site, page-structure and TLS guards, and three walkthroughs driven
against the built application — a first-run walk, a full run through a damaged profile, and a new one
for this fix, driven against a real node that genuinely reports having an owner, because a stand-in
would have agreed with the old behaviour.

The guard for this fix was checked by deliberately reintroducing the fault five ways — including
putting the wrong question back one line further up, where the first version of the test could not
see it. All five were caught.

Also added: the release process now refuses to publish a version number that already exists with
different contents, so one version can never mean two different programs.

Downloads

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

NSIS setup.exe  sha256  fe14ee25d1363f663f75a3604bdaa8ab63b61002111e3280e2b72fddba42f5bf
MSI             sha256  86f907416df5b02bf7cfcc556c8f55b152f67d331b881450751d27a42c268adf

⚠ Compare hashes, not sizes.

Vault Manager v0.7.3

Vault Manager v0.7.3

If your saved list of nodes ever goes missing, Vault Manager now says so instead of quietly
welcoming you as a new user. Until this release, a node list that had vanished looked exactly like
a computer that had never set one up — the same cheerful "add your first node" screen, with nothing
to suggest anything had been lost.

Who this affects

Nobody's node, and nobody's data. This is about Vault Manager's own record — the small file on your
computer that remembers which nodes you have paired with and holds the credential for them. Your
node keeps running exactly as before, and nothing on it is touched.

If your list is intact, this release changes nothing you will see.

What was wrong

Vault Manager already knew the difference between "I cannot read your saved list" (which it reports
loudly, and refuses to write over) and "you have no nodes". What it could not tell apart were the
two very different reasons a list can simply not be there:

• nobody has set this computer up yet — completely normal; and
• there were nodes here, and the file holding them is gone.

Both drew the same first-run screen. So a real loss could sit there unremarked, and the one moment
when something might still be recoverable would pass without anyone being told to look.

This was found on a real machine: a list holding two paired nodes on one day, and on another day no
list and no backup — with the app happily offering to set up a first node.

The fix

Vault Manager now leaves a small marker outside the list file, recording only how many nodes
this computer has ever had saved, and when that was last true. Evidence kept inside the thing that
went missing is not evidence, which is why it lives somewhere else.

If the list is then gone but the marker says nodes were once there, you get a plain statement of what
is known: how many there were, when they were last confirmed, whether the backup copy is gone too —
and, said outright, that Vault Manager did not delete it and cannot tell you what did. It also
points at the way back: pairing this computer with your node again using an owner code.

The marker holds no node address, no fingerprint and no credential — only a count and a date.
Anything more would be a second copy of the very file we are trying to protect.

It stays quiet unless it is sure

A warning that cries wolf is worse than none, so this one says nothing at all unless it can prove the
claim. A list that loads — even an empty one, because removing your last node is a normal thing to do
— is not a loss. A list that cannot be read keeps its own existing, louder message and its backup,
rather than being reported twice in two different ways. And if there is no marker, Vault Manager
simply does not know, which is not the same as knowing nothing was there, so it stays silent.

⚠ It cannot see backwards. The marker starts recording the first time your list is saved after
you install this version, so it has nothing to say about a list that went missing before then —
including the one that prompted this release.

You will see it without going looking for it

The warning itself lives on the Set up & manage a node tab, which is not the tab Vault Manager
opens on — and the whole point of the message is that you have no particular reason to go there,
since every other screen agrees you have no nodes. So while the warning stands, that tab is marked
on the very first screen, with a ⚠ in its label rather than a colour alone. The mark clears itself
once the warning no longer applies.

Also in this release

A sentence in the existing damaged-list warning used to read "there is no backup file … so nothing
has been saved on this computer yet" — the same mistake in miniature, guessing a first run from an
absence. It now gives both possible readings and admits that screen cannot tell which is true.

Verification

219 unit tests (three new), plus the call-site, page-structure and TLS guards, and two
walkthroughs driven against the built application: a first-run setup walk, and a full run through the
damaged state itself — because you cannot check a repair on a healthy machine, so the test creates
the damage first.

Every new guard was checked by deliberately breaking the thing it protects and confirming it
complains: shipping the warning switched on, letting the page guess instead of asking, letting an
ordinary save erase the marker, making it fire when it cannot actually tell, slipping a node's
address into the marker, leaving the first-screen mark stuck on for ever, and reducing that mark to a
colour. Eight for eight.

This release also adds a pre-publish check that reads the finished program's own dependency table and
refuses to publish it if it was built against a developer-only runtime — a fault that makes an
application fail to start on a computer without developer tools installed, while looking perfectly
fine on the machine it was built on. v0.7.2 and this release were both checked and are clean.

Downloads

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

NSIS setup.exe  sha256  fa5da2638d59d6c1b740a5f1a109a930ed015b883e3e5741fd1adf9d3d082edf
MSI             sha256  096928822ec86f4d3ce198292babf509f937089d1fe0bd2376b47d306c92667c

⚠ Compare hashes, not sizes.

Vault Manager v0.7.2

Vault Manager v0.7.2

A long space hash no longer pushes the enrolments table off the panel. In v0.7.1 the "Apps
and spaces enrolled" list came back (it used to blank on a messenger enrolment) — but an enrolment
whose space is shown as its full 52-character hash made that row too wide, so the App column and its
Rename button spilled off the right edge of the panel. This release keeps every row inside its panel.

What was wrong

A space hash like uhCkkt-8kNZY10dzgV_wPYWGhB3rowSxs82DJf_-un8amVHlRvDj9 only has "break points" at
its hyphens — the underscores aren't ones — so the browser couldn't wrap the long middle run, and
the whole table grew wider than the panel to fit it.

The fix

The enrolled-apps table (and the other node tables that can carry a long key or hash) now wrap long
values anywhere they need to, so the text folds neatly inside its column and the table stays
within the panel — while the Rename/Revoke buttons keep sitting on one line. Measured contained at
every window width from wide down to narrow.

Verification

216 unit tests (one new — a_long_space_hash_wraps_in_place_and_never_overflows_the_devices_table
— which pins the wrap rule and that the action button stays on one line), plus the call-site,
page-structure and TLS guards. The fix was measured against the shipped app shell and its real
stylesheet (and the bundled monospace font): 0 pixels of overflow from 720px down to 340px, where
before it spilled 70–290px.

Downloads

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

NSIS setup.exe  sha256  059393789168661991c8a002646a9d83cfb910d22ecf800f51d93cede4f68a38
MSI             sha256  3c29d9d9e63524b820ab85edf53270bb9241038841725ce3902407cc86f0dc79

⚠ Compare hashes, not sizes.

Vault Manager v0.7.1

Vault Manager v0.7.1

The "Apps and spaces enrolled" list no longer disappears when a messenger connects. Mark hit
this live on 2026-08-18: the moment a Parley device enrolled on his node, the whole enrolled-apps
section went blank with an error — hiding the VaultDrive and ReelVault rows that had been showing
fine a second earlier. This release fixes that, and carries forward the space-rename polish from
v0.7.0.

What was wrong

A Parley device is a messenger — it has no VaultDrive storage space — so the node correctly reports
that enrolment with an empty (null) space. Vault Manager was reading the enrolled-members list in
one all-or-nothing pass that demanded a value for every field, so a single null field on one
enrolment failed the read for the entire list. One messenger took every other app off the screen.

The fix

• A missing or empty field is now a "—", never a crash. Each enrolment field tolerates the node
  reporting nothing for it.
• The list is read one row at a time, so an enrolment shaped in a way Vault Manager didn't expect
  can only ever affect its own row — it can never hide the others again. A row it genuinely can't read
  is shown as a placeholder rather than silently dropped.
• A messenger enrolment with no space now reads "—" in the Space column, instead of a blank cell.

Also in this release

The space-Rename control from v0.7.0 (rename a space your node owns; it waits for the node to
actually apply the change, and your access never changes because grants ride the space's permanent
identity). Nothing about that changed — it's carried forward.

Verification

215 unit tests (one new — a_null_field_on_one_enrolment_never_blanks_the_whole_list — which
pins that a null-heavy messenger row leaves a well-formed row completely intact), plus the
call-site, page-structure and TLS guards. The shipped binary was launched and driven over its own
debug bridge to confirm the enrolled-members command is wired and answers safely.

Seeing the full list render with a real Parley device enrolled is a live check at the keyboard — the
node has to have a messenger enrolled to produce the null the fix is about — and the parsing logic
itself is covered by the unit test above.

Downloads

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

NSIS setup.exe  sha256  b8be652f3e91827ffba82e4fc187c7326196074ef7aec1323d6bd0aadd1971d0
MSI             sha256  51a2ee0a2cac8945cd6945409880ea5706e9a9ed12e0e44b5c51d2b9a6ad0c79

⚠ Compare hashes, not sizes.

Vault Manager v0.7.0

Vault Manager v0.7.0

You can rename a space your node owns. Until now there was no way to do it from anywhere — Vault
Manager didn't offer it, and VaultDrive is deliberately read-only about someone else's space — so a
space kept whatever name it was first given. This release adds a Rename control to each space on
the node's Spaces panel.

Rename a space your node owns

On the Spaces panel, every space your node authored now has a Rename button. Click it, type
the new name, press Save (or Enter). That's it.

Two things make it trustworthy rather than a name that silently doesn't stick:

• It waits for your node to actually apply the change before it settles. The node accepts a
  rename and then applies it — the new name shows up on the node's own space list within about a
  minute, and on your other devices once it syncs to them. Vault Manager watches the node's own list
  and only reports "renamed" once the node itself shows the new name, never on the strength of the
  request being accepted. If a minute passes without the name changing, it says exactly that and
  keeps your typed text in place, rather than looking like it worked when it didn't.
• Your access doesn't change. Renaming touches only the name. Everything that grants access — the
  people and devices you've shared the space with, its storage pin, its enrolment — is keyed to the
  space's permanent identity, which a rename never moves. So a rename can't quietly lock anyone out.

This needs a current node (Vault Node v0.2.4-rc.3 or newer, where the node learned to rename a
space it owns). On an older node the Rename control is shown disabled, with the reason — never
hidden — and it lights up on its own once the node updates itself; there's nothing to install in
Vault Manager.

What it touches

Only the space's name, and only for a space your node authored (a member device still can't edit
someone else's space — that's correct, and unchanged). It changes none of your files and none of
your grants.

Verification

214 unit tests (four new), plus the call-site, page-structure and TLS guards. The rename control
is pinned by a structural guard that requires it to confirm the applied name from the node's own
space list rather than trusting the node's acceptance reply (the same rule the self-hosting toggle
keeps). The Rust side is unit-tested: it reads the node's acceptance versus a refusal-inside-a-2xx,
names each refusal cause honestly (an older node, no conductor, the wrong scope), and gates the
control on the release that added renaming.

The rename endpoint is live on the current Vault Node release, so the control reaches a real route
on an up-to-date node. Driving the full round-trip end to end — rename in Vault Manager, watch the new
name appear in VaultDrive and VaultDocs — is a live check at the keyboard; the code path is the same
signed request the node's own route test covers.

Downloads

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

NSIS setup.exe  sha256  36f7e3f514f3278ec2a4590e8f057edd4b8b84e58dcf1a60c0f9ec67342cf19a
MSI             sha256  fce5e8effff170ca83fb07b28fcb4c87c80c1340d4936529e71bfd7d799ad0d4

⚠ Compare hashes, not sizes.

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.

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.