Return-Path: X-Original-To: atp@mail2.ietf.org Delivered-To: atp@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 73E8E1111893F for ; Mon, 6 Jul 2026 14:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783373012; bh=dstS5+aUTgo7ByQoPSOygwpBwBPqrDQJ3Gga2xKdQAg=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=RGOqmcWa85aOz2/ksB0nn5rWoo0s88c45D7UhMvvd++M4J83WFAmg2UiNpVlDSSg6 yE2gW5cBaXPehLHi0i1y0IHzmcQUqflI2mMgF6JZyJixjYJZGydQahqvXQH9d1gGyc c1tBMJCZfQ4owbLTufazEYaQDkVp/oj9OSrAG4m8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkkzBxqb7EEQ for ; Mon, 6 Jul 2026 14:23:30 -0700 (PDT) Received: from mail-yx1-xb12a.google.com (mail-yx1-xb12a.google.com [IPv6:2607:f8b0:4864:20::b12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 615EF11114A80 for ; Mon, 6 Jul 2026 14:16:47 -0700 (PDT) Received: by mail-yx1-xb12a.google.com with SMTP id 956f58d0204a3-664c6304683so3353823d50.2 for ; Mon, 06 Jul 2026 14:16:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783372607; cv=none; d=google.com; s=arc-20260327; b=HVzE+fXBygxoNjPua23H+lvFqjX5uxmNi9XHrbpgi1kFioq/7wsJuMNtOW4stA8ZA/ 3b91u8U4NG9eRgcjROwYGYd7ba+E6gVGUCPOmZFqbofD3aJhgEQD30u/R9WtfLh8yi+j nRxZv/n53vbbWGTgAmSkiSsLwmw4MP2t30heUmT5xURev8o+iTqiM55QRXdcIHz2o5iN 3RZx12rH1jWYrT/frnc+n7lyWFS/f0jwHcUOMxff1GYYdcZji1vFARB9SULbBh6SxPqy K85meUMVOXHjIe8ONUmeI9qGLlpsqjVXGs/GqtBEIcUkLF4ShqsA3+MVyRMYgzckzQGI aLKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=dstS5+aUTgo7ByQoPSOygwpBwBPqrDQJ3Gga2xKdQAg=; fh=X154v23GiRJzEZ0I/yyci2yuk67ue7pB4TnNtFvgWaQ=; b=PS/7MdHrNjA0Lk7s4Hc2/8kiZKysNhwGJcmloeW/biZ7ZKI2DwsEDklyrh6JupsnoZ srOtKTrGYT35KDTwe51nLie7pGQodWSEtIhi5ODv9ZhGh+ej7ppfJ/OaIt668EGPp3GH d2b01zEPOk+C2g4iH4kvaxISBhlqzrNLyJ4XVyY6zGd7ImYf1sEU8E0e4NcZgQM5FbLw DaKcuFPZ1ShCEXo1xqyX+nrSi+iQskqrKIEAZeS4EVSupXzD4BfHYFWsQklOuSOHjCU/ l+07Kpxap7HwvPgC2SosC7gEb+RVVHTjulGpyu+VTzmsqOfoRkZ66PAidYZtcb8r/PIE 2SJg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783372607; x=1783977407; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dstS5+aUTgo7ByQoPSOygwpBwBPqrDQJ3Gga2xKdQAg=; b=d6LyXBjPtRxW65FvvWwVlh9L85eMonj431v+u7kMl0MaqZPFTiEW2XkSeZYYiErwPj kzVjExoGFUv6V75vlEB7e154VYggn3osAHNwsT3GbNDzRgMWVfoA9I7AS7rB2dNyd3uy C79PPC/C3t2yJMD9bQkOgoVcBpiYoZfhJn/OgK0Enc/QbqLeVeO6TfJ257deujIf5W54 +whNqFR+O5KADHvM91R/HwTDZoSpafv4/KjHUtnLSTiMSrgqHV6o0LhdR/2+R0U+a75k uVJK1EiNEQBcxlRkxWVUulCrnB7yw0pI2vNbGiY1ltKpsDz0rJe28BPnPDsrj7ut8F5/ JeNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783372607; x=1783977407; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=dstS5+aUTgo7ByQoPSOygwpBwBPqrDQJ3Gga2xKdQAg=; b=JpGO5Ae51HsgQeFVqzytPI+MuG247eGb5doTKyBJKM8T0rHWSgNoRslD6hcIO1Os2r qpMJId8e5XD9CVHz6nUXHXANpNpqnBlzzt6LbtVNGWEz+Rj1tnisrrEjVR13kByDK/Sq 45qjRU2W/0Ih6gmz2hzPKa9+/zJ1f0+spGEhF9HrO7YYNbpn1UswcgxPyv4ENfqKCmL7 sMCOgkOmwNNdU2LqGyc1k+/1Sgbc5GuB8sXndIQq1+eHuVp/54UbbDMjHSdabVFBfqe9 L41WntJe9pi+HfvVWSKJkdDBTt2uodhVAz0rvMLZ9q8NMtCNxwDEZCYT2m9aP8lBNbZu uA4g== X-Gm-Message-State: AOJu0YwJRvYGNGkKgi+HEc21xzIJnBCNzReU6flSeZJSrc61q5cvbHRl aQHnzgqQ+0/7CZGqOttzlhH4sN9fyOsp1HopBRMIkAuELi7z4WfPlxDqSXNY6NoCADCXCpTZ7Vo YgzzKYRIQkrUqV4Cp+WvzB86OI+tsIvd4xOnLZ/Q= X-Gm-Gg: AfdE7cludkLeQnzQNdsAeVtS0wNW7FDZXYATViD6KCTu1eH50LRo2xMjyHdksVmmfrT bbxEkC68UzJD0vMw3ZiXRLQAGX/ixdCj98As1uJZQ5lsg5DVh9oQ2Zu97Yx5Jvx2VgwdL08Ny83 DiKZFVwb9FtgDpfOAEPAOqOknxzLqtA7gsoSBf2ez3YhivQ0hncAxTKZohnMLJnR47PrX47RT+G 0kn2QOuusmuvm16qNhDM4NXu21G7cBEq3Edn+Uec6ufd6yjI6mrBUJOu/y9TI9UzZR9z6rnt++m 129w/4XT8FlEJFAKCGxB7Ec+iUb8 X-Received: by 2002:a53:bc01:0:b0:664:dbfc:e465 with SMTP id 956f58d0204a3-6677fa2ef21mr1596842d50.8.1783372606739; Mon, 06 Jul 2026 14:16:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Schleihauf Date: Mon, 6 Jul 2026 17:16:10 -0400 X-Gm-Features: AVVi8CeVZitP6hMFXPbT4_J3K3bdDFmW2FYEe82diHP7m5c92buO5aGawDxDpvQ Message-ID: To: Bryan Newbold Content-Type: multipart/alternative; boundary="000000000000ba1cc90655f7ca5c" Message-ID-Hash: MVCOKANWOGUPNDO2CBDVYAYZE3GDQIIE X-Message-ID-Hash: MVCOKANWOGUPNDO2CBDVYAYZE3GDQIIE X-MailFrom: uniphil@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: atp@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BAtp=5D_Re=3A_Repository_and_Synchronization_Draft_Text?= List-Id: Authenticated Transfer Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ba1cc90655f7ca5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Bryan Newbold wrote: > On Sat, Jun 27, 2026 at 7:52=E2=80=AFAM Phil Schleihauf wrote: > >> Regarding Sync, 4.1.2, Operation Inversion: >> >> - Is there any restriction regarding multiple ops appearing in one commi= t >> 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 recor= d > 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) >> 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 >> , >> 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 > --000000000000ba1cc90655f7ca5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 els= e but S4.5 Commit Validation -> Step 2 only says

>=C2=A0All created and updated record blocks must be present,

which I had interpreted=C2=A0as "blocks present in th= e CAR", and not necessarily in the unmodified tree.

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


On= Tue, Jun 30, 2026 at 9:40=E2=80=AFPM Bryan Newbold <bryan@blueskyweb.xyz> wrote:<= br>
On Sat, Jun = 27, 2026 at 7:52=E2=80=AFAM Phil Schleihauf <uniphil@gmail.com> 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:=C2=A0

=
>=C2=A0Multiple operations on the same record (path) are not allowe= d within a commit.

I think multiple operations on = a single repo path (aka MST key) probably isn't even possible to repres= ent 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 j= ust about validating the ops list in a commit message as being well-formed.=

To speculate about how this sort of question migh= t even come up, a repository MST implementation (eg, as part of a PDS imple= mentation) might have support for applying multiple successive mutations to= the tree, and then output a "diff" (including ops list). Or inte= rmediary services might try to "compress" multiple successive rep= o diffs (commit messages) into a single combined diff. I think in both of t= hose cases it is=C2=A0
=C2=A0
Issue #78 on the origin= al Sync1.1 proposal (0006)=C2=A0on Github is still open: "Blocks n= eeded for operation inversion depends on the order of the operations"<= /div>

I=C2=A0think=C2=A0the rule

>=C2=A0Producers of diffs intended to support operation inversi= on MUST include, in addition to the blocks required by Section 4.1.1, the MST nodes for keys directly adj= acent (in lexicographic order) to mutated keys.

is= meant to satisfy your follow-up on that issue

>= ;=C2=A0require enough blocks to allow inversion regardless of the order of = operations.

but it would be nice to confirm that t= hat is the case.

To be honest I= still don't feel particularly confident about the formulation and requ= irements here. Specifically, which "additional" MST nodes (as blo= cks) are required for operation inversion, and whether the order of operati= on inversion changes the requirements. It would be great if we (collectivel= y) 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 implem= entations. But corner-cases are probably just statistically rare.

--bryan=C2=A0

--000000000000ba1cc90655f7ca5c--