Principles/06 of 06

Works offline, live together.

Mandala is local-first. Your data is on the device in front of you, so it works without the internet. Your devices send each other what they missed when they meet. The direction from here is live: documents and tables that update as others work, people side by side. This page says which part is which.

Planet Express · somewhere past the Moon

There is no signal on the ship. Hermes opens his laptop anyway, adds bubble wrap to the office supplies, and marks Tyrell’s invoice as paid.

He has forgotten that he did some of this at his desk that morning, after Bender unplugged the router to charge himself: Slurm on the same list, and the same invoice, paid.

When the laptop and the desk meet again, the list has both items. The invoice is not paid twice: the second payment is kept as a conflict for Hermes to settle.

Hermes’s laptopboth offline · 09:58 to 10:20Hermes’s desk
AddItem Bubble wrap, 3 rolls10:01 · seq 211
commutes
AddItem Slurm, 2 cases10:04 · seq 318
Pay Tyrell invoice #204110:02 · seq 212
exclusive
Pay Tyrell invoice #204110:05 · seq 319
Back online: each sends what the other lacks, and both apply it in clock order.
Office supplies

Bubble wrap, 3 rolls · Slurm, 2 cases

both kept, on both devices
Invoice #2041, paid twice?

Each device paid while apart, where no rule could see the other. Each refuses the other’s payment and keeps it as a conflict record. Hermes settles it under “Didn’t merge”.

refconflict-7c1e4b90a3d25f68-319
namespacestd.business.payable
actionPay
recordpayable-tyrell-2041
device · seq7c1e4b90… · 319
arguments{"payment_reference": "PE-5521"}
reasonrefused: state.status == "approved"
resolvedfalse
01 · Local first today

The contract says how each action merges.

Merging isn’t guessed. Each contract states, action by action, what happens when two devices did things apart. Adding to a list can’t conflict. Paying an invoice can.

commutes

Order doesn’t matter. Both are kept.

last_writer

The later change wins; the earlier one is noted as superseded.

exclusive, the default

Applied only if the rules still allow it. Otherwise it becomes a conflict for you to settle. Nothing is dropped silently.

std.personal.shopping_itemfront matter
---namespace: std.personal.shopping_itemversion: 1.0.0merge: AddItem=commutes, Check=last_writer, Remove=last_writer---
std.business.payablefront matter
---namespace: std.business.payableversion: 1.1.0merge: Receive=commutes, Review=last_writer, Approve=exclusive, Pay=exclusive, Reject=exclusive---

Real, from the standard library. Two devices can each add groceries. A second payment of the same invoice becomes a conflict record instead of a second payment.

02 · Documents today

Text merges by itself.

Each device keeps the whole set of your files. Edits travel directly between your devices and merge, even when two of them changed the same line while apart. There is no “conflicted copy” to sort out.

No cloud in between

Devices find each other on your network or across the internet and connect directly, encrypted. Only devices enrolled under your identity are trusted.

Together on one Mandala

Open the same document in two windows of the same Mandala and you see each other type.

Mac · offline

- [ ] Send the price list to all three

Laptop · offline

- [ ] Send the price list @due(2026-10-15)

Server

- [ ] Send the price list

Back online · merged everywhere

- [ ] Send the price list to all three @due(2026-10-15)

03 · Live together coming

Where this is going.

Local-first and realtime are the same idea at two speeds: everyone has the data, and changes flow. Today they flow when devices meet. The design we are building toward makes every screen a question that stays open, so the answer changes in front of you.

works today
  • Your devices sync. Records and documents, directly between your Mac and your servers, with merge rules and conflict records.
  • Offline is normal. A device that was away catches up when it comes back.
  • Co-editing on one Mandala. Two windows on the same document see each other type.
  • Live drafting. You watch your accomplice write a document beside the chat.
  • Sharing a local service between your own devices, at a stable address, with no VPN.
coming · designed, not built
  • Tables and boards that update live. A colleague approves a payable and the row leaves your list, with no reload.
  • People beside you. Who is in a document or on a record, their cursor, the field they are editing.
  • Co-editing between devices as it happens, not at the next sync, and surviving a restart.
  • Your accomplice typing into the document itself, as one more participant.
  • Several people on one Mandala, each with their own sign-in and signature.

The coming column is one design, called Medha on Karma: documents and records in one store, with live queries. It is designed and written down. None of it has shipped, and it depends on work that is itself still landing. The iPhone app is also still coming, so “your devices” today means your Mac and your servers.

Offline is not an error state. It’s a device that hasn’t met the others yet.

What if two devices disagree?

The contract decides. Some changes merge, the latest wins for others, and the rest become a conflict you settle under “Didn’t merge”.

Is a second device a backup?

It survives the loss of a machine, but a deletion syncs too. Keep dated backups as well.

Where is the detail?

Devices on the Karma page and sync on the Medha page.