[Feature]: venue/projector mode

[tbcsec]

Before you start

• I searched existing issues and this isn't already requested.

What problem does this solve?

Allows for big events to put the competition up on the big screen. a rotating scoreboard, live solve tracker, first-blood splashes, announcement takeovers, live competition insights.

Proposed solution

Extension of the existing /public/<competition_id> endpoint most likely. Make sense for it to live in the same place if it's displaying similar information. Could be a toggle on that page to switch between static view, and venue mode.

Alternatives considered

No response

Rough size

Medium (a new screen / endpoint)

Contribution

• I'd be willing to help implement this.

[tbcsec]

Triage

What's being asked

An unauthenticated big-screen "venue mode" for in-person events: a rotating display cycling the scoreboard, a live solve tracker, first-blood splashes, announcement takeovers, and competition insights. Proposed as an extension of the existing /public/ surface, toggleable between the current static view and venue mode.

Module(s) affected

This spans several modules, which is why it's labelled cross-cutting:

• scoring — backend/routers/public_scoreboard.py is today's entire public API surface (board + CTFtime feed, gated on public_scoreboard opt-in). Venue mode needs additional public-safe endpoints: recent solves, first bloods, and whatever "insights" make the cut (utils/analytics.py computes them but routers/analytics.py is staff-gated).
• announcements — backend/routers/announcements.py is authenticated-only; a public takeover means deliberately exposing announcement content, likely behind a per-announcement or per-competition flag.
• WebSocket layer (§4.1) — the public page currently polls every 30s (usePublicScoreboard); "live" solve tracking and splashes want either aggressive polling or the platform's first unauthenticated WS room. That's a real architectural decision (auth is baked into the §4.1 connection flow) and probably wants an ADR.
• Frontend — frontend/src/app/public/[competitionId]/page.tsx + a family of new venue components (rotation controller, splash overlays, takeover layer).

Missing information

• Which widgets are in scope for v1, and is the rotation order/cadence fixed or organiser-configurable?
• Is live (WS) delivery a requirement, or is short-interval polling acceptable for a first cut? This is the biggest scope lever.
• Are announcements safe to show publicly as-is, or does this need an "also show on venue screen" flag per announcement?
• Should venue mode be its own per-competition opt-in, or implied by the existing public_scoreboard toggle?

Duplicates

None open. Closed #24 (public scoreboard improvements — full width, insight cards, timeline graph) shipped the groundwork this would build on.

Sizing note

Filed as Medium, but the unauthenticated-live-updates question plus multiple new public endpoints and a new display subsystem push this to size/large — if v1 is scoped to polling + scoreboard/solves rotation only, it could shrink back to medium.

---

Generated by Claude Code