Blind replica sync on the edge

A sync service has to see enough to do its job. It needs to know that a request is authorized, which account owns a stored object, whether a subscription permits sync, and which encrypted updates a device still needs.

It does not follow that the service must see the title of a passport record, the username in a login, the text of a Secure Note, or the contents of an attachment.

That distinction is the claim behind NT² Premium sync: the cloud relays ciphertext and maintains limited account metadata, but it cannot read vault contents. Encryption happens on the device before replica data crosses the network. Decryption happens on an authorized device after it receives the data. The service between those points handles opaque frames.

This is not a claim that the server sees nothing. It sees operational facts such as request timing, object sizes, account identity, and billing state. Networks cannot route packets without metadata, and subscription services cannot enforce an entitlement without an account record. The useful security boundary is more precise: the server should not receive the keys or plaintext needed to interpret a person's vault.

That boundary changes what the sync system is allowed to become.

The cloud-first constraint

Most sync APIs begin with a server-owned data model.

A client sends JSON with fields such as title, category, updatedAt, and notes. The server validates those fields, writes them into relational columns, builds indexes, resolves conflicts, and returns a clean representation to every device. This is a productive architecture. It makes server-side search, analytics, support tooling, and migrations straightforward.

It also means the provider can read the data, unless another encryption layer is added.

Sometimes an application says data is "encrypted" because the database disk is encrypted or because HTTPS protects it in transit. Both are important, but neither makes the service blind. The application server still receives plaintext. It can log a request body, index a secret, expose it through an internal console, or decrypt a stored value with a key available to the same operating environment.

Client-side encryption can improve that model, but only if the boundary is real. If the server receives encrypted blobs alongside plaintext titles, categories, URLs, previews, or search tokens, the supposedly opaque payload may still reveal much of a person's life. If the provider keeps a decryption key for account recovery, the blobs are not blind to the provider. If a support operator can click "view vault," the architecture has already answered the trust question.

For a local-first vault, adapting that conventional API is the wrong starting point. The device already has the database, the indexes, and the ability to interpret item fields. Sync should move changes between replicas, not recreate the vault as a readable cloud application.

Design the unit of sync as an opaque frame

NT² treats an authorized device as a vault replica. The local vault remains the place where structured records are understood. Before a change is eligible for sync, sensitive content is encrypted locally. The sync representation is then packaged as an opaque frame inside a replica batch.

From the relay's perspective, a frame is deliberately boring. It has enough outer information to store, order, and deliver the encrypted object, but the meaningful payload is ciphertext. The relay does not need a column for a bank name, a document number, a note body, or a credential URL. It does not need to know whether a frame represents a new item, an updated attachment, or another private vault fact.

This separation creates two different schemas:

1. The local vault schema understands structured assets, relationships, and indexes.
2. The relay schema understands accounts, opaque objects, replica progress, and delivery.

Keeping those schemas different is a privacy feature. A cloud table cannot accidentally expose an item title if no item-title column exists. A support query cannot filter for "all passport records" if the service never receives a readable category. A database export can still be sensitive because metadata matters, but it is not an export of plaintext vault contents.

Replica batches also make the transport practical. A device can group encrypted changes, upload them, and record progress without issuing one cloud request for every local field edit. Another authorized device can ask for frames after its last known position, download the missing batches, authenticate and decrypt them locally, and apply the resulting changes to its own replica.

The edge is useful here because it is close to devices and good at short authorization and transfer requests. It does not need to perform vault computation. Its job is to verify the account request, accept or return opaque objects, and keep the small amount of coordination state needed for delivery.

Object storage holds bytes, not a second vault

Encrypted replica frames and attachment data can be larger and more numerous than an account row should hold. Object storage fits that workload: it stores byte sequences under opaque identifiers and serves them back to authorized requests.

The important point is not the storage product. It is the contract around it.

The object store receives encrypted data. The edge account record points to ownership and synchronization state. Neither needs to parse a person's item fields. Object names should not be derived from readable titles. Logs should not contain decrypted payloads. Authorization should be checked before upload and download. Retention and deletion behavior still matter, because ciphertext is still user data even when the service cannot read it.

This design also avoids pretending that one database technology should do everything. An edge account table is good for small, queryable facts:

• a cryptographic account identity;
• public material needed to verify an authenticated request;
• whether the account is disabled;
• whether Premium sync is currently entitled;
• billing status and timestamps;
• cursors or references needed to coordinate replicas.

Those are account and service facts, not vault item fields. The table should not contain decrypted titles, usernames, notes, attachment names, document previews, or a server-generated full-text index.

That line is easy to blur over time. A product team may want a support dashboard that shows "just the latest five item names." An engineer may propose plaintext categories to simplify metrics. A search feature may begin with "harmless" deterministic tokens. Each shortcut gives the service a new fact about the vault and creates a field that must be secured, governed, disclosed, and eventually deleted.

The stricter architecture asks a different question: can this feature run on the device that already has the key? If yes, the edge should not learn the answer.

Live notification can stay lightweight

Batch sync does not require every device to poll constantly. A lightweight coordination service can notify connected replicas that new encrypted data is available. It might hold a short-lived connection, signal a sequence change, or serialize a small piece of per-vault coordination.

That notification does not need to carry the secret itself. "New frames are available after position 42" is enough. The receiving device can authenticate, fetch the opaque batch, and decrypt it locally.

This distinction matters because real-time infrastructure often grows into a second application backend. Once it starts interpreting item operations, rendering previews, or making content-aware decisions, the blind relay boundary weakens. A live channel should improve delivery latency, not become a place where vault meaning is reconstructed.

It should also remain optional to correctness. A missed notification is an inconvenience, not data loss. The next authenticated sync can discover the missing frames from durable progress state. Devices that were asleep or offline should be able to catch up without having maintained a permanent connection.

The trade-off: sync is optional, offline is normal

Blind sync gives up capabilities that cloud-first products often treat as basic.

NT² cannot rely on the server to render your records in a browser session that has no local vault. It cannot ask the cloud to search every secret while your devices are offline. Conflict handling and migrations must be designed so authorized clients can do meaningful work. Support cannot inspect a record to diagnose why its contents look wrong.

There is also no honest way to promise that metadata disappears. The service can observe that an account synchronized at a certain time, transferred a certain number of bytes, or has multiple active replicas. Traffic analysis and endpoint compromise are separate risks from server-side plaintext access. Zero-knowledge narrows trust; it does not abolish systems security.

In exchange, the default path stays simple: create a vault locally, unlock it locally, search it locally, and keep using it without a network. Premium sync is a paid convenience for people who want encrypted replicas across devices. It is not a prerequisite for owning or opening a vault.

That product boundary also controls cost. People who need no relay should not have to fund one through a mandatory account. People who choose sync pay for storage, transfer, and coordination. The subscription adds availability across devices; it does not purchase the provider permission to read the underlying records.

Offline operation is therefore not a degraded fallback. It is the happy path from which sync extends.

What we refuse to build

Architecture is clearer when refusal is explicit.

No server-side search of secrets. Full-text search belongs on an unlocked device, where the local index can work with readable data under the user's control. Uploading plaintext titles or a provider-readable search index would make cloud search easier, but it would also create a searchable collection of the facts the vault is meant to protect.

No operator "view vault" tool. Support and operations need tools for service health: account status, entitlement failures, transfer errors, object counts, and delivery timing. They do not need a button that decrypts a customer's records. If such a button can exist, the provider has the key or a path to it, and "blind relay" is no longer an accurate description.

These refusals have consequences. Troubleshooting must rely on client-side diagnostics, safe error codes, and metadata that does not expose content. Product analytics cannot answer every content question. Recovery cannot quietly depend on a provider-held decryption secret.

Those are not missing admin features waiting to be added. They are constraints that preserve the model.

Let the network help without taking ownership

The useful alternative to cloud-first is not permanent isolation. A local vault can benefit from edge delivery, durable object storage, and live notifications while keeping interpretation on authorized devices.

The division of responsibility is the point:

• devices create, index, encrypt, decrypt, and search vault content;
• the edge verifies accounts and sync entitlement;
• object storage retains opaque replica frames;
• lightweight coordination tells replicas when to fetch;
• no server component receives the ability to open the vault.

That is what "blind replica sync" means in practical terms. The cloud is allowed to carry and coordinate encrypted state. It is not promoted into the owner of a readable master copy.

For the unlock-versus-cloud boundary, read Unlocking a local vault is not logging in to the cloud. For the broader local-first stack, see why a PWA can be a local-first, zero-server vault. If that model fits how you want to keep sensitive records, open NT² Vault.