Research 013: the forge and the registries — a seat answers the wrong question #82

2026-09-22T22:38:46Z

jschoubben commented

2026-09-22 22:38:46 +00:00

Asked during the first migration: should the mesh have a mesh-scoped git seat, the way it has one for the store and the broker? Answered from the code rather than from memory.

No, and the question points at a different hole. A seat does two things: it refuses a second claimant at resolution, and in one place it answers where the broker is. Every symptom around the forge — the builder's literal address, the port that would not follow a node, the takeover that is not a takeover — is about an address and a credential nobody resolves, which a seat does not answer.

What the survey found: the forge's git service is declared nowhere, so nothing can require it; package-registry is a fully built provision with zero consumers, because the builder carries a file naming the module, 127.0.0.1 and the port instead; the builder is told where source lives per build by a person, with no credential and no way to re-point a moved forge; and the four mesh-scoped seats that exist are all singular servers the mesh runs for its own working, which a forge is not. A git seat would also forbid a second forge, which an earlier record already argues should be allowed.

Two corrections to existing issues came out of it, both checked in the code:

090 — the bootstrap forge and its module differ in a fifth way, the image digest, while a comment says they are pinned identically.
085 — the forge's registration at genesis is skipped on a default port, so the ordinary mesh raises a forge the controller has never heard of, holding a port it has not reserved.

The open question is whether the forge's git service should become a provision the builder requires, which is the unanswered half of 085. The obstacle is known: such a requirement may go unanswered during genesis, and the mesh has no optional requirement.

Asked during the first migration: should the mesh have a mesh-scoped git seat, the way it has one for the store and the broker? Answered from the code rather than from memory. **No**, and the question points at a different hole. A seat does two things: it refuses a second claimant at resolution, and in one place it answers where the broker is. Every symptom around the forge — the builder's literal address, the port that would not follow a node, the takeover that is not a takeover — is about **an address and a credential nobody resolves**, which a seat does not answer. What the survey found: the forge's git service is declared nowhere, so nothing can require it; `package-registry` is a fully built provision with **zero consumers**, because the builder carries a file naming the module, `127.0.0.1` and the port instead; the builder is told where source lives per build by a person, with no credential and no way to re-point a moved forge; and the four mesh-scoped seats that exist are all singular servers the mesh runs for its own working, which a forge is not. A git seat would also forbid a second forge, which an earlier record already argues should be allowed. Two corrections to existing issues came out of it, both checked in the code: - **090** — the bootstrap forge and its module differ in a fifth way, the image digest, while a comment says they are pinned identically. - **085** — the forge's registration at genesis is skipped on a default port, so the ordinary mesh raises a forge the controller has never heard of, holding a port it has not reserved. The open question is whether the forge's git service should become a provision the builder requires, which is the unanswered half of 085. The obstacle is known: such a requirement may go unanswered during genesis, and the mesh has no optional requirement.

jschoubben added 1 commit 2026-09-22 22:38:46 +00:00

Research 013: the forge and the registries — a seat answers the wrong question; issues 090 and 085 corrected from the code 43b55d6664

jschoubben merged commit 0d8b683ad7 into main

2026-09-22 23:03:11 +00:00

jschoubben deleted branch research/013-the-forge-and-the-registries

2026-09-22 23:03:11 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#82