Drawpile is the most mature open-source multiplayer drawing system — hundreds of concurrent users, real-time collaborative painting, pressure-sensitive tablet support, cross-platform. It is the closest existing system to what Codrawer needs to become on the networking side, and its architecture is worth understanding in detail because it solved problems Codrawer has not yet faced.
Command replay
Drawpile is a command-replay system. Session history is a sequence of drawing commands — penmove, penup, fillrect — that can be recorded and replayed to produce the same canvas. The server is deliberately dumb: it does not understand drawing semantics; it receives opaque messages, assigns them a canonical order, and relays them to every client. Clients render locally. This is structurally identical to what codrawer-bridge does with stroke_begin/stroke_pts/stroke_end: the server is a switchboard, not a renderer.
Retcon and consistency
Where Drawpile gets hard — and where Codrawer will eventually need to go — is consistency under concurrency. When Alice and Bob draw at the same time, their commands arrive at the server . Drawpile handles this with a mechanism it calls retcon: each client applies its own strokes immediately (no waiting for the round trip), maintains a “local fork” of uncommitted commands, and when a non-concurrent command arrives from another user — meaning the bounding rectangles overlap — the client rolls the canvas back to a savepoint, replays history in canonical order, and moves the local fork to the end. The key insight is that most concurrent drawing is actually commutative (strokes in different regions), so rollback is rare. Drawpile optimizes for the common case that artists naturally avoid drawing over each other.
Cross-user undo
Drawpile's undo system is the other lesson. Because commands stream incrementally (penmove by penmove), the protocol has explicit UndoPoint markers that demarcate undoable regions. Undo across multiple users works by marking one user's commands as “undone,” rolling back to a cheap copy-on-write snapshot, and replaying only the non-undone commands — so Alice can undo her line from underneath Bob's without creating a hole in Bob's work. Canvas snapshots are cheap because Drawpile uses COW tile storage: copying a layer copies only metadata until a tile is actually modified.
Where Codrawer stands
Codrawer does not yet have retcon, rollback, or cross-user undo. What it does have is structural readiness. Multiple WebSocket clients on one session_id already see the same stroke and the same layer. User strokes carry IDs; the broadcast excludes the sender; the AI layer is distinct from all user layers. The path from here to Drawpile-grade multiplayer is real engineering — savepoints, local forks, COW state management — but it is not a redesign. The harder problems are the ones Drawpile never had to solve: what happens when the AI is also a participant? How do you undo AI suggestions without breaking the user context they responded to? Who controls the ghost layer when two humans are drawing and the AI is trying to help both of them? What happens when a symbol one person invented is used by another, and the system needs to decide which interpretation to compute against? Those are the social and semantic questions that make this genuinely new territory. Drawpile shows how far you can get with a clean command-replay model; Codrawer picks up from where Drawpile stops — at the boundary between canvas and computation, between broadcasting strokes and interpreting them.
Next deep dive
Vision — Gestural delegation, mark vocabularies, sketch-to-CAD, and staying in the sketchworld — the forward-looking argument for sketch computing.
Or explore: Lineage, Infrastructure.