Identify add-to batches by batch message hash - #35
Merged
Conversation
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>
This was referenced Aug 10, 2026
markmnl
added a commit
to markmnl/fmsg-docker
that referenced
this pull request
Aug 25, 2026
Picks up markmnl/fmsgd#35 and #39 now they are merged: - msg_add_to_batch.sha256 stores the batch message hash, which is the batch's identity (SPEC §11/§12) — the same addresses re-issued at a new time are a distinct batch, not a duplicate. - msg_add_to uniqueness moves from (msg_id, addr) to (batch_id, addr), so distinct batches may re-add the same address, each batch being its own sibling branch. The old constraint is dropped for existing databases. - time_added now documents that it carries the batch message's wire time. - populate_msg_psha256_from_pid accepts a psha256 matching one of the parent's recorded batch hashes, so replies referencing a batch by hash store against the shared parent row. Every statement stays idempotent, so re-running the script remains the migration path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
handleAddToPathmaps 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.addToBatchRecordednow matches onmsg_add_to_batch.sha256instead of walking the recipient-address set.insertAddToBatchstores the batch hash; both receive paths (attach and full-delivery) pass the cached wire hash.dd.sql:msg_add_to_batch.sha256 byteaadded (idempotent alter included);msg_add_touniqueness 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
msg_add_to_batchrows havesha256 = 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.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.scripts/update-dd.shin fmsg-docker to refresh the postgres init copy.Confirmed follow-up (a) of #33.
🤖 Generated with Claude Code