id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037)

From the #2037 investigation (match-result attestation)

Investigation #2037 (queue task 3350, result posted on that issue 2026-10-29) specified the attestation object layer for ID matches: genesis agreement (both players sign game + logic hash + named witness + objection window), per-player signed result claims, agreed/final states computed from the objects, witness decision and objection as signed events, fork-proof voiding via existing event-store mechanics. This issue is the proof of concept for the concession path — the program pattern is design + PoC, and a PoC is not the permanent feature: nothing production is built on top of this without a review round (epic #2056).

PoC scope (existing tic-tac-toe example, `pkgs/id/examples/tic-tac-toe`)

Two players play a match with a signed genesis agreement object (game id, logic/version hash, both player IDs, witness slot left unused for this PoC, objection window parameter present).
At match end each player emits a signed result claim (outcome, final-state hash, both chain frontiers).
A viewer computes the result state from the objects alone: proposed → agreed when both claims concur; conflicting claims → disputed.
The whole exchange is demonstrated offline-first: match + attestation complete with no server, then sync to a second store which computes the identical state.
Negative case demonstrated: one player's claim names the wrong winner → state is disputed, never agreed.

Out of scope

Witness decision flow, objection handling, audit replay (that is #2038 / synthesis #2039 territory), registries/rankings, any production API.

Acceptance criteria

PoC runs the 5 scope points above against the tic-tac-toe example, with the object shapes documented in the PR/issue
The offline-then-sync demonstration shows identical computed state on both stores
A short findings note is posted on this issue: what the PoC proved about the id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037 object shapes, and what it did not prove
No production attestation feature is claimed or merged under this issue

Program: ID platform expansion, epic #2056. Parent investigation: #2037. Related: #2038 (match audit), #2039 (attestation + audit design v1, gated), #2030 (trust/visibility — counting views).

CODE-1114

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), Lane E shift
Session / ID: queue task 3403
Found via: queue claim
Task: Triage id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248 — revalidate the mutual-concession attestation PoC scope against current pkgs/id tic-tac-toe example and id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037 findings; post triage findings and route implementation.
Expectation: effort class m (triage this run); done = findings posted on id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248 and follow-on implementation routed via queue, or PoC work started if genuinely scoped.
Links: queue task 3403

Triage findings — #2248 attestation PoC (queue task 3403)

Verdict: live, correctly scoped, and an implementation build — not a triage-sized fix. Issue is OPEN, no held / user-owned / do-not-* labels, no competing PR or branch found for attestation work. Routed to a follow-on implementation task (enqueued this pass; see closing agent note).

Verified against current main (2026-10-30, fresh `gh` reads)

No attestation layer exists: code search for attestation in pkgs/id/src/ returns only unrelated world-module provenance wording (src/world/mod.rs: "not a signature or a trust attestation"); no genesis-agreement, result-claim, concession, or disputed-state object exists. This matches the id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037 investigation's verdict (task 3350, comments on id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037).
Primitives the PoC composes do exist: signed chained events in pkgs/id/src/chain.rs, event store in pkgs/id/src/event_store/ (ingest.rs, sync.rs, resolve.rs — including fork/equivocation handling), and sync in src/event_sync.rs / src/log_sync.rs. The offline-then-sync scope point should ride the existing store sync, not a new transport.
Target example is minimal and pure: pkgs/id/examples/tic-tac-toe/ is main.roc + README + build.sh + prebuilt wasm. main.roc's update is a pure function of (model, event) and its records already publish {"board": "...", "plays": N, "winner": "X"} as JSON — so the final-state hash in a result claim can be taken over the replayed board/records, and the winner for the negative case is unambiguous.
Existing test surfaces to extend: pkgs/id/tests/event_store_properties.rs, chain_properties.rs, multidevice.rs, voiding_scenarios.rs — a PoC expressed as an integration test/example under pkgs/id/tests/ (or a small example crate) fits the repo's conventions better than touching the Roc world program itself.

Recommended implementation shape (for the follow-on task)

Define the two PoC objects as ordinary signed events per id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037: genesis agreement {game id, logic/version hash (hash of tic-tac-toe main.roc/wasm), both player IDs, witness slot unused, objection-window parameter} and per-player result claim {match, outcome, final-state hash, both chain frontiers}.
A pure viewer function computing proposed → agreed on concurring claims and disputed on conflicting claims, from the objects alone.
Demonstration harness: play/attest in one store with no server, sync to a second store, assert identical computed state; negative case (one claim names the wrong winner) asserts disputed, never agreed.
Document the object shapes in the PR and post the findings note required by the acceptance criteria — what the PoC proved / did not prove. No production API, no witness/objection flow (id: investigate: match audit — netcode log format, replay validation, and cheating signals #2038/id: design: match attestation + audit v1 #2039 territory, explicitly out of scope).

Sizing / risk

Effort class L (new object types + viewer + two-store harness), medium risk: design-sensitive but fully additive and PoC-scoped; nothing existing is modified in behaviour.
This triage task (3403) closes as triaged; the build itself is the follow-on queue task named in the closing note.

🤖 Agent note · done

Agent: queue worker (repo-worker-code), Lane E shift
Session / ID: queue task 3403
Found via: queue claim
Task: Triage id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248 — complete: findings posted on this issue (verified no attestation layer exists on current main; primitives in chain.rs/event_store confirmed; tic-tac-toe example is a pure Roc program publishing board/plays/winner records; recommended PoC shape and sizing L/medium recorded).
Expectation: done = triaged with follow-on routed. Implementation is follow-on queue task 3941 (small_fix, priority 30) — this issue stays open for it and carries queue/queued for that task.
Links: follow-on packet: hidden_files/packet-2248-poc.json · parent investigation id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037 · epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056

🤖 Agent note · findings (PoC implemented, PR #2854)

Agent: queue worker (repo-worker-code), Lane A shift
Session / ID: queue task 3953
Found via: queue claim
Task: Findings note for the id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248 PoC (PR id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854, head f2633ac9; 3/3 PoC tests green on the laptop, full pkgs/id CI is the merge gate).

What the PoC proved about the #2037 object shapes

The two shapes suffice for the concession path: a genesis agreement signed identically by both players (as ordinary attestation.genesis chain events) plus one attestation.claim per player carrying {agreement hash, outcome, final-state hash, both frontiers} lets a pure viewer compute Proposed/Agreed/Disputed from the objects alone — no server, no store-specific state.
Offline-first works with the existing primitives exactly as triage predicted: signed chained events + the event store's ingest hold the whole exchange offline, and a second store fed the first store's applied event bytes (+ the bodies those headers commit to) computes the identical state over the identical event-id set.
The negative case holds: a wrong-winner claim computes Disputed, never Agreed; a single claim stays Proposed; a player double-claiming different outcomes also computes Disputed.
The final-state hash binds cleanly to the example's own published record ({"board":…,"plays":5,"winner":"X"}), and the logic hash to main.roc bytes — no Roc program changes were needed.

What it did not prove

Witness decision flow, objection handling, and the objection window's semantics (parameter present, never exercised) — id: investigate: match audit — netcode log format, replay validation, and cheating signals #2038/id: design: match attestation + audit v1 #2039 territory, still open.
Fork-proof voiding of claims (the store's fork mechanics are inherited, not demonstrated for attestation kinds), audit replay, and viewer behaviour under partially-synced frontiers.
Body transport: the demonstration carries bodies beside their headers; it does not exercise the content/blob layer or the range-sync transport itself.
Nothing production: no API, no registry, no feature claim. A review round is required before anything builds on this (epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056).

Also noted while routing: the earlier triage note named "follow-on task 3941" for this PoC — that number is a different, unrelated queued task (triage #2816, verified live in the queue). Task 3953 is the sole fix task carrying the issue:2248 dedupe key.

Links: PR id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854 · branch queue/3953-2248-attestation-poc · parent id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037 · epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056

Merge pull request #2854 from developing-today/queue/3953-2248-attest…

🤖 Agent note · done (merged)

Agent: repo-worker-code (openchamber scheduled lane)
Session / ID: OpenChamber scheduled lane run 2026-10-30 18:00 CDT · queue task 3953
Found via: queue claim (resumed task 3953 after PR id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854 opened by Lane A)
Task: Closed the loop on task 3953 — verified PR id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854 checks clean, merged PR id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854 into main (074485713b11745c5164a131aac6e80305abd228), removed in-flight labels, and closed id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248.
Expectation: PoC landed on main: mutual-concession match attestation on the tic-tac-toe example (pkgs/id/src/attestation.rs + tests). Findings note already posted on this issue. Issue closed.
Links: id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248 id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248 · PR id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854 id: mutual-concession match attestation PoC on tic-tac-toe (#2248) #2854 · merge commit 0744857

Completed via PR #2854 (merge commit 0744857)

Navigation Menu

Repository navigation

id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248

From the #2037 investigation (match-result attestation)

PoC scope (existing tic-tac-toe example, `pkgs/id/examples/tic-tac-toe`)

Out of scope

Acceptance criteria

Triage findings — #2248 attestation PoC (queue task 3403)

Verified against current main (2026-10-30, fresh `gh` reads)

Recommended implementation shape (for the follow-on task)

Sizing / risk

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id: PoC: mutual-concession match attestation on the tic-tac-toe example — genesis agreement + dual signed result claims, offline-first (from #2037) #2248

Description

From the #2037 investigation (match-result attestation)

PoC scope (existing tic-tac-toe example, pkgs/id/examples/tic-tac-toe)

Out of scope

Acceptance criteria

Activity

developing-today commented on Oct 29, 2026

dezren39 commented on Oct 30, 2026

dezren39 commented on Oct 30, 2026

Triage findings — #2248 attestation PoC (queue task 3403)

Verified against current main (2026-10-30, fresh gh reads)

Recommended implementation shape (for the follow-on task)

Sizing / risk

dezren39 commented on Oct 30, 2026

11 remaining items

dezren39 commented on Oct 30, 2026

dezren39 commented on Oct 30, 2026

dezren39 commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

PoC scope (existing tic-tac-toe example, `pkgs/id/examples/tic-tac-toe`)

Verified against current main (2026-10-30, fresh `gh` reads)