← all documents · raw markdown · 6 KB

Scope — device persistence and a resume you choose

Goal, in your words: account data lives on the server; each device keeps its

own sense of where *you* were on *it*; drafts cross between them; and when you

come back you pick — carry on where this device was, or pick up what you left

on the other one.

---

What already exists

Most of the plumbing is built. Worth knowing before scoping the rest.

| Piece | Where | State |

|---|---|---|

| Account sync | _syncKeys / _syncPrefixes, [internal endpoint] | Working. Server publishes the key list so client and server can't drift. |

| Draft sync | prefix kai.draft. | Working. Drafts already follow the account. |

| Draft capture | _autoDraftSave / _autoDraftRestore | Working. Excludes passwords and data-nodraft. |

| Reading position | _leoMarks(), {page, at} per document | Working, device-local. |

| Device-local view | kai.lastView, oracle.lastChat | Fixed 2026-08-18 (v9.10.720) — was account-synced, which is why the Codex followed you between devices. |

| A device secret | _kai_device_secret | Exists, but it is an auth secret. Not usable as an identity we display. |

So the model you described is roughly half-implemented already. The missing

half is not sync. It is provenance and choice.

---

What is actually missing

1. Nothing records which device wrote anything. Drafts and reading marks

carry no device id. So "continue the draft from your phone" cannot be built —

not because syncing is hard, but because nothing knows it came from a phone.

2. Drafts have no timestamp. saveDraft stores a bare string. Two devices

with two drafts cannot be ordered, so "which is newer" is unanswerable, and

last-write-wins silently eats the other.

3. Restore is silent and unconditional. _autoDraftRestore fills every

empty eligible input at 120ms and 700ms after load. It never asks. That is fine

when the draft is yours from this device and wrong when it came from elsewhere —

it is the same class of problem as the Codex jump: a decision taken for you.

4. There is no device list. Nothing to name, see or forget a device with.

---

Design

Identity

Add kai.device.id (random, non-secret, device-local, never synced as a

preference) and kai.device.label, defaulted from the user agent — "Phone",

"Windows PC" — and user-editable. Registered to the account so other devices can

render a name instead of a hash. Not the existing _kai_device_secret;

reusing an auth secret as a display id would leak it into UI and logs.

Provenance

Draft values become { v, at, dev } instead of a bare string, read

back-compatibly: a bare string is treated as {v, at:0, dev:null} so nothing

written by an older client is lost, and old clients keep working because the

server's allowlist is back-compat by design. Reading marks gain dev alongside

the at they already have.

The two tracks

This device's session — kai.lastView, scroll, reading mark. Local, never

synced. This is the "carry on where I was on *this* machine" track.

The account track — drafts, and reading marks if you want them to travel.

This is the "pick up what I left elsewhere" track.

Both are kept. The point is that you choose, rather than one silently winning.

The resume affordance

Replace the silent jump with an offer. On boot, compute candidates:

this device's last session, if it has one
the newest account-track item that is from a different device and newer

than this device's own

Then:

neither → nothing shown (the common case; no new noise)
one → a single chip: *"Continue reading — page 65"* or *"Draft from your Phone, 4 min ago"*
both → two chips, yours first

Dismiss is permanent for that item. A chip that reappears after you decline is a

nag, and a nag gets ignored, and an ignored control is the same as a broken one.

Drafts specifically

Same-device drafts keep filling the box silently — that behaviour is right and

people rely on it. A draft from *another* device stops overwriting and offers a

chip instead. That is the whole behavioural change.

---

Phases

|---|---|---|---|

| 1 | Device id + label; stamp drafts and marks with {v, at, dev}; back-compat readers | none | low — additive, reversible |

| 2 | Reading resume becomes a chip instead of setView('codex') | the Codex stops grabbing you | low |

| 4 | Devices list in settings: name, last seen, forget | new settings pane | low |

Phase 1 is the only hard dependency. 2, 3 and 4 are independent after it and can

ship in any order or not at all.

---

Risks

Draft format migration is the one thing that can lose work. The reader must

accept both shapes forever, not for a transition window — old clients keep

writing bare strings for as long as one exists unrefreshed.

Clock skew between devices makes "newer" wrong. Prefer server-stamped

times where the sync round-trip already provides one.

Privacy: device labels are account data visible to that account only. Do

not store raw user-agent strings; derive a label and keep the string local.

Never sync _kai_device_secret, and never sync kai.lastView again — that

regression is what this whole thread started from.

---

Decisions I need from you

1. Should reading marks sync across devices? If yes you get "continue reading

from your phone" on the desktop; if no, each device remembers only its own

place. Your description implies yes, but it is the one place the two tracks

genuinely overlap.

2. Chip on every load, or only on conflict? Only-on-conflict is quieter and

is what I would build unless you say otherwise.

3. Same-device drafts — keep filling silently, or always ask? I would keep

silent; asking about your own draft on your own machine is friction with no

information in it.