The Time Problem

Live and offline are not two separate product modes. They are two views of the same shared timeline.

A useful collaboration system has to answer ordinary questions: what happened before I arrived, what changed while I was away, what did I edit locally, what changed remotely, and what should happen when those histories meet?

Three Concrete Cases

A meeting should not become opaque because someone joined late. The late user needs enough retained state to catch up: what was said, what was decided, what is live now, and where the current conversation connects to the earlier part.

A collaborative document should not treat offline edits as an embarrassment. The system should know the base version, local changes, remote changes, and the conflict shape well enough to offer a merge path instead of dumping responsibility onto the user.

A team workspace should not become unusable because a network changed. Tabs, documents, messages, and task state need a local view that can reconnect, refresh, and reconcile from the state the user actually had.

State The Product Must Keep

Failure Mode Avoided

The weak design assumes everyone is always online, always current, and always looking at the same state. That makes the software simpler until real work happens.

Real collaboration includes absence. People miss meetings, edit documents on airplanes, reopen old tabs, reconnect through bad networks, and return to projects after decisions have moved on. The product either carries that time structure or forces people to reconstruct it manually.

Original Post Context

The original post asked why a user cannot move cleanly between recorded time and live time, or return from offline editing into a merge UI that reflects what actually changed.

The cleaned-up architecture point is simple: collaboration software should treat time, absence, and reconnects as first-class product state.