How to implement a football league, where anyone can join, players of the league play with who they want, where they want, plus maintaining a global rank of each player who registered. Sort of chess.com but for football.
First how does a regular football league work: there are a set of selected teams, the administrator of the league schedules the whole season in advance. To win the competition you need to accumulate the most points:
In our case, we want the league to be accessible by anyone who wants to register, meaning that the number of participants grows dynamically, and the games are scheduled by the users themselves. Ranking can therefore not be based on points, which will just reward playing a lot of games; we will use Elo.
How do we ensure the data is not corrupted, how can we trust a certain score or result? If anyone can curl our endpoints and just send whatever they want.
We can use cryptographic signatures to ensure only certain specified hardware can access the server, that we hardcode on both the server and the device. Here is how it can work: instead of the user creating and managing their team (creation, handle recruitment, quit, ban...) as well as scheduling the game with the other team to which we need to implement an RSVP system (we are essentially reinventing a messaging app) and using a voting system to determine the winning team which will inevitably lead to a lot of unresolvable conflicts.
Let's say that there are no fixed teams. Users schedule their games outside the app in their preferred manner, they meet and register a game using software and hardware we (the league) provide. The software will send signals to the hardware, the hardware will receive an array of players that it will cut into two random opposing teams, calculate Elo for each user, start a counter and count the score (goal line technology) then sign and send the final game result to the server using pre provisioned crytpographic keys. In some sense, it can be thought of as a layer that sits on top of regular games the people already play — we just add this step where they mount the hardware and register their game for it to be counted in the league.
In football there are two goals, this means that we need two modules for each goal. One "master" that will handle communicating with the user, the server and counting the score. And one "slave" which only counts the score and communicates with the master.
Master needs to authenticate to the server to ensure the data it sends is trustworthy. Slave needs to authenticate with the master to ensure the data it sends to the master is trustworthy.
Therefore we need to introduce a stage before shipping the device to the end user:
Each pair of devices is associated.
On the other hand, and in order to use it, the user will need to register or authenticate to the server. We will abstract the auth details for now.
After this is done, the user can open both devices; there is no order in which they must be opened (can open the master before the slave or vice versa). The two devices will now start a local handshake. The slave will start a Wi-Fi hotspot, the master will connect to it. They will start a TCP socket, the slave will advertise its device ID; if it matches the device ID associated to the slave hardcoded into the master device, the handshake can continue. Then the master will send a challenge to the slave (to prevent replay attacks), the slave will sign it using its hardcoded key and return it. If the verification is successful (via the hardcoded slave public key on the master device) the local handshake is considered completed and the slave's authenticity is attested. The TCP socket is maintained.
The master device will start Wi-Fi hotspot mode, and broadcast a predefined SSID with no password, to which users will connect. Once connected, the users will need to verify the authenticity of the master device (and by verifying the master they can in consequence determine authenticity for the slave).
At the end of the process, the user will know if they are interacting with official hardware and firmware. They can now safely send their info to the device (user_id, username, elo, k_factor); internally the device will build an array of connected/registered players. This process happens for each user.
The device fully trusts user input, because the integrity of the sent data will
be verified at the end of the game on the server, invalidating the game if data does not match.
We exclude from this process matching the username. Usernames can be modified in-game causing a race
condition (user sends username to device → user modifies their username → device sends the match result
with the old username).
Users can now interact with the device to change their status from connected to ready. Once a user has checked "ready", it is not possible to turn back; if they quit or their connection is lost after n time, they automatically lose the game. Once 10 users are ready:
At the end of the main game timer:
It is therefore crucial for users to have a proper cellular connection. We exploit users' cellular connections to ensure they do not have to pay an additional cellular subscription for the device to access the internet. We could use Wi-Fi, but it would put a constraint on the places users can play.
First we need to define the constraints:
All design, code and writting was done by hand. AI was used for research.
For questions or to be updated for the release, contact me at [email protected]