Multi-device sync, and the bug I shipped that taught me why it had to be server-side.

The version I shipped first

The first implementation of multi-device sync in Gazenest used chrome.storage.sync. This is the browser API that Chrome provides for syncing extension data across devices via a user's Google account. It is well-documented, available without backend infrastructure, and works automatically if you structure your data correctly.

I used it because it was the obvious choice. The data I needed to sync, watched video IDs, user preferences, Clarity Score history, seemed like exactly what chrome.storage.sync was designed for. I shipped it. It worked in testing. I moved on.

The failure mode

The failure appeared in production about three weeks after shipping, and it was a specific and unpleasant kind of failure: silent data loss, intermittent, affecting only users with higher watch history volume.

chrome.storage.sync has limits. The total storage per extension is capped at 102,400 bytes. Individual items are capped at 8,192 bytes. The sync quota, how much data can be written per hour, is also bounded. For a user watching a moderate amount of YouTube, the watch history accumulates fast. The IDs alone, one per watched video, add up quickly when you're tracking sessions carefully.

What happened to affected users was this: their watch history started silently truncating. Older records were dropped when new ones pushed against the storage ceiling. The watched-videos filter started failing to recognize videos they'd watched weeks ago. The Clarity Score calculations became inaccurate because the session history was incomplete. The rewatch detection stopped working for anything outside the most recent slice of history.

Users noticed it as inconsistency. "The filter stopped working." "My scores seem off." I noticed it when I dug into the reports and found history gaps that shouldn't have been there.

Why I should have predicted this

Looking back, the failure mode was predictable from the storage limits. A user who watches 10-15 videos a day generates roughly 300-450 video IDs per month. At even a conservative estimate of 100 bytes per record (ID plus metadata), that's 30-45 KB per month of new data. The 102,400 byte ceiling is hit in roughly 2-3 months of moderate use.

I had looked at the limits during development. I had not done the arithmetic on how quickly a behavior tracker accumulates data. That is the specific failure of judgment that produced the bug: I was thinking about the data structure, not the data volume.

What server-side sync actually changes

The move to server-side sync, using PostgreSQL as the canonical data store, resolves the volume problem structurally rather than through workarounds. The database is not subject to per-extension storage quotas. A user with three years of watch history and detailed session records does not face truncation because storage is cheap and scalable in ways that browser extension storage is not.

But there is a more important difference than storage capacity.

Browser sync is eventually consistent by design. Chrome syncs chrome.storage.sync data on its own schedule, with no guarantees about when changes propagate across devices. For most extension use cases, this is fine. For a behavior tracker that is computing scores across your full history, eventual consistency introduces errors. A Clarity Score computed on Device A using a partial history sync from Device B is a wrong score. Quietly wrong, in a way that damages trust in the data.

Server-side sync with a single canonical store eliminates this class of error. Every device reads from and writes to the same database. There is no reconciliation problem. The data is always current because there is only one copy.

The multi-device case specifically

The use case that makes server-side sync most clearly necessary is switching devices mid-session. If you start watching YouTube on a laptop, step away, and continue on a desktop, or a different browser, or after reinstalling, the session continuity needs to survive that transition.

With browser sync, that transition breaks in subtle ways: the new device doesn't have the full session context, the Clarity Score for the session is computed with incomplete data, and the watched-videos filter may not have caught up with what you watched on the other device.

With server-side sync, the session data is in PostgreSQL. Whichever device you open YouTube on, the extension pulls the current state. The filter is current. The Clarity history is current. The transition is transparent.

The honest version of the lesson

I shipped chrome.storage.sync because it was easier. It saved me weeks of backend work. It let me ship a feature that sounded complete before the infrastructure was ready to support it properly.

The lesson is not that shortcuts always fail. Some shortcuts are fine. This one failed because behavior tracking generates more data than browser storage is designed to handle, and the failure mode was silent truncation rather than an obvious error, meaning users experienced it as bugs in the tracker's accuracy, which is the worst possible failure for a tool that depends on trust in its data.

If you're building any extension that accumulates behavioral data over time, the ceiling on browser storage is not a theoretical concern. It is a timeline. Plan for server-side sync before it becomes a production incident.

Multi-device sync is available on Gazenest on all plans. The architecture is built on PostgreSQL, not browser storage, so the history you're building is complete, consistent, and yours.