Publish the pin from the script, so serving a name is one command

[ralyodio]

setup-origin.sh did everything except the step that makes a name usable. It generated the key, wrote the nginx block, verified the certificate — then printed a base64 string and told a human to go paste it in a browser. Until they did, every client refused the name, so the automated part produced nothing that worked on its own.

No browser is needed

The registry's own router already accepts a bearer token alongside a cookie session:

moshpitRouter.use("/api/moshpit", async (req, _res, next) => {
  if (!req.user) {
    const user = await userForApiKey(bearer(req));
    if (user) req.user = user;
  }
  next();
});

So with a key, serving a name becomes genuinely one command:

MOSHPIT_API_KEY=... sh scripts/setup-origin.sh chovy.hacker \
  --target dev.profullstack.com

Key → certificate → nginx → reload → verify → publish the pin → set the target → read it back. Without a key nothing changes: it prints the pin exactly as before.

It reads the pin back

A 201 and "the endpoint clients query actually serves this" are different claims. A pin accepted but not served leaves the name refused with nothing to show for it, so the script confirms rather than assumes:

==> confirming the registry serves it
  chovy.hacker is published and verifiable

--target refuses IPv4 up front

The registry rejects IPv4 literals by design — the rationale is in moshpit-gateway.mjs:

"An A record is a commitment to an address that a name's owner usually does not own for long — IPv4 on a small host is leased, NATed, or shared, and a name pointed at one goes stale silently. Hostnames stay allowed."

The script catches it before the certificate exists, and names the fix (use a hostname) — which the API's own error does not. A hostname is also how a name reaches IPv4-only clients, since the address behind it resolves normally.

Also fixes --help

It was consumed as the name and answered '--help' does not look like a Moshpit name. Pre-existing, not from this change.

Verification

Request shapes checked against a mock registry:

PUT  /api/moshpit/tlds/hacker/names   Bearer …  {"label":"chovy","target":"dev.profullstack.com"}
POST /api/moshpit/tlds/hacker/pins    Bearer …  {"label":"chovy","pin":"v6k99…","kind":"tls","note":"setup-origin.sh"}
GET  /api/moshpit/tlds/hacker/pins?label=chovy

These match the deployed routes' setNameTarget({tld, label, target}) and addPin({tld, label, pin, kind, note}). sh -n clean; the guards for missing --api-key, IPv4 literals and URLs are all exercised.

Not run end to end against the live registry — that needs a real API key, which I don't have. The HTTP layer is verified against a mock; the first real run is still the first real run.

🤖 Generated with Claude Code

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.