OpenPairings

Andere programma's 5 minuten lezen

OpenResults

De publieke uitslagensite

Op OpenResults volgen spelers, ouders en toeschouwers een toernooi op hun eigen telefoon. Ze vinden er de paringen, de uitslagen zodra ze binnenkomen, de stand, een kruistabel, een kaart per speler en een formulier om je in te schrijven. Het toont wat OpenPairings stuurt en rekent zelf niets uit: de stand komt al berekend binnen, in de volgorde die de arbiter koos, en een ronde die niet gepubliceerd is, staat er gewoon niet.

Wanneer je het nodig hebt. Telkens als iemand anders dan de arbiter het toernooi moet kunnen zien. Om te publiceren hoef je niets te installeren: je verbindt OpenPairings één keer met een uitslagensite en kiest per toernooi hoe openbaar het is. OpenResults is een gehoste dienst op openresults.cloud; de broncode is niet gepubliceerd.

Waar het past. Publiceren stuurt een toernooi erheen; OpenResults: de publieke uitslagensite toont wat toeschouwers zien en wat de arbiter bepaalt. Met elektronische borden stuurt Alnasl de zetten erheen terwijl er gespeeld wordt.

De rest van deze pagina is alleen in het Engels beschikbaar.

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 arbiterthe public
writersexactly one personnone
readersonehundreds, in bursts
latencyinstant, and offline-tolerantseconds are fine
when it mattersduring the roundafter it
cost of failurethe round cannot be pairedsomebody 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#

  1. 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.
  2. 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.