Collaborative Canvas blueprint

This is a design blueprint, not a shipped example. It describes a recipe for a shared canvas whose objects are CRDT-backed game entities.

Model

Represent each drawable object as an immutable token record: stable ID, owner, shape, bounds, z-order, and version/provenance metadata. Use a Space for named regions or a token map when concurrent occupancy must preserve every object. Store comments, selections, and presence separately from durable art.

Invariants should be explicit: IDs are unique, coordinates are bounded, deleted objects have tombstones, and derived indexes can be rebuilt. Concurrent moves need a declared policy (for example, preserve both versions and show a conflict, or use a deterministic register); do not quietly call last-write-wins "consensus".

Authority and fit

Every client can author a mergeable edit in a peer model. A moderation or export service may still be authoritative for permissions, quotas, and publication. HyperToken does not make a modified client honest, and an unauthenticated relay only routes messages. Use an authoritative service when edits must be accepted or rejected centrally, or when large documents and abuse controls dominate.

The blueprint is appropriate for offline sketches, annotation, and replayable collaborative spaces. It is inappropriate when pixel-level media, strong access control, or a mature presence/graphics stack is the primary problem.