[Atp] Re: Repository and Synchronization Draft Text

[Phil Schleihauf <[e-mail]>]

ah, 4.4.2 does answer it! thank you.

good point about different ops not being able to coexist at the same path
at once in a tree. i probably missed somewhere else but S4.5 Commit
Validation -> Step 2 only says

> All created and updated record blocks must be present,

which I had interpreted as "blocks present in the CAR", and not necessarily
in the unmodified tree.

but that's moot since it's already disallowed. (and under coalesced commits
i think the ops need to merge by path too)


On Tue, Jun 30, 2026 at 9:40 PM Bryan Newbold <[e-mail]> wrote:

> On Sat, Jun 27, 2026 at 7:52 AM Phil Schleihauf <[e-mail]> wrote:
>
>> Regarding Sync, 4.1.2, Operation Inversion:
>>
>> - Is there any restriction regarding multiple ops appearing in one commit
>> for the same key?
>>
>
> Sync 4.4.2 ("#commit Message") says:
>
> > Multiple operations on the same record (path) are not allowed within a
> commit.
>
> I think multiple operations on a single repo path (aka MST key) probably
> isn't even possible to represent in the tree itself, right? A given record
> path can only have one value (including non-existence) in the tree at a
> given time. So I think this is just about validating the ops list in a
> commit message as being well-formed.
>
> To speculate about how this sort of question might even come up, a
> repository MST implementation (eg, as part of a PDS implementation) might
> have support for applying multiple successive mutations to the tree, and
> then output a "diff" (including ops list). Or intermediary services might
> try to "compress" multiple successive repo diffs (commit messages) into a
> single combined diff. I think in both of those cases it is
>
>
>> Issue #78 on the original Sync1.1 proposal (0006)
>> <https://github.com/bluesky-social/proposals/issues/78#issuecomment-2764952168> on
>> Github is still open: "Blocks needed for operation inversion depends on the
>> order of the operations"
>>
>> I *think* the rule
>>
>> > Producers of diffs intended to support operation inversion MUST
>> include, in addition to the blocks required by Section 4.1.1
>> <https://www.ietf.org/archive/id/draft-holmgren-at-synchronization-00.html#diff-format>,
>> the MST nodes for keys directly adjacent (in lexicographic order) to
>> mutated keys.
>>
>> is meant to satisfy your follow-up on that issue
>>
>> > require enough blocks to allow inversion regardless of the order of
>> operations.
>>
>> but it would be nice to confirm that that is the case.
>>
>
> To be honest I still don't feel particularly confident about the
> formulation and requirements here. Specifically, which "additional" MST
> nodes (as blocks) are required for operation inversion, and whether the
> order of operation inversion changes the requirements. It would be great if
> we (collectively) could firm this up with some data structure analysis.
>
> IIRC we do have some fuzz testing which randomizes the order of ops for
> randomly generated multi-operation commit objects in some of our
> implementations. But corner-cases are probably just statistically rare.
>
> --bryan
>