Other programs 5 minutes read
OpenResults
The public results site
OpenResults is where players, parents and spectators follow a tournament on their own phones. They find the pairings, the results as they come in, the standings, a cross-table, a card per player, and a form to enter the tournament. It shows what OpenPairings sends it and computes nothing: the standings arrive already worked out, in the order the arbiter chose, and a round that was not published is simply not there.
When you need it. Whenever the tournament should be visible to anybody but the arbiter. You do not install it to publish: connect OpenPairings to a results site once and choose, per tournament, how public it is. It is a hosted service at openresults.cloud; its source is not published.
Where it fits. Publishing sends a tournament there; OpenResults: the public results site shows what the spectators see and what the arbiter controls. With electronic boards, Alnasl sends the moves to it while the games are played.
The public half of OpenPairings: published pairings, standings and player registration for a chess tournament.
It renders what an arbiter sends it. It computes nothing.
Why it is a separate thing#
An arbiter's tool and a spectator's page want opposite things.
| the arbiter | the public | |
|---|---|---|
| writers | exactly one person | none |
| readers | one | hundreds, in bursts |
| latency | instant, and offline-tolerant | seconds are fine |
| when it matters | during the round | after it |
| cost of failure | the round cannot be paired | somebody refreshes |
They used to be one process, which meant a chess venue's wifi - school gyms, hotel basements - could block an arbiter from pairing round 5, and a popular open's standings page was served by the same machine trying to run the tournament.
Splitting them lets the arbiter's side run entirely on a laptop with no network at all, and lets this side be cached hard and fall over without stopping anybody's chess.
What it does#
- Publish. Accepts a snapshot of a tournament and serves it: standings with the arbiter's chosen tiebreaks (a starting rank of every entered player, in place of the table, before round one), a page per round shown live as results come in, and a cross-table and a card per player that stop at the round the published standings reflect rather than racing ahead of them. A published round is immutable, so it caches for a long time.
- Registration. Takes entries from a public form and holds them in a queue. It never writes to a tournament - the arbiter's machine pulls the queue, and the arbiter decides who is in.
The arbiter chooses how much of it is shown. Ratings, titles, federations, clubs, categories, tiebreak columns and the player cards can each be switched off per tournament, and a tournament can be published without appearing on the front page at all. See OpenPairings' public-pages doc.
What it deliberately does not do#
- It does not calculate. Standings arrive already computed, tiebreaks applied, in the arbiter's chosen order - hand-set, if that is what they did, and the page says so. The arbiter's screen is the document of record and this page must never contradict the hall.
- It does not hold tournament state. It has snapshots and a registration queue. The source of truth is the arbiter's machine.
- It does not know who anybody is. No accounts, no sessions, no cookies on the reading path. The stats page counts unique readers per day from a hash under a salt that is thrown away each day; what is kept is in docs/privacy-retention.md.
- It cannot leak what it was not sent. An unpublished round and a hidden board are absent from the payload, not filtered on render.
Embedding#
Every page may be put in an iframe, so a club can show its own tournament's standings on its front page. Safe because there is nothing here to clickjack: no session, no login, and the two things that write take no authority from the visitor either.
PUBLIC_FRAME_ANCESTORS restricts it to an origin list, or 'none' to switch
it off.
Status#
In production. Publishing, registration, tournament keys, takedown, themes, per-tournament display rules and the FIDE search are all live and covered by the test suite.
A player's history across every tournament this server holds, found by FIDE
id, is also live: linked from a player's card when they have one, honouring
the same display rules, takedown and unlisting as everywhere else. See
OpenResultsWeb.PlayerHistory.
Before round one, the standings page shows the field in starting-number
order instead of an empty table. See Tournament.starting_rank?/1.
The standings table can be sorted by any column and filtered by club,
federation or category, entirely in the browser - the server renders one
table regardless of how it is later sorted or filtered, so the page cache
stays exactly as valid as it always was. A club or federation filter is
reflected in the URL and can be copied and shared. See
OpenResultsWeb.TournamentHTML.standings_table/1.
Every tiebreak value on that table opens, by tap or by keyboard, to the
per-round working behind it - the same figures the player page already
shows in full, reached with <details>/<summary> rather than a script.
See OpenResultsWeb.TournamentHTML.tiebreak_cell/1.
The front page groups its tournaments into live, upcoming and finished, and
can be searched, again in the browser. A tournament's group is derived from
fields the snapshot already carries - rounds published against the declared
total, and its own dates - never computed or stored. See
OpenResultsWeb.Tournament.status/2.
Licence#
OpenResults is closed source. Copyright (c) 2026 teapot-chess. All rights reserved. No licence is granted to use, copy, modify or distribute this software. It is run as a hosted service at https://openresults.cloud.