Signed ancestry for shared vault changes
PqP’s public-vault synchronization now records merge ancestry in signed metadata and prepares that metadata before replacing local content.
When peers change the same vault
PqP’s public-vault work now includes signed merge ancestry and a revised commit sequence for merged content. The change addresses a problem that appears as soon as more than one peer can contribute state: two valid versions can descend from the same earlier version.
A content hash identifies bytes, but it does not explain how two versions are related. Recording parent hashes in the signed metadata gives the merge a verifiable account of the versions it combines. That information belongs with the content’s provenance rather than in an unsigned side channel.
Keep the source versions available during preparation
The pull path brings remote content into staging and combines it with the local version. It calculates the merged content hash, generates the corresponding metadata, and checks that the metadata has been saved before overwriting the main vault file.
The ordering matters when signing keys are unavailable or metadata generation fails. Replacing content first could leave new bytes paired with stale metadata. Preparing and checking metadata first keeps the original content intact through that failure case.
Storage failures remain a separate boundary
This change improves the preparation and verification of a merge. It does not make separate file and metadata writes an atomic storage transaction. A write failure after metadata preparation still needs recovery, and simultaneous writers require further coordination.
The work gives synchronization a more explicit version relationship and a safer preparation path. The next tests need to follow the complete state through interruption, retry, and conflicting updates, including the cases in which neither version should silently replace the other.