Local-first data over storage you choose

Your app keeps working. Your storage provider stays blind.

Interocitor keeps structured data on trusted devices, syncs independent changes when connectivity returns, and carries documents and media as durable files. With a key source, payloads are encrypted before remote storage receives them.

Why Interocitor

Keep work close. Use the network to move it.

Server-owned state is convenient, but it turns network outages into product outages and puts database operators inside the plaintext trust boundary. Interocitor splits synchronization from storage: trusted endpoints merge changes; the remote stores and moves them.

Responsibility split with a non-null key source

Trusted devices
Keep working state and resolve changes.
Remote mailbox
Stores and moves encrypted artifacts.
Storage operator
Operates storage without payload plaintext.

Keep working without a round trip

A local-first interface can respond from local state when a device is in the field, moving between networks, or temporarily offline. Connectivity becomes the way work travels, not a prerequisite for doing the work.

Store data without sharing the contents

A provider can retain and serve encrypted artifacts without needing the final decryption key. This narrows the confidentiality boundary and makes a storage dump materially less revealing than a plaintext application database.

Put the mailbox where it belongs

The same application model can use a Cloudflare mailbox, a user’s Google Drive, a WebDAV server or home NAS, or a custom adapter. The storage decision can follow the product’s deployment, ownership, and operational needs.

See it in action

Local collaboration, protected data and trusted automation.

One model covers application state that changes, files that must stay exact, and trusted workers that need to participate without exposing their work to storage.

01 Local-first application

TodoMVC, live in this browser.

Use two familiar TodoMVC clients side by side. A live in-page filesystem exposes the exact manifest, device, head, and change files without asking the visitor to provide storage or run a backend.

Make convergence observable. Change either client, simulate a disconnect, and inspect the files created on reconnection. Everything resets when the page reloads. Try the live TodoMVC
one page · two clients
const memory = new MemoryAdapter();
const left = createDatabase('client-1');
const right = createDatabase('client-2');

await left.table('todos').add({
  title: 'Ship it', done: false
});

await left.flush();
await right.pull();

02 End-to-end encrypted chat

Two clients. One mailbox that cannot read the conversation.

Alice and Bob share a mesh key and exchange message rows through an inspectable in-page mailbox. The application deletes messages older than the newest fifteen, synchronizes the tombstones, and compacts covered history.

Inspect the actual ciphertext. Send from either client, watch the other converge, and verify that the mailbox never receives the message text. Everything resets when the page reloads. Try encrypted chat
Alice Meet at five? plaintext endpoint
Mailbox v1 · iv · ciphertext no mesh key
Bob Meet at five? plaintext endpoint

15 newest messages remain visible on both clients.

03 Collaborative board

A Trello-style board that works from each local copy.

Maya and Noah add and move cards independently, then exchange encrypted row changes through the in-page mailbox. Their boards converge without asking the mailbox to understand columns, cards, or conflicts.

Make independent edits, then sync. Watch each board stay local until both clients exchange their changes. Try the shared board
IdeasInterview usersPlan launch
DoingRewrite onboarding
DonePrivate beta

04 Protected family location

Strong payload privacy does not make a safety product.

Two devices share encrypted latest-known location rows while the mailbox sees no place names or coordinates. The five-second demo cadence keeps both views current; broad key-holder access, consent, revocation, and emergency reliability remain product responsibilities.

Inspect the privacy boundary and the failure boundary. This is a protected-data demonstration, not a tracking recommendation. Try the locator boundary
Alex Home Sam School

Latest known is not live or emergency-safe.

05 Private file share

A private Dropbox over storage you choose.

Let storage do what it is good at—retain and deliver files—without giving it the document contents. Interocitor encrypts bytes before the adapter receives them, then another paired endpoint decrypts the same object.

await db.putFile(path, bytes, file.type);
const copy = await db.getFile(path);

File calls use the remote directly, so transfers need connectivity. Object paths, sizes, timing, and request identity can still be visible to the storage operator.

06 Agent workflow

Share task state without exposing it to storage.

A product writes a task row. An authorized agent endpoint observes it, does the work, and writes result rows or files back into the same mesh. Both endpoints can keep their own working state; the mailbox only exchanges encrypted artifacts. Work that must happen once needs an application-owned claim, lease, or safe retry rule.

Trusted endpoint Product Writes task rows
encrypted changes
Remote mailbox Cannot read the task Stores artifacts
encrypted results
Trusted endpoint Agent Reads, acts, writes
The agent holds a mesh key and sees plaintext, so isolate workflows into separate databases and keys when they need smaller trust boundaries.

What that means in practice

The useful copy stays close. The remote carries sealed parcels.

A plain-language view of the promises—and the trade-offs.

Picture two people changing the same shared workspace from different devices. One is offline on a train; the other is connected at home. Each can keep changing local rows. When their devices can reach the mailbox again, they exchange encrypted changes and arrive at the same result without asking the mailbox to choose a winner.

The mailbox is important, but deliberately unhelpful: it stores and returns protected artifacts without receiving the final key or interpreting the row data inside them. It can still see operational metadata—names, sizes, timing, request identity, and device identifiers—and it can still lose, withhold, or roll back what it stores.

That is why local-first and encrypted do not mean consequence-free. Row work survives offline only when the app uses durable local storage; durable-file calls still need a connection. A lost key needs recovery prepared in advance, a copied key requires a new database and key for full revocation, and important data still needs tested backups.

Read the simple questions and honest answers

Why local convergence matters

Independent work does not need a central editor.

Trusted devices can change local rows without first acquiring a server lock or waiting for a leader. Interocitor’s structured data model lets those devices converge after they exchange encrypted changes.

Follow a change through the complete sync loop

Two data surfaces

Rows should converge. Files should stay exact.

Application state and file content need different promises. Treating them honestly avoids forcing large binary objects into a merge model or pretending remote files have the same offline behavior as local records.

Structured rows

Local working state that can converge

Use rows for the facts an application reads, changes, and reconciles across devices—titles, statuses, notes, relationships, and other structured state. Reads and writes use the application’s local store, so the product can remain responsive without a live remote.

Durable files

Exact remote objects for documents and media

Use files when the bytes themselves must remain intact. They are encrypted before storage, but they are not merged as records. File calls need the remote, which makes their availability boundary explicit instead of hiding it.

Bring your own cloud

Put the mailbox where ownership makes sense.

Storage is part of a product’s trust, cost, portability, and recovery story. Some teams want an operated Cloudflare deployment. Some want data in a user-controlled Google Drive account. Others prefer WebDAV on infrastructure they already own.

Interocitor keeps those choices behind the same storage role. Changing the operator does not require moving plaintext merge logic into that operator’s environment.

  • CloudflareOperate a mailbox with D1 and R2.
  • Google DriveLet a user connect their own storage.
  • WebDAVUse a compatible server or home NAS.
  • Custom adapterFit an existing storage environment.

The actual trust boundary

Encryption narrows trust. It does not remove it.

With a non-null key source, row payloads, snapshots, durable-file bodies, and recovery-wrapper contents are encrypted before the remote adapter receives them. The final decryption keys and usable plaintext remain at trusted endpoints.

The remote still observes operational metadata such as object names, sizes, timing, request identity, mesh identifiers, and device identifiers. It can also withhold, delete, or roll back stored data. Interocitor protects payload confidentiality and entry integrity; reliable storage and backups still protect availability.

Protected from the remote

  • Row field names and values
  • Snapshot payloads
  • Durable-file contents
  • Recovery-wrapper contents

Still visible to the remote

  • Object names, paths, sizes, and timing
  • Mesh and device identifiers
  • Request and storage-account identity
  • Deletion, withholding, and rollback opportunities

See the illustrated trust boundary for the path from trusted endpoints through remote storage.

Before choosing the architecture

Decide who holds trust, not only where bytes live.

A local-first encrypted mesh changes several product responsibilities. These are the questions worth answering before implementation details.

Which endpoints may read everything?

A client, worker, or AI agent with the mesh key is a trusted endpoint. It can process the row database, so use separate databases and keys when work needs a smaller trust boundary.

How will users recover a lost key?

Recovery must be prepared before loss. Another trusted device or a previously published recovery wrapper can restore access; without either, encrypted data is unreadable.

What happens when a device is no longer trusted?

Removing remote access does not erase a key that was already copied. Full revocation requires a new mesh and key, which should be part of the product’s incident plan.

Who protects availability?

Encryption cannot recreate deleted objects. Important deployments still need provider version history or an independent copy, plus a restore path that has been tested.

Ready for the mechanics?

See how independent writes converge, what the remote stores, and how clients keep history bounded.

Open how it works