I’m at the point where I want to start extending the Blygger protocol to accommodate Hermann Hesse’s Glass Bead Game.

The first thing I have to remind myself is that Product Brain must evolve to Protocol Brain. Don’t make the client or the platform; make the protocol-ish engine that can power numerous arbitrary, value-adding manifestations of clients and platforms. To do that, I’ll take an Amazonian approach and work backwards.

In Hesse’s novel, a Glass Bead Game is played by Castalia’s scholars using a symbolic language that links ideas from every discipline, such as a musical theme, a mathematical proof, or a line of poetry. A player opens with a motif, then develops and transforms it through variations, counterpoints and correspondences across fields, much like composing a fugue.

The aim isn’t to win but to create a game of maximum harmony, elegance and insight, revealing the hidden unity of all knowledge. A great game is judged as a work of art and is also experienced as contemplation, close to prayer.

Happily, Blygger’s ethos and resulting protocol—blogs × wikis × Twitter × git changelogs, built on static files and RSS—provide the primitives to bring GBGs to life on the web, today.

Let’s pretend that one of The Protocol Institute’s Special Interest Groups (SIGs) is extending their roster of events. On a weekly basis, they will be hosting a Glass Bead Game.

The Game functions as follows. The two players involved agree to an exchange which the SIG has a particular interest in. Let’s say the SIG provides a prompt or brief in advance.

The Game begins. The first turn is a Player making an opening move using their own Blyg. Perhaps they iterate through a fragment or piece together a thread. When time runs out, the move is locked in.

The other Player responds via their own Blyg. They may respond directly with a fragment. They might transclude a thread from the Blyg of someone else in the SIG (a number of whom are watching the Game unfold live, hanging out on Discord).

The exchanges go back and forth, with fragments, threads, transclusions, stubs, and off-Blyg excerpts all woven into a dense tapestry of live thought.

At the close of the Game, the entire structure is itself locked up, and then becomes a part of the cultural mosaic, and informs both ongoing Blygging and future Games.

Extending Blygger for GBGs

Working backwards from the Game, the protocol needs to supply a handful of things:

• A brief that convenes the Game and that every move can point back to
• Moves, authored by each player on their own Blyg
• Lineage, so each move names what it builds on
• Lock-in, so a finished move becomes immutable and citable
• Notification, so a player knows the other has moved
• Membership, so any item can say which Game it belongs to
• Outside material, so moves can draw in other Blygs and off-Blyg sources
• A record, so the finished Game becomes a single artefact

Almost all of this already exists.

• The brief is just a fragment or thread on the SIG’s Blyg
• Moves are fragments and threads
• Lineage is stub_of
• Lock-in is a pin, which Blygger already treats as a permanent, irrevocable promise
• Notification is Webmention
• Outside material arrives through cross-origin transclusion, or through a stub of a plain URL
• The record is a thread on the SIG’s Blyg that transcludes every pinned move and is then pinned itself

Timing, turn order, spectators and judging stay out of the protocol entirely, just as AI does.

Only two things are missing:

Membership. A new optional field, game_of, names the brief. Clients that don’t understand it ignore it, so a move still reads as an ordinary stub everywhere else.

Multiple parents. Synthesis moves build on more than one prior move, but stub_of names a single target. Relaxing it to accept several means one Webmention per parent. A more conservative route leaves stub_of alone and treats a move’s transclusions as its extra parents.

A valid move, then, is a pinned L2 item that carries game_of and stubs at least one prior move in the same Game; an opening move stubs the brief. The pinned version is the move, so later edits to the live item don’t touch the Game. The protocol only defines what counts. The SIG’s Game client checks who played and when, and leaves anything invalid out of the record.

A few questions remain open.

• Should references be able to name a specific pinned version, so lineage points at the move rather than the living item?
• Should the brief list the players, so any client can validate a Game?
• Is game_of really a general “convened by” field that salons and reading groups could reuse?