Skip to content

Identify add-to batches by batch message hash - #35

Open
markmnl wants to merge 1 commit into
mainfrom
fix/add-to-batch-hash-identity
Open

Identify add-to batches by batch message hash#35
markmnl wants to merge 1 commit into
mainfrom
fix/add-to-batch-hash-identity

Conversation

@markmnl

@markmnl markmnl commented Aug 10, 2026

Copy link
Copy Markdown
Owner

Implements the batch-identity follow-up from #33 per the design ruling: batch identity is the batch message hash (which covers time), so re-issuing an add-to with the same address set at a new time is a distinct batch — a new sibling branch — not a duplicate (SPEC §11/§12).

Changes

  • handleAddToPath maps the stored parent's payload paths into the received add-to header and computes the batch message hash (add-to header + parent payload, SPEC §11 NOTE I) before the duplicate check. The same computation was already done later on the code-65 path for challenge verification; it is cached, so this is one hash either way.
  • addToBatchRecorded now matches on msg_add_to_batch.sha256 instead of walking the recipient-address set.
  • insertAddToBatch stores the batch hash; both receive paths (attach and full-delivery) pass the cached wire hash.
  • dd.sql: msg_add_to_batch.sha256 bytea added (idempotent alter included); msg_add_to uniqueness relaxed from (msg_id, addr) to (batch_id, addr) so a later batch may re-add an address an earlier batch added (each batch is its own sibling branch). Migration drops the old constraint and creates the new unique index under PostgreSQL's default generated name.

Notes for review

  • Pre-migration msg_add_to_batch rows have sha256 = null, so a legacy batch re-delivered after upgrade is recorded as a new batch rather than detected as a duplicate — a one-time migration cost.
  • Batches originated locally (inserted by fmsg-webapi) also carry sha256 = null; hash-keyed duplicate detection only matters on the receive path. Resolve reply parents referencing add-to batch hashes #39 populates it at first delivery (ensureBatchHash), so replies referencing a locally originated batch resolve at this host too.
  • After merge, run scripts/update-dd.sh in fmsg-docker to refresh the postgres init copy.

Confirmed follow-up (a) of #33.

🤖 Generated with Claude Code

Batch identity is the batch message hash, which covers time (SPEC
SS11/SS12): re-issuing the same add-to addresses at a new time is a
distinct batch (a new sibling branch), not a duplicate. Previously
addToBatchRecorded keyed on the recipient-address set, so a re-issued
batch was rejected code 10.

The receiving host computes the batch hash at header exchange from the
add-to header plus the stored parent's payload, stores it on
msg_add_to_batch.sha256, and duplicate-checks against it. msg_add_to
uniqueness is relaxed from (msg_id, addr) to (batch_id, addr) so a
later batch may re-add an address an earlier batch added.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant