mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 03:38:23 +00:00
Claude
f1c461dcfa
Two deviations from BUD-11, both predating the read-auth rework and both carried forward by it. The `x` tag defeated the per-host token cache. BUD-11 lists `x` as optional for `GET /<sha256>`, but its Tag scoping rule is strict about what including one means: "When `x` tags are present, the token is only valid for operations on the specified blob hashes." Tokens are cached per host and replayed for every blob on it, so from the second image onward we were sending a token scoped to some other blob's hash. The old comment had the reasoning backwards — it kept `x` "for servers that check it", which is precisely the case that rejects a reused token. createGetAuth now takes a nullable hash, and the read-auth path passes null: the `server` tag alone scopes the token, which is what makes reuse legitimate. That widens the grant from one blob to any blob on the host for the token's hour, which is the inherent price of caching and is the shape BUD-11 sanctions. The token encoding was standard Base64. BUD-11: "MUST be encoded as Base64 URL-safe without padding (Base64url, as used by JWTs)". In practice the alphabets coincide — a token's JSON is printable ASCII and a sextet only reaches 62/63 when the third byte of its group is `>`, `~`, `?` or DEL, so `+` and `/` never appeared across 600 sampled tokens — but padding did, on 52% of them. NIP-98's encoder is deliberately left alone; it specifies no variant. Nothing in the tree decodes a Blossom auth header, so the encoding change is client-side only. Tests pin both rules at the event level and end-to-end on the token this path actually mints, with several content lengths for the padding case since whether padding appears depends on the JSON length mod 3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TYrDf5Z8TE4uivADuFwPFz