How Clipboard Sync Works: Events, WebSockets and Device Sessions

1. Capturing the copy

The page listens for the copy event on its own editor (MDN). It reads the selected text and lets the normal copy continue, so your local clipboard behaves as usual.

2. Writing it safely

The text is sent over HTTPS with an idempotency key, so a retry after a network glitch never creates a duplicate. The server checks who you are, validates the size, encrypts the content and stores it.

3. Ordering

Each change gets a per-account sequence number, allocated inside a database transaction. Devices apply changes in that order, which keeps every device's history identical.

4. Telling other devices

A small notification — not the content — goes to your other sessions over a WebSocket when the server supports one. When it does not, the app checks for new events every few seconds instead. Both use the same ordered event list.

5. Catching up

Each device remembers the last sequence it applied. After being offline it asks for "everything after N". If it was away so long that old events were pruned, it downloads a fresh snapshot instead.

6. Device sessions

Every browser you sign in on is a separate device with its own revocable session. Removing a device ends its access immediately and closes its realtime connection.

What this design avoids

• Duplicates from retries (idempotency keys).
• Missed items after sleep (cursor-based catch-up).
• Loops when the app copies to your clipboard itself (the app does not re-sync its own writes).