nips
nips copied to clipboard
NIP-64: Chess (WIP)
Work-in-progress.
Reserving kind := 30 for messages representing Chess games/moves or general mechanics to represent text-based games.
This is currently used by Jester app:
- Code: https://github.com/jesterui/jesterui
- Demo: https://jesterui.github.io/
Not yet clear on what format to settle to be future-proof and/or to support all kinds of different game mechanics.
e.g. from the SGF format Wiki page:
The main purposes of SGF are to store records of played games and to provide features for storing annotated and analyzed games (e.g. board markup, variations). It is a text-only, tree-based format. The tree structure makes the addition of variations simple. It is also text-based instead of binary for the sake of portability.
Why is it preferable to use a kind over a tag? I would imagine that a tag could add more value as it could include metadata like the guid for the game for which the event is for.
I'd settle for a very quick description of the events, no need to write an article about motivation, abstract, nothing. You can just say: "This is a NIP that standardizes chess games over Nostr", but not even this is needed. If the title says "Chess" everybody already knows what to expect.
A link at the end to your implementation settles any remaining doubt.
No need to think very much about future-proof. The simplest thing is better. Isn't the SGF format good? I think it is good, but I'm not a chess player.
imo this is too specific. Maybe we could reserve a kind for "game event" or even "app-to-app data" where the content is arbitrary app-specific data, and it requires a unique tag like "chess-v1" or something.
Nevermind, SGF is for Go. Is this NIP about Go? I think Go would be a different kind, even if very similar to this. The same app will not implement both Chess and Go, so no need to be future-proof.
EDIT: if it is very similar and someone wants to make a Go app and not make a different NIP we can just amend this NIP to include the Go format and a new Go kind.
imo this is too specific. Maybe we could reserve a kind for "game event" or even "app-to-app data" where the content is arbitrary app-specific data, and it requires a unique tag like "chess-v1" or something.
We have many numbers to use, no need to save kind numbers. This NIP should be about chess, simple and quick. Other apps need other NIPs, which can also be quick and simple.
Also this is not "app-specific", it is a standard protocol that multiple different apps can use to play chess against each other.
@kmkhami
Why is it preferable to use a
kindover atag? I would imagine that atagcould add more value as it could include metadata like theguidfor the game for which theeventis for.
Don't want to spam the global feed of kind := 1 messages.
@fiatjaf
I'd settle for a very quick description of the events, no need to write an article about motivation, abstract, nothing. You can just say: "This is a NIP that standardizes chess games over Nostr", but not even this is needed. If the title says "Chess" everybody already knows what to expect.
A link at the end to your implementation settles any remaining doubt.
:+1:
@fiatjaf
Nevermind, SGF is for Go. Is this NIP about Go? I think Go would be a different kind, even if very similar to this. The same app will not implement both Chess and Go, so no need to be future-proof.
Did not investigate too much by now. It is for all kind of board games:
The Smart Game Format (SGF) is a computer file format used for storing records of board games. Go is the game that is most commonly represented in this format and is the default.
Currently, Jester uses FEN, but this is too limited. At the moment I am testing to switch over to PGN, which would be chess-only and covers everything needed.
@itslenny
imo this is too specific. Maybe we could reserve a kind for "game event" or even "app-to-app data" where the content is arbitrary app-specific data, and it requires a unique tag like "chess-v1" or something.
Yes, I was thinking alike. Maybe it can be flexible. But as @fiatjaf said, "This NIP should be about chess, simple and quick.". Let's see what comes out of it. Any suggestion is highly appreciated :pray: I'll focus on supporting everything needed for chess games for now.
Edit: This is really just to reserve NIP number 64 for chess : -P
Not sure why this needs a NIP and there is nothing to review
It definitely needs a NIP and it is marked as a draft.
Not sure why this needs a NIP and there is nothing to review
I think which format is used should be standardized since clients need to support the same format to be compatible.
Or it should be mentioned how the format that a chess event uses is specified; for example by using a JSON string for content with appropriate keys inside: "fen" for FEN format, "pgn" for PGN format etc.
@ekzyis
Or it should be mentioned how the format that a chess event uses is specified; for example by using a JSON string for content with appropriate keys inside: "fen" for FEN format, "pgn" for PGN format etc.
I disagree. Just use a different kind for each. Also if you're doing chess, just use always the same format, not two different formats, that just doubles the work for nothing. If you're using Go do a different kind and pick a format for Go and then everybody uses that. And so on.
@theborakompanioni
Currently, Jester uses FEN, but this is too limited. At the moment I am testing to switch over to PGN, which would be chess-only and covers everything needed.
I don't know what I am talking about, but I think you should pick the one that has more libraries available for it in many languages. Unless it is so easy to parse that anyone can do it by hand, in that case the easiest one is better.
Closing due to inactivity. This would be a good candidate for inclusion via an external link like nostrocket if you have a nip @theborakompanioni
Closing due to inactivity. This would be a good candidate for inclusion via an external link like nostrocket if you have a nip @theborakompanioni
Hey @staab, I understand. Thanks for leaving it open such a long period of time. :orange_heart:
I recently picked up looking into it once again. Maybe something will come out of it, but I would not bet on it. So closing is probably for the best. :pray:
I'll leave it closed for now but feel free to reopen whenever
Maybe something will come out of it, but I would not bet on it.
I would bet on it :)