Skip to content

id: design: session header + segment checkpoint event kind #2240

Closed

Description

@dezren39

Design the durable encoding for checkpointed live sessions — the input everything else in the #2034 family depends on.

Why

#2034 investigation (doc: doc/2026-10-29T10-45-00Z_investigation_ephemeral_live_data_retention/) concluded on a two-tier model: durable facts stay on the per-author signed hash chain (ChainExt), keystroke/cursor/input traffic moves to an ephemeral per-session stream authenticated by a session header + per-session MAC key, closed by intermittent segment checkpoints. Nothing in the tree defines what a session header or a checkpoint is.

Scope

  • Define SessionHeader and SegmentCheckpoint records and a new ChainExt.kind (session.checkpoint), with canonical-CBOR encoding and golden test vectors, verified the same way as any other signed event (pkgs/id/src/chain.rs:282-342).
  • Decide the open question from the investigation: is a checkpoint an ordinary graph event, or a parallel signed artifact in the artifact.rs shape referenced from the graph? State the trade-off and pick one.
  • Decide the session-header MAC key scheme: committed in the header vs derived per session from a long-term key; behaviour on key rotation mid-session.
  • Specify segment policy defaults (N events / T seconds, plus emission on commit/blur/disconnect) and whether it is world-configurable like WorldLimits (pkgs/id/src/world/mod.rs:59-99).
  • Specify how checkpoints interact with fork proofs and the waiting pool (pkgs/id/src/event_store/mod.rs:12-22, waiting.rs) so a later compaction cannot break after resolution.
  • Peer countersignature (peer_signature) variant: which classes must require it (id: investigate: match-result attestation — mutual concession, witness adjudication, offline play #2037/id: investigate: match audit — netcode log format, replay validation, and cheating signals #2038 consume this).

Acceptance

  • A design doc under doc/ linked from this issue with the record shapes, encoding, verifier walk, and the decisions above.
  • Wire fields and a verifier algorithm concrete enough that the PoC issue can be built from it without further design.
  • No permanent feature built here — this is design only.

Refs #2034, #2056.

Activity

  1. added
    priority/highImportant and time-sensitive
    queue/queuedHas a queued task in the Supabase agent queue
    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. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 1, 2026
  4. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

    • Agent: repo queue worker, lane D (repo-queue-worker-shift-d)
    • Session / ID: queue task 3461 (triage, fleet-monitor safety-net), claimed 2026-11-01T08:05Z
    • Task: Triage id: design: session header + segment checkpoint event kind #2240: re-verify the design claims against current main, decide the design route and any gating follow-ups.
    • Expectation: claim-by-claim verdict posted on this issue this shift; the design production routed as one follow-up packet with the PoC explicitly gated behind it.
  5. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · triaged — CONFIRMED; design production routed as one packet (task 5240), PoC explicitly gated

  6. added
    queue/queuedHas a queued task in the Supabase agent queue
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 1, 2026
  7. 82 remaining items

  8. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  9. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up for metadata-only ownership revalidation

    • Agent: queue worker (repo-worker-code), OpenChamber scheduled lane
    • Session / ID: OpenCode session ses_e5e6382f632ffeoXT3muAxJr0w · queue task 5240
    • Found via: atomic queue claim; resumed from parked ownership checkpoint
    • Fresh metadata: id: design: session header + segment checkpoint event kind #2240 OPEN and assigned to dezren39; sole matching PR design(id): #2240 session checkpoint encoding #3867 OPEN, non-draft, authored and assigned to dezren39.
    • Action: no PR content/checks, branch, or worktree inspected or touched.
    • Next: park pending PR disposition or explicit ownership release.
  10. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked — Drew-owned PR remains open

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

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  13. added 2 commits that reference this issue on Nov 2, 2026
  14. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done

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-sensitive

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions