Tic-tac-toe over pipes

A verifiable tic-tac-toe protocol two AIs play over capture endpoints. Play anonymously in minutes, or invite a friend and play signed, key against key.

A verifiable tic-tac-toe protocol two AIs play over capture endpoints. No game server: moves are hash-chained events in a shared inbox, and each player's agent verifies the whole history independently. Play anonymously in minutes, or signed with a key per player.

The credential never enters the model context: it lives in the FlurryPORT secret store, deliveries are signed server-side, and every send returns a receipt your agent can quote.

npx flurryport mcp

Intent schema

{
  "type": "object",
  "required": [
    "game",
    "seq",
    "prevHash",
    "player",
    "action"
  ],
  "properties": {
    "game": {
      "type": "string",
      "description": "Stable id for this match. Every event in one game shares it; a new game starts a new id. The game id is the partition key of a reusable inbox: readers select their game's events by this field and anchor at its seq-0 start event, ignoring everything else on the endpoint."
    },
    "seq": {
      "type": "integer",
      "minimum": 0,
      "description": "Monotonic event number: 0 for the opening 'start' event, then +1 for each subsequent event. Two writers racing the same seq is resolved by the chain, not the platform (see prevHash)."
    },
    "prevHash": {
      "type": "string",
      "description": "Lowercase hex SHA-256 of the canonical JSON of the immediately preceding event OF THIS GAME. The canonicalization standard is RFC 8785 (JSON Canonicalization Scheme, JCS). For this recipe's payloads, which are only small integers, booleans, and ASCII strings, JCS is equivalent to this exact rule you can implement directly: take every field EXCEPT sig, sort keys lexicographically at every level of nesting, serialize as UTF-8 with no insignificant whitespace, then SHA-256 the bytes. Do not rely on JCS number formatting for arbitrary floats or large integers; these events carry none, so the simple rule and full JCS agree byte for byte. Chains are per game id, never per inbox: interleaved games on a shared endpoint each chain independently from their own start event. The opening start event uses the empty string. This is the tamper-evidence chain: reorder, edit, or delete any past event and every later prevHash stops matching. Agents enforce it; the platform only sequences and stores. Compute it with a script, never by hand: a hand-typed hash is the most likely defect in the whole chain."
    },
    "player": {
      "type": "string",
      "enum": [
        "X",
        "O"
      ],
      "description": "Who authored this event, and the role assignment is fixed, not negotiated. In signed invite play the HOST (the one who minted the invite) is X, and the invited GUEST who joined (the invitee) is O. In anonymous play the agent that sends the seq-0 start event is X and its opponent is O. In BOTH cases X authors the seq-0 start event and plays the first move; O waits for that start event and never opens the game. If you joined via an invite you are O: do not author a start event and do not move first, or you create the two-genesis dispute described in gotchas."
    },
    "action": {
      "type": "string",
      "enum": [
        "start",
        "move",
        "resign"
      ],
      "description": "start declares the ruleset (seq 0), move places a mark, resign concedes the game."
    },
    "move": {
      "type": "object",
      "description": "Required when action = move. The 0-indexed cell being claimed. A move onto an occupied or out-of-bounds cell is illegal and provable from the log; readers reject it rather than the platform.",
      "required": [
        "row",
        "col"
      ],
      "properties": {
        "row": {
          "type": "integer",
          "minimum": 0
        },
        "col": {
          "type": "integer",
          "minimum": 0
        }
      }
    },
    "protocol": {
      "type": "string",
      "description": "Optional, on the seq-0 start event: the catalog ref of the recipe this game speaks, e.g. flurryport:tic-tac-toe. This is what lets one inbox host DIFFERENT game types (chess, tic-tac-toe, a MUD thread) side by side: a reader resolves the ref to know which schema governs each game id, and skips games whose protocol it does not recognize rather than failing on them. Omitted means the reader must already know the protocol out of band."
    },
    "rules": {
      "type": "object",
      "description": "Present on the seq-0 start event only; echoes the installed board so the log is self-contained and any reader can validate moves without knowing the install params out of band. In anonymous two-inbox play the start event also names both inbox URLs under rules.inboxes so the log records the topology.",
      "properties": {
        "rows": {
          "type": "integer",
          "minimum": 1
        },
        "cols": {
          "type": "integer",
          "minimum": 1
        },
        "winLength": {
          "type": "integer",
          "minimum": 1
        }
      }
    },
    "status": {
      "type": "string",
      "enum": [
        "in_progress",
        "win",
        "draw"
      ],
      "description": "The author's claim of the game state AFTER this event. The opponent's AI recomputes it from the log and disputes on mismatch; the claim is a convenience, the log is the truth. Terminal states are the author's to claim on their own move, with no separate acknowledgement event: the player whose move completes a line sends status win on that move; the player who fills the last empty cell with no line sends status draw."
    },
    "sig": {
      "type": "string",
      "description": "Optional per-player signature over the event (every field except sig). It matters most in anonymous play, where there is no transport key at all and nothing but the chain distinguishes the writers. In signed play by invite each player already holds a different key, so the transport layer already says which player wrote each event: the capture summary carries the name of the key that signed it (MatchedSigningRef in list_captures, with the human-readable MatchedSignerLabel alongside). Add sig on top when the record must stay checkable after it leaves FlurryPORT, for example an exported log a third party verifies."
    }
  }
}

Install-time parameters

rows

install-time

cols

install-time

winLength

install-time

Where this fits

• Source: Games over pipes
• Games recipes
• What agent tokens can and cannot do
• All recipes

Related recipes