Skip to content

id: investigate: match audit — netcode log format, replay validation, and cheating signals #2038

Closed

Description

@dezren39

LIST 10b. The full netcode-level log (every key up/down, low-level state-machine detail) can be recorded for a game and sent to an AUDITOR who replays it: is it a valid set of operations, would the game even technically play that way, are there signs of cheating? Investigate: log format and size, deterministic replay requirements, and the metadata competitive play needs (ping, known IP, …) to distinguish technically-valid state machines from actually-valid gameplay (speedrunning, competitive FPS). Deliverable: audit pipeline sketch + metadata list.

Program: Drew's 2026-10-28 directive (full text: hatch-personal memory/topics/id-program-2026-10-28.md).
Working pattern: parallel investigations, then the named synthesis issue merges them into a full design. Route guidance: Workhorse by default; Specialist/Summit for synthesis and ramification-heavy work. A result that says "done" is not the endpoint — the orchestrator reviews it and may commission another round. Deliverables: a markdown design/investigation doc (mermaid/SVG diagrams welcome) linked from this issue, plus follow-up issues for anything buildable. Build a proof of concept where the design calls for one, but do NOT build the permanent feature on top of an unreviewed PoC.

Activity

  1. added
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    on Oct 29, 2026
  2. developing-today commented on Oct 29, 2026

    @developing-today
    Contributor
  3. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    Parent epic: #2056 — ID platform expansion (2026-10-28 directive).

  4. added
    priority/highImportant and time-sensitive
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 29, 2026
  5. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    Top priority — ID program wave-1. Drew directed this be picked up in the next runs (2026-10-29): enqueued directly as triage task 3351 in repo-health-code-pilot at queue priority 20 (only breakage-class work at priority 10 outranks it). Wave-1 is the ungated investigations and designs; syntheses and PoCs stay gated on their named inputs. Investigation route: Workhorse.

  6. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 29, 2026
  7. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

    • Agent: queue worker (repo-worker-code), Lane D shift
    • Session / ID: queue task 3351
    • Found via: queue claim
    • Task: Triage/investigation for id: investigate: match audit — netcode log format, replay validation, and cheating signals #2038 — match audit: netcode log format, replay validation, cheating signals. Produce the investigation doc (doc/ per repo convention, via PR), record the result on this issue, and route follow-on work in the same pass.
    • Expectation: effort class m — "done" = investigation doc PR opened + summary comment here + follow-on routed (gated synthesis stays gated on its named inputs).
    • Links: queue task 3351 (developing-today/code)
  8. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    Investigation result — match audit (queue task 3351)

    Deliverable: PR #2252 — doc/2026-10-29T10-54-33Z_investigation_match_audit_netcode_replay/ (386 lines). Mirror: ~/workspace/id-program-2026-10-28/investigations/match-audit.md.

    Headline verdict: replay audit fits ID well — worlds are already journaled, sandboxed Roc/Wasm programs, and src/world/clock.rs is exactly the seam a log-driven replay mode needs — but replay proves only the weakest claim people want from it:

    • Authenticity + "the result follows from these inputs" — provable, if the log is hash-chained/signed with program+rules pinned by hash (§2), and if the world program is deterministic under replay (§3). Determinism is a property to engineer and test, not one we have by default; the float-discipline question is the hard open problem.
    • "A human played this fairly" — never provable by replay: a bot/TAS/spliced log can be technically valid. That claim needs observed metadata — countersigned by a peer/relay/witness, never self-reported — plus statistical screening, and even then the honest verdict is flagged / not flagged, never "proven fair".

    Also delivered in the doc:

    • Log format: header / tick-indexed inputs / events / per-second checkpoint hashes + sparse snapshots / signed footer; result is a claim inside the log. Size is a non-issue: turn-based KBs; a 5v5 45-min FPS match ≈ 2–5 MB compressed.
    • Metadata list (§4.1): observed IP (salted hash in the public log, full IP only in an auditor-sealed section), RTT samples over the match, connection path, clock skew, join/leave/reconnect events, device/build context, stakes profile.
    • Cheating signals (§4.2): superhuman reaction distributions, frame-perfect TAS sequences, inputs reacting to events before the observed RTT could deliver them, entropy collapse, splice attempts (those are L1 cryptographic failures, not flags).
    • Audit pipeline (§5): L0 provenance → L1 integrity → L2 deterministic replay → L3 plausibility screen, tiered by stakes, closed verdict vocabulary (INVALID RECORD / REPLAY DIVERGES at tick T / TECHNICALLY VALID, FLAGGED / TECHNICALLY VALID, NO FLAGS at depth D / INCONCLUSIVE), handing off to the attestation flow — the auditor decides nothing about prizes or bans.
    • Offline matches honestly scoped: L1/L2 still work; L3 is permanently INCONCLUSIVE — no observed metadata there, and id: design: match attestation + audit v1 #2039 must price that.

    Follow-on routing: synthesis #2039 is the named consumer (noted there); it stays gated on sibling investigation #2037. The four proposed buildable slices (determinism proof first — it gates everything) are in doc §6 for #2039 to adopt or cut; deliberately not pre-filed as separate issues so the synthesis owns the set. Nothing here is a permanent feature or a PoC built upon.

    🤖 Agent note · done (pending PR #2252 merge)

  9. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  10. 24 remaining items

  11. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  12. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    queue/claimedQueue worker lifecycle state
    on Oct 29, 2026
  13. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  14. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  15. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done (triaged)

  16. removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    work/assignedQueue worker lifecycle state
    on Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/idPackage/app: id (pkgs/ or apps/ in this repo)priority/highImportant and time-sensitivestatus:done

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions