.nt2backup as a sovereignty format

Claim: the escape hatch is a format, not a slogan

A vault that cannot leave the product is not local-first. It is hosted data with offline UI.

NT² Vault’s escape hatch is a file extension you can say out loud: .nt2backup. The claim is sharper than “we have export.” The file is a sovereignty format: a user-held package of portable vault profile plus ciphertext for items and attachments—enough for another enrolled device to restore what matters, without asking the edge to become a custodian.

That package is not a spreadsheet of secrets. It is not a support ticket that ends in “we reset your password.” It is not a Premium-only privilege with a weaker Free-tier story. Free users move vaults with the same family of encrypted batches; optional cloud sync ships related bytes over HTTP. The security model does not fork when the transport does.

If you only remember one sentence: .nt2backup is how ownership stays portable when the cloud is optional and the master password never leaves your device.

Constraint: dumps, oracles, and “the cloud is the backup”

Three failure modes haunt encrypted vault products. All of them look like portability until you ask who holds the keys.

Plaintext dumps. Export as CSV, unencrypted JSON, or “open format for interoperability” sounds generous. For a structured vault it is a second copy of your life in the clear—on a USB stick, in email, in a sync folder that indexes file contents. Zero-knowledge at rest means little if the escape hatch is the place where the product quietly gives up. A sovereignty format must carry sealed payloads, not a friendly unzip of everything you typed.

Provider-shaped recovery. “Just restore from our servers” is convenient when the provider also holds enough material to unlock you after a forgotten password. That convenience is an oracle. NT² refuses password reset by design: salt stays on the device, the edge does not store a password verifier you can fetch, and support cannot reconstruct what it never received. Portability therefore cannot mean “ask us for your vault back.” It has to mean you already hold a file—or you enrolled another replica—before disaster day.

Cloud-only truth. Local-first marketing collapses when the only durable snapshot lives in the vendor’s object store. Device loss then becomes a support flow. Subscription churn becomes a hostage situation. A real escape hatch must work without Premium sync: copy a file, enroll a cold device, merge ciphertext. Cloud may accelerate multi-device life; it must not be the sole definition of “backed up.”

There is a quieter constraint inside the vault itself. Not every row in the local database is portable. Sync cursors describe this replica’s progress. WebAuthn bindings belong to this authenticator. Dumping the whole attic into an export file pretends another laptop is the same machine. A sovereignty format has to know what travels and what must stay behind—or it becomes a vector for confused restore and broken unlock.

Design: portable profile + sealed payloads, one batch family

.nt2backup is engineered as an encrypted replica batch you can put on disk, USB, or any channel you trust more than a single vendor account.

Conceptually the file carries two layers:

The profile half is why section-shaped vault meta matters. Portable sections are allowlisted travelers. Device-local sections are omitted on purpose. Unlock on the destination still derives keys from the master password and local salt; the file does not become a password-in-a-box.

The catalog half keeps the same envelope discipline as day-to-day storage: each object’s content encryption key stays wrapped; IVs stay unique; the batch moves ciphertext the edge would also be allowed to store blindly. Opening the file without the right unlock path does not yield a readable biography.

flowchart LR
  source[Unlocked source vault]
  batch[.nt2backup batch]
  enroll[Enrolled target replica]
  merge[Merge ciphertext + portable profile]

  source -->|export portable sections + sealed rows| batch
  enroll -->|import after enroll| merge
  batch --> merge
  merge --> target[Restored vault on new device]

Two process rules keep the format honest.

Enroll, then import. A cold device does not become a replica by opening a backup alone. Identity enrollment (recovery kit path, setup QR, or equivalent user-held bootstrap) establishes that this machine is allowed to hold the vault. .nt2backup then merges contents into that enrolled replica. Mixing those doors—treating backup as enrollment—is how products accidentally invent a password-reset oracle dressed as a file.

Same batch family as blind sync. Premium cloud sync does not invent a second merge model or a clearer plaintext. It transports related replica batches to a blind hub. Free-tier file copy and Premium batch pull are different transports for convergent ciphertext, not different trust stories. That is escape-hatch engineering: the file you hold and the bytes you sync speak the same language.

Attachment ciphertext may ride beside the batch (large blobs are awkward to inline forever), but the rule stays: metadata authoritative, payloads sealed, nothing decrypts because it crossed a USB cable.

.nt2backup is also intentionally not a recovery kit. A recovery kit answers “how do I unlock on a cold device?” A backup answers “how do I move or restore the sealed catalog?” Both are encrypted. Both are user-held. Confusing them is how people export the wrong file under stress. Sovereignty needs both tools—and clear jobs for each.

Trade-off: you hold the file, so the file is precious

Shipping a real sovereignty format costs convenience we refuse to fake.

No magical forgotten-password recovery from the backup alone. The file contains sealed payloads and portable profile—not a plaintext master password and not a server-side unwrap button. Lose every unlock factor and every user-held recovery path, and NT² cannot invent them. That is the same trade-off as no password reset, by design; the backup does not secretly undo it.

Operational hygiene lands on the user. A .nt2backup on an unlocked laptop desktop, emailed to yourself, or synced into a provider that scans file bodies is still ciphertext—but it is high-value ciphertext. Treat it like a sealed archive: separate from the master password, versioned after large changes, stored where you choose. Ownership includes custody.

Restore is a sequence, not a single click myth. Enroll the new device, then import. Wrong order fails closed instead of “helpfully” minting a half-vault. That friction is deliberate. It keeps backup from becoming a second unlock oracle.

Device-local honesty. Sync state and platform authenticators do not round-trip as if they were portable identity. After restore you re-enable sync, re-bind passkeys, and accept that this replica starts its own bookkeeping. The format refuses to lie about physics.

We gave up “interoperable plaintext” as the default exit. Other tools can still receive selective shares or user-initiated copies of specific fields. The full-vault escape hatch stays encrypted. Interoperability that requires dumping secrets is not the kind we optimize for.

What we gain is the property marketing often claims and rarely ships: you can leave without asking us to become you, and you can refuse the cloud without refusing multi-device life.

What we refuse

We refuse plaintext full-vault export as the sovereignty story. Sealed batches leave; convenience dumps are not the product promise.

We refuse putting the master password in the backup file. The password stays in your head (and in whatever user-held factors you chose). The file is not a password manager for the password manager.

We refuse treating backup import as enrollment or password reset. Those are different doors. Crossing them would recreate the provider oracle we deleted from the edge.

We refuse exporting device-local state as portable identity. Cursors and authenticator bindings stay on the machine that owns them.

We refuse a Premium-only escape hatch. File export is first-class for Free. Cloud sync is optional acceleration with the same ciphertext family—not a different security model sold as “real backup.”

We refuse a cloud salt or verifier fetch to “complete” restore. Salt travels out-of-band in portable profile or enrollment material. The edge never becomes the place you download enough to guess the password.

We refuse decrypting on the wire or on disk “so restore is easier.” Merge applies sealed rows. Unlock on the destination is still local derivation.

Close: ownership you can put on a stick

.nt2backup is where the product’s softest promise becomes a hard artifact. Not a policy page. A file.

The story-side version of this claim is Escape hatch, not lock-in. How portable profile sections are chosen lives in Vault profile is section KV, not one mega-row. Why we cannot reset your password—and why that forces user-held recovery—is No password reset, by design. Why salt never becomes a cloud fetch is The KDF salt stays on your device. Which encrypted file does which job is Recovery kit or backup file?. How item and attachment payloads stay sealed per object is One key per object: envelope encryption inside NT² Vault.

If you want a vault whose exit path is a sovereignty format you hold—not a support queue—try NT² Vault or read more at nt2.me.