The problem Chessman solves

The world chess federation (FIDE) which is the international organization responsible for maintaining chess ratings and giving titles such as Grandmaster etc. faces a lot of corruption and cheating allegations in the present as well as in the past.

This highlights the need for a global chess rating authority which maintains and awards chess ratings which is trustworthy, reliable and transparent.
Chessman aims to solve this problem along with serveral others faced by professional chess players using web3.

It will maintain a list of ratings of all registered players. The only way for a player to change their ratings is if they (both black and white) submit their game in "pgn" format. Upon reviewing the game the chessman admin account i.e. the owner of the smart contract can change the ratings.
Also note: a game can be marked complete only when both players submit the same movesheet.

But wait, there's more to this.
We strongly believe that the data of the games played by players belongs to them and is not to be sold for profit by various chess database companies without compensating the players like it happens today.

So each game submitted to chessman is encrpyted and the decoded just by the admin, and players. Rest of the world can only verify that all three parties have the same copy of the game.

Verification:
In order to verify the moves of the game, any account can submit an access request and obtain an encrypted copy of the moves that is encrypted using their personal public key and can only be viewed by them. In this way anyone can check whether the moves played by a player were made using a chess engine and also if the rating awarded to them by Chessman admin is inline with rating algorithms set by the the community.

Challenges we ran into

The cryptography was the most difficult part for us to figure out.
We needed a way for players to tell the admin that they played a game, both of them should agree that this was the game played also these moves should only be visible to those who have been granted the permission i.e. admin, players and verifier account.

We could not use a symmeteric encyption because that would require sharing of a shared secret key between the parties and create open ways to game the rating system and break the trust of the system.

We decided to use RSA which is an asymmetric method, this would however require changes in the contract and users flow. Where a game will need approval of the admin to begin and the admin will only approve after generating a unique public-private key pair.

Another problem we ran into was the limit of encrpytion of rsa, which we solved by breaking the game moves into chunks, encoding them, stichking the chunks back. The decryption also working similarly.

The next step was representation of the game.
This was inpart soved by the cryptography because using the same public key can only generate same encrypted data if initial data was the same i.e both players submitted the exact same moves.