NIP-64: Chess (Portable Game Notation)
Some protocols are tiny because the old format is already good
NIP-64 is refreshingly small. Chess already has Portable Game Notation, a human-readable and widely supported format for recording games. The NIP says: put PGN in a Nostr event of kind 64 and let clients render it.
That is the right amount of protocol. Nostr does not need to invent chess notation. It needs an event kind so games can be posted, discovered, replied to, archived, rendered and verified by clients.
A good NIP-64 client can make a chess note feel alive: board replay, move validation, comments, metadata, links back to Lichess or another source, and ordinary Nostr conversation around the game.
Kind 64 with PGN in content
The content field is a PGN database. The examples range from * for an unknown or unfinished game to full games with Event, Site, Date, players, result and move text. The event may include an alt tag so clients that do not understand chess can still show a readable description.
Clients need to publish PGN in export format, the strict machine-created style, but accept import format, the looser human-created style. They needs to check formatting and legal moves. Relays may validate PGN and reject invalid notes.
The standard deliberately stays narrow. It does not define tournaments, matchmaking, clocks, ratings or correspondence chess. It defines a portable game record.
A small app-specific NIP that changed kind numbers early
theborakompanioni added the visible PGN work in December 2023. In February 2024, the examples were moved, FEN tags were removed and the kind changed from 30 to 64. In March 2024, chess was added to the title.
That early cleanup is useful because it shows restraint. The NIP moved toward PGN-only instead of layering extra chess-specific tags that might duplicate the PGN itself.
Later changes were mostly formatting and reference fixes. NIP-64 is not a giant ecosystem standard; it is a good example of how Nostr can carry a niche application object cleanly.
The client needs to be a chess you, not a text box
The minimum implementation is to display PGN text. The useful implementation renders the board, steps through moves, shows comments, validates legality and gives non-supporting clients an alt summary.
Because PGN is a mature format, implementers can rely on existing chess libraries rather than hand-parsing casually. That is especially important for import-format tolerance and legal-move validation.
NIP-64 can also act as an archive bridge. A game played elsewhere can be posted as a signed Nostr object with the original site in PGN metadata. The conversation around the game can then live on Nostr.
Tiny standards can still make messy archives
If clients accept invalid PGN without marking it, the archive becomes noisy. If relays reject too aggressively, human-created import format may be lost.
There is also context loss. A PGN without source, players or result can still be valid, but may not be useful. Good clients need to encourage useful metadata without making simple games impossible.
Read NIP-64 in the wild
NIP-64 shows that Nostr can carry structured games, not only social posts. Chess needs players, moves, state and results that independent clients can understand.
A signed move proves who published it, not whether the game state is valid. A serious client still has to validate moves, clocks, resignations and disputes.
What changes when you actually use it
For you, NIP-64: Chess is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms kind 64, draft, kind:64, .content are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-64: Chess needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
The official file is organized around Note, Content, Notes, Client Behavior, Relay Behavior, Examples, Resources. Inspect kind 64, draft, kind:64, .content because these are the pieces most likely to surface as product behavior.
NIP-64: Chess earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-64: Chess is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-64: Chess is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-64: Chess is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-01 and the adjacent source links to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-64: Chess names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-64: Chess does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-01 and the adjacent source links and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-64: Chess with interoperability. If kind 64, draft, kind:64, .content cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-01 and the adjacent source links and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: PGN specification, Chessprogramming PGN overview, NIP-31 alt tag context, Lichess. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-64 source is the anchor for exact wording, and NIP-64 commit history shows how that wording moved over time. The strongest secondary clues here are PGN specification, Chessprogramming PGN overview, NIP-31 alt tag context. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-64: Chess: first the human promise, then kind 64, draft, kind:64, .content, then the implementation record, then the real-world failure case. That order keeps NIP-64 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
kind 64,draft,kind:64,.content, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
kind 64,draft,kind:64,.contentin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-64 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-64: Chess in that order: Official NIP-64 source for the current wording; NIP-64 commit history for the change record; PGN specification, Chessprogramming PGN overview, NIP-31 alt tag context for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
