Interactive Whiteboard Overview
Product overview, architecture, room model, realtime path over LiveKit and server persistence.
Interactive Whiteboard is one of the ni-meet product lines: whiteboard rooms, scenes and strokes are persisted by the control plane, and a realtime data channel fans the incremental changes out to every member in the room. It does not need a whiteboard-specific media server — voice and video in the room keep running on the RTC channel.
Product positioning
- Persistent: scenes, strokes, images and viewport are stored by the control plane and stay readable until the room is closed; snapshots and replay remain available afterwards.
- Replayable: every change is appended to an operation log with a monotonic sequence number, and the replay endpoint returns operation frames with time offsets that a player can pause, seek and end.
- Authenticated: project credentials authorise server-to-server calls; room tokens are bound to one room and one role (
admin/writer/reader) with a controllable lifetime. - Observable: the room version increments on every mutation and the operation sequence is monotonic, which makes reconciliation and de-duplication straightforward.
Architecture
Browser / mobile WebView
│ ① REST (scene and content persistence)
│ ② LiveKit data channel (topic = whiteboard, low-latency broadcast)
▼
ni-meet control plane ── whiteboard service ── rooms / scenes / strokes / operation log
│
└── snapshot export (JSON / SVG) and replay timelinePath ① is the source of truth: late joiners, replay and export all read from the control plane. Path ② exists for latency only; if a packet is lost, the next REST sync or state refresh reconciles it.
Capabilities
| Capability | Description |
|---|---|
| Room lifecycle | create, list, detail, ban/unban, permanent close (read-only afterwards) |
| Scenes (pages) | scene paths /dir/page, background images, insert and switch |
| Scene content | strokes (pencil, eraser, rectangle, ellipse, shape, laser pointer and more), images, viewport |
| Undo/redo | isolated per member, with the full operation log retained server-side |
| Snapshot/export | full JSON snapshot (including the operation log) and per-scene SVG |
| Replay | operation frames and offsets for an optional from / to window |
| Room tokens | NETLESSROOM_* with controllable role and lifetime; project tokens use NETLESSSDK_* |
Relationship to RTC
A whiteboard room and an RTC channel are separate concepts: the room has its own UUID and can be attached to any channel name or lesson. The usual pattern is to join the RTC channel for voice/video, then join the whiteboard room with a room token; both tokens are minted server-side with the same project credentials.
Current boundaries
- The server does not convert documents (PPT/PDF to images): the caller uploads the background and references it by URL in the scene.
- Scene deletion and page reordering are not part of the server surface; clients can still clear content or switch pages.
- The operation log keeps the latest 10 000 records per room; earlier records stop participating in replay.
- The whiteboard service uses the platform storage abstraction; the default in-memory implementation is cleared on restart, so production deployments must provide a persistent store.
Version history
- Version 0.9.0 2026-10-20 — Initial whiteboard overview (pre-GA).