BoostBracket

Rocket League runs Easy Anti-Cheat online, where BakkesMod is neither permitted nor functional. Reading live game state therefore requires the organiser to host a local match that players join by direct IP - which is a support burden, so the platform documents the three steps publicly and stores the address and port encrypted per match, visible only to the assigned players and staff.

A bridge on the host machine reads the SOS plugin and posts the score to the API, which commits it and broadcasts to overlays and public pages. The chain is: game to BakkesMod to bridge to an ingest endpoint to an outbox event to every connected client.

The token that bridge uses is scoped to one match, expires within a day, is revocable, and is displayed exactly once. It carries a bearer credential and no cookie, so it is outside the session and CSRF surface entirely. Crucially it cannot submit, revise or finalise a result - and the referee who created it stays the audited actor, re-authorised on every call, so removing their role stops the feed.

Observed games are advisory. They pre-fill the referee’s result form so it is confirmed rather than retyped, and they are stored separately from the dual-confirmed records that actually decide the bracket. Automation that quietly becomes the source of truth is how a tournament ends in an argument.

REST snapshots stay authoritative. A domain mutation writes an outbox event inside the same database transaction that made the change, and only then does Socket.IO broadcast a typed notification through Redis. Clients treat those as hints and refetch on reconnect or when they notice a version gap.

The alternative - trusting the socket to carry state - produces a bracket that disagrees with itself the first time somebody’s wifi drops mid-match. Here the worst case is a client that is briefly stale and knows it.

The media path is direct WebRTC playback plus browser or OBS publishing through LiveKit. Recording and HLS exist as obvious next features and are deliberately not exposed, because their storage, consent, egress and delivery lifecycles are not implemented and verified end to end.

Similarly, the API refuses to start in production without a real session secret, non-development database and Redis URLs, private object storage, secure cookies and development auth switched off. Sign-in runs an authorization-code flow with state, PKCE and a single-use server-side record for every provider, and an unconfigured provider is refused with a 503 rather than half-working.