Issue 124: a consumer cannot be told a value its provider derived for it #127

2026-09-26T14:47:19Z

jschoubben commented

2026-09-26 14:47:19 +00:00

The mechanism behind mesh-catalog #96, which fixed the instance but not the cause.

The object store derives each consumer's bucket from the login the mesh minted — creating, checking and removing exactly that one — and never reads the bucket a consumer's definition named. But the consumer must still tell its own software which bucket to use, and it has no way to be told: interpolations reach a definition from five places, and the only one that carries what a provider knows is a bound value, which comes from the provider's serves — a literal block, identical for every consumer. A value derived per consumer has no way into it, and a provisioner's contract returns nothing, so what it derived stays inside it.

So all three consumers transcribed the answer by hand. Two transcribed it right; one named the predecessor's bucket while its key admits only the derived one — authenticating successfully and then being refused on every object, which reads like a credential fault and is not one. It was well-formed, and no check compares such a string to what the provider would actually create.

The general shape, which is why this is filed rather than left in the fix: any interface where the provider names the resource forces the consumer to reproduce the provider's rule in its own definition — a prefixing database provisioner, a vhost-scoping queue provider. That is issue 119's fault with names instead of paths.

The open questions name the two candidate channels — a provisioner returning consumer-visible values, or serves declaring a value as derived from the consumer's identity with the mesh performing the derivation (it already encodes one such rule: the 20-character identity limit exists because of what an object store's access key accepts) — plus the cheap check that would have caught this instance today, without either mechanism.

Checks: cycle 288 documents, the chain holds; records 104, all passed; index current.

The mechanism behind mesh-catalog #96, which fixed the instance but not the cause. The object store derives each consumer's bucket from the login the mesh minted — creating, checking and removing exactly that one — and never reads the bucket a consumer's definition named. But the consumer must still tell its own software which bucket to use, and it has **no way to be told**: interpolations reach a definition from five places, and the only one that carries what a provider knows is a *bound* value, which comes from the provider's `serves` — a literal block, identical for every consumer. A value derived per consumer has no way into it, and a provisioner's contract returns nothing, so what it derived stays inside it. So all three consumers transcribed the answer by hand. Two transcribed it right; one named the predecessor's bucket while its key admits only the derived one — authenticating successfully and then being refused on every object, which reads like a credential fault and is not one. It was well-formed, and no check compares such a string to what the provider would actually create. The general shape, which is why this is filed rather than left in the fix: **any interface where the provider names the resource** forces the consumer to reproduce the provider's rule in its own definition — a prefixing database provisioner, a vhost-scoping queue provider. That is issue 119's fault with names instead of paths. The open questions name the two candidate channels — a provisioner returning consumer-visible values, or `serves` declaring a value as derived from the consumer's identity with the mesh performing the derivation (it already encodes one such rule: the 20-character identity limit exists because of what an object store's access key accepts) — plus the cheap check that would have caught this instance today, without either mechanism. Checks: cycle 288 documents, the chain holds; records 104, all passed; index current.

jschoubben added 1 commit 2026-09-26 14:47:20 +00:00

Issue 124: a consumer cannot be told a value its provider derived for it 146fd6b3a8

The object store derives each consumer's bucket from the login the mesh minted, and never reads the
one a definition named. The consumer still has to tell its own software which bucket to use, and has
no way to be told: bound values come from the provider's serves, which is a literal block identical
for every consumer, and a provisioner returns nothing. So all three consumers wrote the answer down
by hand and one of them wrote the predecessor's bucket — a key scoped to one bucket and software
asking for another, which reads like a credential fault and is not one.

Records the general shape: any interface where the provider names the resource forces the consumer to
reproduce the provider's rule, kept in agreement by hand and checked by nothing.

jschoubben merged commit 5db79cd168 into main

2026-09-26 14:47:25 +00:00

jschoubben deleted branch issue/124-a-consumer-cannot-be-told-what-its-provider-derived

2026-09-26 14:47:25 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#127