Build a realtime multiplayer whiteboard and know where it breaks

Build a realtime collaborative whiteboard prototype in Bolt.new where up to 8 people can draw on the same canvas at once and see each other's strokes appear live.

CORE INTERACTION
A shared canvas where each connected user can draw freehand strokes in their own assigned color, see a live cursor position for every other connected user labeled with their name, and see strokes from other users appear within roughly half a second of being drawn, not after a page refresh. Drawing tools: pen, eraser, and a color picker with 6 preset colors.

REALTIME TRANSPORT — NAME THE ACTUAL MECHANISM
Bolt.new's WebContainer has no realtime server of its own, so pick one explicit mechanism and use only that one: Supabase Realtime channels (broadcast, not the Postgres changes feed) connected directly from the Bolt.new frontend. Every stroke event and cursor-position update goes through this single channel — do not build a hybrid where some updates go through the realtime channel and others are inferred from local state, since that's exactly how two users' boards silently drift out of sync with each other.

CONFLICT AND ORDERING RULES
State plainly which of these two behaviors you're building, since they produce different results under real concurrent use: (a) last-stroke-wins on any shared object, appropriate here since strokes are additive and don't really "conflict" with each other the way, say, two people editing the same text field would, or (b) an explicit ordering by a server-assigned sequence number so every client renders strokes in the same final order even if network latency delivered them out of order. For a drawing app, additive strokes rendered in receipt order per client is normally fine — call this out explicitly rather than silently reaching for a more complex CRDT approach the app doesn't actually need.

DISCONNECTION AND REJOIN
When a user's connection drops, their cursor should disappear from other users' views within a few seconds — via a presence heartbeat or timeout, not by staying stuck on screen forever. When a user reconnects or a new user joins mid-session, they must see the current full state of the board, not just strokes drawn after they joined — this needs either a periodic snapshot of the canvas state or a full stroke-history replay on join; name which one you're building.

HONEST LIMITATIONS
8 concurrent users on one board, sessions under 30 minutes is the realistic upper bound for this prototype. State plainly, in your own output, what would actually break first if usage grew past that — the realtime channel's message rate, the size of the stroke history being replayed to new joiners, or something else — rather than presenting this as infinitely scalable just because it works in a two-tab test.

CONSTRAINTS
plain white canvas, minimal floating toolbar, no branding chrome Skip user accounts — a name entered on join is enough identity for this prototype.