Concepts
Timelines are the evidence layer in Blue. If documents define participants, rules, and state — timelines define what each participant actually did.
A timeline is:
prevEntry.blueIdConceptually, it is a participant's verifiable history of actions. If an action is not on a trusted timeline, it did not happen as far as the document is concerned.
Without timelines, documents would just be rules and state. You would still need to trust some hidden system to tell you who did what. Timelines solve that by making actions attributable, inspectable, permanent, and suitable for deterministic processing.
Every entry uses the base type Conversation/Timeline Entry from repo.blue. The minimum useful entry looks like this:
type: Conversation/Timeline Entry timeline: timelineId: owner-1 prevEntry: blueId: <blueId of the previous entry on this timeline, or omitted for the first one> timestamp: 1731978000000000 message: type: Conversation/Operation Request operation: increment request: 1 actor: type: Conversation/Principal Actor accountId: alice
timeline.timelineId — which timeline this entry belongs to. Documents bind their channels to specific timeline ids.prevEntry.blueId — hash-link into the previous entry. The first entry on a timeline omits this field. Together with BlueIds, this turns the timeline into a tamper-evident chain.timestamp — when the entry was created (microseconds since epoch is a common convention).message — the payload. Often a Conversation/Operation Request, but any Blue node is allowed (chat messages, status changes, etc.).actor — who performed the action. Usually a Conversation/Principal Actor or Conversation/Agent Actor (see actors and trust).The message may be wrapped with provider-specific metadata in some environments (for example MyOS adds an envelope around the entry). The protocol-level entry is what processors see.
Timeline providers usually carry an extra signal about where an entry came from: a browser session, an API client, a request triggered by another document, or a provider-specific mechanism. That information is not strictly part of the base entry type, but it is critical for trust attribution. See timeline providers.
Blue does not force one global ledger.
Documents then combine these perspectives in a deterministic way. That is a very different trust model from a blockchain.
Timeline providers verify identity, assign and store entries, provide timestamp ordering guarantees, attribute actors, and make entries queryable to processors.
One of the key challenges in Blue: how can multiple processors, observing multiple timelines, reach the same conclusion? The answer is not "global consensus." It is a more local trust guarantee from timeline providers about ordering and completeness. The deeper explanation lives in the timelines white paper.
The document stepper creates demo timelines locally in your browser session. It mints a timeline per channel, computes BlueIds for entries, and chains them via prevEntry.blueId exactly as a real provider would. It then submits each entry to the published Blue document processor and shows you the resulting state.
The stepper does not pretend to be a real timeline provider — there is no identity assurance, no ordering guarantee beyond your local session, and no completeness signal. It is a learning surface. Real worlds use real providers.