Real-Time Collaboration

When more than one author opens the same entry, Krios surfaces live presence and save broadcasts in the entry editor over a Server-Sent Events (SSE) channel, so editors can see who else is in an entry and know when someone else just saved.

This is an awareness layer, not a locking layer — it never blocks anyone from editing. Real conflicts are still caught by optimistic concurrency (the version field) on save.

Signals

Signal	Status	What it does
Presence	Live	A roster of who is currently viewing the entry.
Save broadcast	Live	Notifies other viewers when someone commits a save, so they can reload.
Per-field focus	Wired, not yet visible	The channel and endpoint carry field focus/blur events, but the editor does not render a per-field "X is editing" indicator yet (a polish item).

In the entry editor

• Presence avatars appear in the editor header — up to five circular avatars (initials), then a +N overflow pill. Hovering an avatar shows that viewer's name.
• An "Also viewing" banner lists the other current editors when at least one is present.
• A "Saved" toast appears when another user saves the entry — e.g. "Saved (v4). Reload to see their changes."

Your own session is filtered out of the roster you see.

How it works

• Transport: SSE. The editor opens an EventSource to GET /api/v1/projects/{slug}/entries/{id}/live, which streams presence, saved, and fieldFocus/fieldBlur events. A keepalive ping is sent every ~25s; a viewer is considered gone after ~60s without a heartbeat. The browser's EventSource auto-reconnects on drop.
• Save broadcast is fired as a side effect of the entry update (PUT /entries/{id}) — there is no separate endpoint to call.
• Field focus (awareness only) is signaled via POST /api/v1/projects/{slug}/entries/{id}/focus with { fieldApiName, action: "focus" | "blur" }.
• Auth: these endpoints require a signed-in admin session (API-key callers get a clean 401 and the SSE connection simply closes). They run through the same project resolution and IP-allowlist checks as the rest of the management API.

Operational note

Presence is held in process, in memory — there is no database or external pub/sub behind it. In a single long-running server it works as described. On multi-instance / serverless deployments (e.g. several Vercel lambdas), presence is only consistent among editors who happen to hit the same instance, and it resets when an instance recycles. Multi-region pub/sub (e.g. Redis) is a planned enhancement; the API is shaped so that swap is invisible to clients.

Lineage: real-time collaboration shipped in the V3 wave. Per-field focus indicators and multi-region presence are tracked V3.x polish/scale items.