One sync hub for one vault identity

Optional cloud sync needs a meeting point.

When a laptop uploads an encrypted change, a phone needs somewhere to discover that the vault has advanced. When two replicas reconnect after being offline, they need an agreed place to compare progress. When a device is already online, a small notification can tell it to fetch new encrypted data instead of waiting for the next polling interval.

The usual answer is a shared sync service backed by shared multi-tenant tables. Every account writes rows into the same logical mailbox, and application code adds a tenant condition to every query.

NT² takes a narrower approach: each cloud-enabled vault identity gets one Durable Object as its sole replica coordination hub. The object is named from the vault's public cryptographic identity, its Vault Key DID. It coordinates authorized replicas for that identity, keeps the small amount of state needed to announce progress, and uses hibernatable WebSockets for lightweight change notifications. The encrypted replica frames themselves live in R2 as opaque objects.

The hub is not the vault. It does not hold a readable copy, run searches over secrets, or possess the key required to decrypt a frame. It is closer to a private station board: it can say that another encrypted delivery is available, but it cannot open the parcels or understand what changed.

The shared-table temptation

Multi-tenant tables are popular for good reasons. They are familiar, queryable, and efficient. A team can put all messages into one table with columns such as tenant_id, sequence, payload, and created_at. An index makes fetching the next page fast. A support query can count delayed rows. A background worker can scan the table and retry failed deliveries.

The danger is not that relational databases are inherently unsafe. The danger is that isolation becomes a repeated application-level promise.

Every read must include the right tenant predicate. Every update must verify ownership. Every join must carry the boundary through. Every maintenance script, migration, queue consumer, admin export, and debugging query must remember the same rule. One missing condition can turn an ordinary bug into cross-tenant disclosure.

Framework helpers and database policies can reduce that risk, but they do not erase the organizational pressure around a shared data plane. Once many customers' records occupy one queryable surface, internal tools naturally grow around that surface. Operators want broader searches to troubleshoot incidents. Product teams ask for aggregate fields. Support tools request previews. Someone proposes storing a plaintext title beside an encrypted payload because it would make one screen easier to build.

That is how an operator "peek" culture can emerge without anyone announcing a change in privacy policy. The schema makes broad visibility convenient, so visibility starts to feel normal.

For a vault, this is the wrong cultural default. Sensitive data should not be one forgotten filter away from another tenant, and readable fields should not enter a shared mailbox merely because shared tables are convenient.

Let the public identity choose the room

Every NT² vault has a Vault Key DID: a public cryptographic identity used to authenticate its cloud requests. The identity is not a password and does not reveal the contents of the vault. It gives the service stable public material with which to recognize authorized signatures.

That same public identity can deterministically select the vault's Durable Object. Requests for a given Vault Key DID resolve to the same object, while a different identity resolves to a different object. The result is a simple isolation rule:

• one vault identity has one coordination address;
• only authenticated requests for that identity may use it;
• all replica ordering and live notification for that vault pass through that hub;
• no shared coordinator needs to multiplex readable state for unrelated vaults.

Naming an object from public identity does not make the name a secret. That is not the purpose. Authorization still requires cryptographic proof, and any external request still needs normal validation and abuse controls. The benefit is deterministic routing and a clear ownership boundary, not security through obscurity.

The Durable Object also becomes the natural place to serialize the small moments when sync replicas could otherwise race. It can accept an authenticated announcement that new encrypted frames have been committed, advance coordination state, and tell connected devices that a later position exists. Because requests for one vault converge on one logical object, this coordination does not require a global lock over every customer.

Equally important, the object remains narrow. It does not need the local vault schema. It does not need columns for credentials, notes, document types, tags, or attachment names. It needs only the outer facts required to coordinate encrypted replicas.

Durable coordination, opaque storage

A Durable Object is useful for stateful coordination, but it is not the right place to accumulate every encrypted byte forever. Replica frames and attachment chunks can be numerous and large. R2 is designed to hold those objects durably.

The division of responsibility is deliberate:

1. An authorized device encrypts a vault change locally.
2. It uploads the opaque frame under an opaque object reference.
3. The per-vault Durable Object records or observes the resulting progress needed for coordination.
4. The hub notifies other connected replicas that a newer position is available.
5. An authorized replica fetches the missing frames and decrypts them on its own device.

R2 sees bytes, object references, sizes, and access activity. The Durable Object sees coordination facts such as replica progress and connection state. Neither receives the vault key or plaintext item fields.

This boundary also makes failure behavior easier to reason about. A WebSocket notification is not the durable copy of a change. It is only a hint that the receiver should check for new frames. If a phone is asleep, a connection drops, or a notification is missed, the encrypted frame remains in object storage and the replica can catch up during its next authenticated sync.

The hub therefore improves latency without becoming a fragile message bus whose every event must arrive exactly once.

Hibernatable WebSockets for quiet vaults

Most vaults are quiet most of the time. A person may edit several records, close the app, and make no further changes for hours or days. Keeping a fully active server process alive for every connected but idle replica would waste resources.

Hibernatable WebSockets fit this pattern. A device can maintain a live channel for change notification while the platform allows the Durable Object to sleep when no work is happening. When traffic arrives, the object resumes, validates the relevant context, and continues coordination.

The notification should stay intentionally small. It may indicate that progress has advanced or that new frames are available after a known position. It should not include a decrypted title, a note preview, a credential category, or any other content-derived convenience field.

This matters beyond bandwidth. Real-time systems tend to attract business logic. If the live channel starts carrying interpreted item operations, the coordinator gradually becomes another readable backend. By keeping the signal content-agnostic, NT² preserves the distinction between notification and interpretation:

• the hub knows that encrypted state changed;
• an authorized, unlocked device knows what changed.

That is enough for responsive sync.

The trade-off: more edge machinery, clearer isolation

One Durable Object per vault identity introduces complexity. Routing must be deterministic. Authentication must bind a request to the same identity that selected the object. Object storage references, retry behavior, replica cursors, connection lifecycle, and deletion all need careful handling. Operational tooling must diagnose coordination failures without depending on plaintext content.

A shared table and a fleet of stateless workers can look simpler, especially at the beginning. The per-vault design chooses additional edge machinery in exchange for a boundary that is easier to state and audit: coordination for identity A lives with A's object; identity B reaches a different object; neither object needs readable vault data.

This is isolation at the coordination layer, not a claim of magical physical separation. The objects still run on a shared cloud platform, network metadata still exists, and implementation bugs remain possible. Encryption and authorization are still mandatory. Per-identity routing reduces the number of places where unrelated tenant state is intentionally combined; it does not replace secure engineering.

There is another important limit: the Durable Object is optional because cloud sync is optional.

The local vault can be created, unlocked, searched, and edited without contacting this hub. If the network is unavailable, the object is sleeping, or the user never subscribes to sync, the vault on the device still works. Local operations do not wait for a cloud coordinator to grant permission.

When connectivity returns, a sync-enabled replica can package encrypted changes, authenticate, and resume from durable progress. The cloud extends the vault across devices; it does not become the authority that allows the vault to exist.

What the hub cannot do

The architecture is defined as much by refusal as by capability.

The Durable Object cannot decrypt vault contents. It does not receive the master password, vault encryption key, or another provider-held shortcut to plaintext. Moving coordination into a stateful edge object does not move trust in the same direction.

There is no shared Durable Object containing many vaults' plaintext. Such an object would recreate the global mailbox under a different product name. It would concentrate readable tenant data, invite broad internal queries, and turn a routing mistake into a potential disclosure.

Notifications do not contain secret previews. A device learns that encrypted frames are ready, then authenticates, fetches, and interprets them locally. The hub does not need to make the notification more "helpful" by attaching a title or category.

The object is not required for offline use. Losing live notification may delay synchronization, but it must not lock a person out of the vault already on their device.

These refusals constrain support tooling and server-side features. An operator can inspect service health, connection failures, object counts, timing, and authorization outcomes. They cannot open a record to see why its text looks unusual. That limitation is not an unfinished admin feature. It is evidence that the coordinator has not become a plaintext control room.

A private meeting point, not a readable master copy

Blind sync still needs coordination. The meaningful choice is whether that coordinator becomes a global, readable center of gravity or remains a narrow meeting point for encrypted replicas.

NT² assigns that meeting point per Vault Key DID. One identity resolves to one Durable Object. Hibernatable WebSockets provide low-cost change notification. R2 retains opaque frames. Authorized devices perform encryption, decryption, indexing, and conflict interpretation locally.

The result costs more design effort at the edge, but it makes the intended boundary concrete: a vault's cloud hub can coordinate its replicas without becoming the vault itself.

To see why the cloud identity is separate from local access, read Unlocking a local vault is not logging in to the cloud. For the encrypted transport model this hub coordinates, continue with Blind replica sync on the edge. If you want a vault that remains useful before, during, and after a network connection, open NT² Vault.