pheyvaer / solid-chess

A decentralized chess app build on top of Solid.

Solid Chess

This is a decentralized Chess game, build on top of Solid. No central sever is required to run or set up a game. All personal data about the game is stored on your POD. Requests to join a game are sent to the inbox of your opponent directly. You have two types of games: a non-real-time and a real-time game. With a non-real-time game all updates are sent to the inbox of your opponent, who can interact with it when (s)he wants. With a real-time game WebRTC is used to allow for a direct communication between two instances of the Web app.

The game is available in the browser and terminal. Check the live version or one of the following screencasts:

• non-real-time game via Web app
• real-time game via Web app
• non-real-time game via CLI

WARNING: The "Clear inbox" button removes all files with (chess) game data in your inbox! So be careful!

Documentation

• Code documentation can be found here.
• If you want to know more about how the application interacts with different Solid PODs, you can read this.

What you can do

• Create a new game, which will send a request to join to your opponent.
• Join a game, which will send a response back to your opponent.
• Continue a game you started earlier.

Used technologies/concepts/libraries

• Linked Data: to represent/share the details of the games
• Decentralization: information is fetched from different servers
• Solid PODs: store personal data about the games
• LDflex for Solid: simple access to data in Solid pods through LDflex expressions
• SPARQL: query/update games
• RDF: representation of the data
• Comunica: querying different data sources
• chess.js: chess engine
• chessboard.js: chessboard

Install

Web app

You can run the game locally by doing the following:

• Clone this repo.
• npm i: install Node.js dependencies.
• npm run build:web: bundle the JavaScript via Webpack. The result can be found in web-app/dist/main.js.
• Serve the contents of the root folder, e.g., via http-server.

CLI

• npm i solid-chess -g: install the game.
• solid-chess:launch the game.

Credits

• Freevector Chess Pieces Set (CC BY-SA 4.0, no changes were made)
• Font Awesome chess-rook icon (CC BY 4.0, no changes were made)

License

© 2018 Pieter Heyvaert, MIT License

solid-chess's Issues

Clean up WebRTC channels when ending real time game

give name to game

save start position when not default

put all namespaces in separate file

add RDF to index.html

Add a description (in RDF) of the application to the index.html.
Ideally, we would have conneg for the different RDF serializations, but we are currently serving it via Github pages, so that is not possible.

Catch error when unable to join real time game

selective "clear inbox"

only remove chess related files in inbox

save theme preference to POD

Relevant part of Solid spec: App Config Discovery (draft)

add resulting board layout (FEN) to move

Send notification if initiator stops setting up real time game

Use table to show join requests

At the moment we use a <select> for that, but it refreshes when new options are async added, which is annoying for the user. Also a table allows to sort and filter.

Check to use acl-check

https://www.npmjs.com/package/@solid/acl-check

Would be nice to see if we can use this library instead of the current, custom function that check if the user has write access.

read start position when loading game

add opponent's name to game name in continue menu

check who first starts when loading game

use websockets to detect new entries in inbox

Use websockets to detect new entries in a user's inbox instead of pulling. At the moment, however, I only get updates via websockets for ack and not pub.

EDIT: This the expected behaviour. At the moment you cannot get this information via websockets. It would be nice to have though, see this issue of the Node Solid Server.

remove join requests from inbox

Update screencast

The UI has been updated a bit, so we should make a new screencast.

allow to set read access to chess game info

For example, only your opponent can see the move you make and the rest of the world.

show name of person who send join request

Add fontawesome credits for the favicon and background image

Add credits for fontawesome for the favicon and background image to the README

write README

Tryout ldflex to replace simple SPARQL queries

support end of game

Include FEN as part of a DatatypeProperty

write "how it works"

Use pim:storage location to store the game

Auto-fill the the path to store the game based on user's pim:storage (if they have it of course).

Realtime chess

Can't you use solid'/Notification or solid'/websocket first to use realtime, and if the opponent is not connected send to mailbox ?

Update ontologies used for WebRTC messages

Store response to invitation in POD

Once a response to invitation is received, we also need to store the url of the response on the POD of the person who send the invitation.

Quit real time game when browser window is closed

Add Github link to index.html

Create footer on index.html and add a link to the source code on Github.

Use table to show games to continue

At the moment we use a for that, but it refreshes when new options are async added, which is annoying for the user. Also a table allows to sort and filter.

write end of game RDF

able to stop game

Just go back to home, do not forfeit or sth

Send acceptance of invitation

At the moment a player that joins a game only stores some game data on his POD and waits for updates, but never actually lets the other player know that he accepted the invitation. Therefore, we need to send a notification with the acceptance to the inbox of the other player. This is related to #32, because we also need to model how you accept/refuse requests.

ontology for join requests

At the moment we use http://example.org/game/ as namespace for join requests. Thus, we need a real ontology to model the requests to join the game. We either find an existing one or make one ourselves.

Check with LDN test suite and submit an implementation report

How conforming is the application as per LDN's Sender and/or Consumer?

If possible, would you like to submit an implementation report at https://linkedresearch.org/ldn/tests/ (see links to sender and consumer tests)? It will immediately appear at https://linkedresearch.org/ldn/tests/summary after the report is sent. Thanks!

add sender verification

Write blog post about centralization vs decentralization

Write a blog post that compares centralization and decentralization in the context of a chess game.
Read this first.

Use schema:contributor to state in which games a player participates

This is stored in the WebId using a custom predicate. I think schema:contributer is better.

mobile design

Add documentation

At the moment there is basically no documentation in the code. Not good.

Use FEN for move hash

Create safe URI fragments using https://en.wikipedia.org/wiki/Forsyth%E2%80%93Edwards_Notation for the moves.

add another set of chess pieces

add install instructions

check if url already defines a game when creating a new game

use GraphQL-LD instead of SPARQL

This would remove the need to convert the SPARQL results to JSON objects.

add favicon 👨‍🎨

Add tests with a local instance of NSS