Issue 108: the second door was attached to the wrong thing #124

2026-09-26T13:22:21Z

jschoubben commented

2026-09-26 13:22:21 +00:00

Retracts this report's premise, in place, with the reasoning left visible — the same way issue 113 handled its correction.

Two separate things had been treated as one:

The mesh's own artifact store holds the store seat. It is internal by design — reached by name over the overlay, no accounts, because being on that network is the permission (ADR 0082).
Serving a registry publicly is a service the mesh can host, a module with its own name, its own accounts and its own storage, like anything else it runs for somebody.

The conversion this report was written beside gave the seat-holding store a second, public, authenticated door over the same filesystem — which is neither of those things, but the internal store with an external face. That door is not being built. A publicly served registry, if one is wanted, is a module beside the store rather than another way in to it.

What that leaves:

The complication in the title is gone: one registry process on the store's filesystem, so the shared blob-descriptor cache and the deletion-cached-by-the-other-door problem do not arise.
The original issue is untouched and is the whole of it — no garbage collection, and the settings a collection routine depends on are not enabled.
One thing is sharpened rather than removed: deletion on the only door is deletion on a door with no accounts, reachable by everything on the overlay. The predecessor kept deletion behind its authenticated door, which it could, having one. So adding garbage collection now includes deciding whether deletion is exposed there at all, or only ever performed by a routine the mesh runs against its own store.

Title and original text left as written, since the reasoning that assumed two doors is what a reader needs to see retracted. Checks: cycle 286 documents, the chain holds; records 104, all passed; index current.

Retracts this report's premise, in place, with the reasoning left visible — the same way issue 113 handled its correction. Two separate things had been treated as one: - **The mesh's own artifact store holds the store seat.** It is internal by design — reached by name over the overlay, no accounts, because being on that network is the permission (ADR 0082). - **Serving a registry publicly is a service the mesh can host**, a module with its own name, its own accounts and its own storage, like anything else it runs for somebody. The conversion this report was written beside gave the seat-holding store a *second, public, authenticated door over the same filesystem* — which is neither of those things, but the internal store with an external face. That door is not being built. A publicly served registry, if one is wanted, is a module beside the store rather than another way in to it. What that leaves: - The complication in the title is gone: one registry process on the store's filesystem, so the shared blob-descriptor cache and the deletion-cached-by-the-other-door problem do not arise. - The original issue is untouched and is the whole of it — no garbage collection, and the settings a collection routine depends on are not enabled. - One thing is sharpened rather than removed: deletion on the only door is deletion on a door with **no accounts**, reachable by everything on the overlay. The predecessor kept deletion behind its authenticated door, which it could, having one. So adding garbage collection now includes deciding whether deletion is exposed there at all, or only ever performed by a routine the mesh runs against its own store. Title and original text left as written, since the reasoning that assumed two doors is what a reader needs to see retracted. Checks: cycle 286 documents, the chain holds; records 104, all passed; index current.

jschoubben added 1 commit 2026-09-26 13:22:21 +00:00

Issue 108: the second door was attached to the wrong thing c343fc68c5

Two things were treated as one. The mesh's own artifact store holds the store seat and is internal by
design — reached by name over the overlay, no accounts, ADR 0082. Serving a registry publicly is a
service the mesh can host: a module with its own name, accounts and storage, like anything else it
runs for somebody. The conversion this report was written beside gave the seat holder a second public
door over the same filesystem, which is neither.

Keeps the original issue whole — no garbage collection, and the settings a routine needs are not
enabled — drops the two-door complication, and sharpens one thing: deletion on the only door is
deletion on a door with no accounts, which the predecessor kept behind its authenticated one.

jschoubben merged commit 1489d17238 into main

2026-09-26 13:22:55 +00:00

jschoubben deleted branch issue/108-one-door-after-all

2026-09-26 13:22:56 +00:00

jschoubben referenced this pull request

2026-09-26 13:23:08 +00:00

ADR 0115 (proposed): a route may state the largest request body it carries #123

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#124