Hi all, I would like to share with you another PoC build on Solid: a Chess game! ♜ All personal data about the game is stored on your POD. Requests to join and updates of a game are sent to the inbox of your opponent directly. A game can easily be reconstructed by following the links that describe the moves that the different players make. Note that each player stores the details of his move himself. There is just a notification send to the opponent that a new move has been made. There is a live version and screencast available, together with the source code. Have fun playing! 
And as always feedback is welcome!
8 Likes
Wow, that’s pretty cool! Lots of room for cheating though now it is your data and not a secure server’s … I guess I can always modify the game data through the data browser.
1 Like
Yes you can modify the data. That’s why I was thinking of adding a hash of all moves to both PODs. That way when reconstructing the game you know when your opponent changed something, because the hash will not longer be the same.
On the other hand - if you only transfer “I make move” (which I didn’t realize at first) and do not share state, then the receiving client can always reject an illegal move. I guessed that the two clients was looking at the same shared chessboard data.
Yes, at the moment the engine (chess.js) will indeed reject invalid moves. But when reconstructing a game (when you for example continue a game that you playing later on) you would still need some validation to see that original board is displayed.
Neat!
Some important tips for Solid apps:
- Discover preferred data storage location by looking up the WebID-Profile Doc of each player i.e., de-reference URI after successful authentication
- Hyperlink player name with their WebID – currently the system is showing https://pheyvaer.github.io/solid-chess/# irrespective of what WebID I authenticated with.
Note the MarkBook App which implements the tips above 
Hi Kingsley,
Thanks for the feedback.
- Is this related to
pim:storage(related issue on Github)? - Could you elaborate on this a bit more? What do you expect here exactly? So you are logged in with multiple users and the application should select the correct one based on the WebID that appears after the
#in the URL?
I can’t help thinking about ways to cheat and secure the game, sorry It needs to be protected from rogue moves from other players - is there some sort of validation of who is adding the move? You might want to exchange some sort of secret at the start and use that to sign moves from both parts - otherwise a third player might corrupt the game by inserting a move on behalf of one of the original players.
Don’t worry. This is one of the things that I was also thinking about when coding. At the moment when reading the inbox, no check is performed on the origin of the notification. Thus, someone else could act as your opponent. One way here to address is to sign the notification with your private key, so that we can verify that you are the real sender of the notification. This and more is described at the spec of LDN. Note that I still have to check whether the app conforms this spec, but it provides ways to do sender verification.
1 Like
All you have to do is discover the preferred data storage location of the user. The relations in question from the WebID-Profile doc are:
- ldp:outbox – public
- ldp:inbox – private
The WebID of a logged in user should always be anchored to the literal identifier (label) . Why? That enables lookups and serendipitious discovery that starts from said users WebID-Profile doc.
Solid enables use of a WebID-Profile doc as a powerful tool for exposing and controlling preferences too
1 Like
Hmmm, what does “anchored to the literal identifier” mean?
ldp:inbox is already used to get the inbox of the user, but what is the purpose of ldp:outbox? It is not describes on the page of the ontology.
Regarding the WebId, why would you wanna do lookups? I mean, at the moment it only make sense to add user-specific data to the app the moment a user is logged in, and at that point you know the WebId through the session.
I didn’t know about LDN before so I asked Sarven Capadisli on the Gitter chat;
What is LDN exactly? Would passing these tests be a requirement for all SOLID based apps?
He replied:
Start quote—
Good question! Short answer: no. LDN ( https://www.w3.org/TR/ldn/ ) is a simple notification mechanism. An application can fulfill one or more roles: sender, receiver, consumer. A Solid server (or a Linked Data Platform) implementation for instance is an LDN receiver (out of the box). There is no requirement that “Solid based apps” must conform to LDN. As far as a Solid server implementation is concerned, an Inbox is just a “container” (a directory/folder…) and the resources in that container are notifications. Notifications can contain any information , so applications ultimately decide for themselves as to what to send and consume. Kind of a ‘social’ agreement if you will. So, if you want to write applications where they can send and consume each others notifications in a uniform way, I’d suggest to implement LDN. It is a super simple protocol (to implement), and most of it is just basic HTTP communication. Here are a list of applications that have submitted a test report: https://linkedresearch.org/ldn/tests/summary
Let’s have an example:
@pheyvaer built a cool chess game. It sends notifications to your opponent to indicate that there was a move, and it gets consumed (reused) by the application to show the new move for the opponent.
Now, in the Solid ecosystem, two parties are using the same application with their respective personal storage.
Another way is where each player uses their own preferred application to play the same game! Everything else stays the same.
So, if those (at least) two applications agree on LDN, then the communication can take place automagically.
— End quote
Thanks @csarven ; sounds great and I’ll check those references. Will also follow the issue #22
Love how solid brought all these cool (new) web technologies to my attention!
3 Likes
I’ve seen on the chat some discussion about how applications should/can/will work with Solid PODs.
Therefore, I’ve created a document where I describe how my chess application interacts with the different Solid PODs of the players
4 Likes
Put differently, use the pattern:
User Literal Identifier or Label or Name
Which makes discovering and looking-up the users WebID-Profile doc much easier. Fundamentally, we want a WebID-Profile document content to inform both users and application behavior.
I am trying to say the pattern should be:
<a href="{user-webid}">{object-of-foaf-name-relation-from-webid-profile-doc}</a>
Thus, when I login I would see the following for the logged in user:
<a href="https://kidehen3.solid.openlinksw.com:8444/profile/card#me">Kingsley Idehen</a>
Effect, courtesy of markdown: Kingsley Idehen
A new version of my Solid-based chess game is out! 
The most important addition is the ability to play a game of chess in your terminal 
You can dive right in via npm i solid-chess -g or check the screencast at https://streamable.com/x7fo0
With this I wanted to show that you cannot only build great browser-based applications using Solid, but also others, such as CLIs. You can find more info at https://github.com/pheyvaer/solid-chess
As always, all feedback is welcome!
7 Likes
So had some more fun with this chess game and added real-time cross-browser communication via WebRTC , where the Solid PODs of the players are used to set up the communication , i.e., the PODs act as the signalling server. This shows that Solid PODs can replace the currently required third-party servers to set up P2P connections. A screencast can be found here https://streamable.com/j951d (but to be honest, the only thing you see here is that it works faster than via the inbox of the PODs 
) Those who are interested in the code can have a look at https://github.com/pheyvaer/solid-chess/blob/master/lib/webrtc.js FYI I need to have a closer look at the proper ontologies to store the details about the connections.
6 Likes
I’ve summarized what I explained and discussed in my presentation (about Solid Chess) at Solid World last week in a blog post https://pieterheyvaert.com/blog/2019/02/10/solid-world-summary/
UPDATE 2019-04-01
Hi all, I’ve just published a new blog post explaining the interactions between my Solid app and Solid PODs. It describes in detail the different actions that users can take and how this is translated in steps taken by the app and PODs, including example RDF and SPARQL queries. https://pieterheyvaert.com/blog/2019/03/30/solid-chess-interaction
5 Likes