Views: onion skin and redline

decided as a requirement, draft in detail.

Collaborators need to see edits before they merge. Neither the original design handover nor most CRDT libraries cover this, so it is a core requirement here.

The views

Onion skin : A translucent overlay of another state drawn over the current one: a session over its parent, a paused queue over the live document, or another connection’s session that hasn’t been merged yet. Every session can be shown as an onion skin.

Redline : A per-author tracked-changes view. For a session, it is the set of operations that a merge would replay, coloured by who made them.

Paused queue : A local session whose automatic merge is switched off. Its edits show as a translucent preview over the live document, and releasing it is an ordinary merge.

Session preview : Any session rendered on its own or over its parent, for review before merging.

Prior art: onion skinning comes from traditional animation, and the redline from word processors’ tracked changes (prior art).

Who renders them

All views belong to muppet. They are ephemeral changes to the displayed tree and never change the state of the session being viewed.

That holds wherever a muppet runs:

in Inkscape, the views draw on the canvas
in the browser via Wasm, they draw in the page
on the server for a no-JS browser, they are rendered as plain SVG layers and HTML

Because server-side rendering is just a server-side muppet, the no-JS view and the native view come from the same code.

What the engine must provide

Authorship on every operation, kept after merging, so a redline can say who changed what.
A state per session, so a preview has something to overlay.
Cheap diffs between two states, so a redline can be computed on demand.

Still open

Should the onion skin show live in-flight edits from other people, explicit suggestions that need accepting (like tracked changes in a word processor), or both?
How redline colours map to authors in a room with many participants.