Sync and offline

What happens to a keystroke

1. Your keystroke changes the screen, immediately and without waiting for anything.
2. It is queued on this device before anything is sent, so a tab that dies before the save lands still has it.
3. It is sent to the server as soon as the network allows, and merged there as a CRDT operation.

Doing the third before the first is a spinner, which is why it is in that order. Step two is the one to read twice, and it is narrower than it sounds: what is kept on this device is the text you typed and the server has not yet accepted. It is replayed when the tab is opened again and deleted the moment the server acknowledges it.

What it does not do is make Fastpad a fully offline editor. Opening a note you have not already opened still needs the network, and a browser that refuses local storage — private browsing, or a policy that blocks site data — has nowhere to put the queue. In that case the editor says so rather than reassuring you: the warning not to reload the tab appears exactly when reloading it would in fact lose work.

Either way it tells you. A save that has not landed is named for what it is — no connection, session ended, note deleted, server fault — with what to do about it, and it keeps trying rather than giving up after a few seconds: the delay between attempts grows, and coming back to the tab or regaining a connection starts it again immediately. The one wait that is not cut short is the one the server itself asked for, because it knows something this tab does not.

Two people, one paragraph

Notes are CRDTs, so concurrent edits merge without a lock and without asking you to pick a winner. Two people typing in the same note, or the same person on a laptop and a phone, converge to the same document whatever order the edits arrive in.

Structure merges too: reordering blocks on one device while editing them on another does not produce a duplicate or a lost block, because a block’s identity is independent of its position.

Offline

In the terminal, edits and captures queue to a durable spool on disk and replay when you reconnect, and the replay is idempotent on both ends — a change the server committed just before you lost signal acknowledges rather than duplicating.

fp capture never fails offline: it writes to that spool with an idempotency key, exits 7, and the next command that works flushes it.

In the web app, an edit you make while the connection is down is queued on this device and retried with a growing delay for as long as the tab is open, and it is sent as soon as the connection returns — you do not have to type again to restart it. The top bar says which of the two you are in, because a connection that has dropped and a change the server refused have opposite prognoses.

The laptop that was shut for a year

History is compacted over time, bounded by what your devices have actually acknowledged rather than by a calendar. A device that has not been seen for a long time and comes back holding edits that can no longer be merged gets a designed path, not a shrug.

Its work becomes a new note titled “Unmerged offline edits from <device>, <date>”, with as much recovered as can be. What never happens is the edits being dropped while the sync reports success.