From f84a55ea6d4d6c5722cc828654946995c3f05b69 Mon Sep 17 00:00:00 2001 From: Jeff Gonzalez Date: Mon, 7 Sep 2026 12:32:42 -0400 Subject: [PATCH] =?UTF-8?q?the=20ETag=20is=20not=20universally=20a=20blob?= =?UTF-8?q?=20hash=20=E2=80=94=20verified=20against=20GitHub?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We left an Affirm asking whether the assumption was load-bearing enough to check first. Checked it an hour later and it fails: GitHub's raw ETag is 64 hex, a sha-256 of something that is not the git object, where gitea's is the blob sha. The API's sha field is the blob sha and matches git hash-object on the fetched bytes, so the content is identical — only the header differs. What survives: conditional requests work on both, and If-None-Match returns 304 from GitHub exactly as from gitea. What does not: "hash the local copy and compare to the remote's ETag" was a gitea coincidence, so there is something to record after all — the ETag itself, opaque, per document. Where it lives is the builder's call, with one steer: not a .md facet, since it is machine state rather than prose. And the check we thought we were getting free is free from elsewhere anyway — an edited local copy shows up in git status, because the copy is committed. The specimen still describes the old idea and is left as written. A specimen is a snapshot of what was proposed, and correcting it in place would hide that we were wrong within a day of proposing it. Co-Authored-By: Claude Opus 5 (1M context) --- .loom/cart/current/claude-substrate-osprey.md | 36 +++++++++++++++++-- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/.loom/cart/current/claude-substrate-osprey.md b/.loom/cart/current/claude-substrate-osprey.md index 1f5de6b..7735cd6 100644 --- a/.loom/cart/current/claude-substrate-osprey.md +++ b/.loom/cart/current/claude-substrate-osprey.md @@ -54,12 +54,42 @@ exist.*** *If `init` earns its place, it creates one file and asks one question. --- +## Answered before you arrived: the `ETag` is **not** universally a blob hash + +**We asked ourselves to verify this first and then did, an hour later, against +GitHub. It does not hold.** + +``` +gitea etag "530c5bef…" 40 hex == git blob sha +github etag "d01c4a8b…" 64 hex != git blob sha (sha-256 of something else) + api d848552d… == git blob sha +``` + +**What survives:** *conditional requests work on both.* `If-None-Match` returns +`304` from GitHub exactly as from gitea. **The mechanism is fine.** + +**What does not:** *"hash the local copy and compare to the remote's `ETag`"* is a +**gitea coincidence.** **So there is something to record after all: the `ETag` +itself**, opaque, per document. + +*Where it lives is yours. **We would not make it a `.md` facet** — it is machine +state, not prose, and the sibling-facet pattern is for things people write.* + +> **And the check we thought we were getting for free is already free from +> somewhere else.** *"Did somebody edit our copy of their document?" needs no hash +> — **the copy is committed, so `git status` says so.*** + +*The specimen still describes the old idea. **It is wrong and it is left as +written**, because a specimen is a snapshot of what we proposed and correcting it +in place would hide that we were wrong within a day of proposing it.* + ## Question: what isolates your work while a round is open? *The one role we left uncast — see [`cart.usages.md`](../../externals/git.hypertheory-labs.dev/loom/cart/cart.usages.md).* -## Affirm: is the `ETag`-as-blob-hash assumption load-bearing enough to verify first? +## ~~Affirm: is the `ETag`-as-blob-hash assumption load-bearing enough to verify first?~~ -*If it does not hold, most of the specimen collapses and it is better to find out -in an afternoon than in a week.* +**Withdrawn — we verified it, and it failed.** *See above. **Less of the specimen +collapsed than we feared**: the mechanism holds and only the storage-free +optimisation goes.*