Skip to content

Declare the gib overlay in the manifest, per BRC-180 - #3

Merged
shruggr merged 1 commit into
mainfrom
feat/brc-180-overlays
Sep 20, 2026
Merged

shruggr merged 1 commit into
mainfrom
feat/brc-180-overlays

Conversation

@shruggr

@shruggr shruggr commented Sep 20, 2026

Copy link
Copy Markdown
Collaborator

BRC-180 adds a metanet.overlays object to /manifest.json: a map from overlay service name to the base URL a client resolves that service's routes against. It answers what does this domain host — complementary to BRC-88 SHIP, which answers who on the network serves this topic. It sits alongside the BRC-73 groupPermissions block already in the same metanet namespace.

As served:

"overlays": {
  "tm_gib": "https://api.1sat.app/1sat/gib/overlay",
  "ls_gib": "https://api.1sat.app/1sat/gib/overlay"
}

Service names

Exactly the two services the 1Sat stack runs for gib, and nothing else — the stack hosts other overlays, but this site has nothing to do with them. Verified two ways:

  • TopicName = "tm_gib" and LookupName = "ls_gib" in 1sat-stack pkg/gib/config.go (the constants pkg/gib/topic.go and pkg/gib/lookup.go report as their metadata).
  • Live on the host: GET /1sat/gib/overlay/listTopicManagers → {"tm_gib":…}, listLookupServiceProviders → {"ls_gib":…}.

Why the value carries a path

This is the one part that deviates from the brief, deliberately. BRC-180 keys name BRC-22 topic managers and BRC-24 lookup services, so the base has to be where those routes live. On api.1sat.app:

Path Status
POST /submit 404
POST /lookup 404
GET /listTopicManagers 404
POST /1sat/gib/overlay/submit 400 (reached the handler)
GET /1sat/gib/overlay/listTopicManagers 200

A conforming client handed the bare host would POST to https://api.1sat.app/submit and get a 404. The stack's plain REST routes (/1sat/gib/heads, /1sat/beef/{txid}) and ORDFS /content/… do resolve against the root, which is what makes the bare host tempting — but a BRC-180 consumer is not calling those. The Go CLI splits it the same way: internal/remote/client.go keeps a host-only Base and appends its own OverlayPath = "/1sat/gib/overlay" before submitting. The spec's own example includes a path-bearing value for the same reason.

Derivation

Both values are built with stackApiUrl from lib/stack.ts, so the manifest follows NEXT_PUBLIC_ONESAT_STACK_URL and the hostname is never written down twice.

Untouched

PWA fields, groupPermissions, babbage.trust, and the access-control-allow-origin: * header.

Verified

bun run lint, bun run typecheck, bun test (37 pass), bun run build all pass. Fetched /manifest.json from a dev server: the object parses and sits inside metanet next to groupPermissions, with the CORS and cache headers intact.

Docs updated in AGENTS.md (route table plus a new section on the path, since it is the easy thing to get wrong) and skills/gibhub/SKILL.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EM5trZ4BfZpW7pBjq2onqX

BRC-180 (bsv-blockchain/BRCs#262) adds a `metanet.overlays` object to
`/manifest.json`: a map from overlay service name to the base URL a client
resolves that service's routes against. It answers "what does this domain
host", which BRC-88 SHIP does not — SHIP says who on the network serves a
topic, this says what one named domain claims.

gibhub declares exactly the two services the 1Sat stack runs for gib and
nothing else: `tm_gib` and `ls_gib`, verified against `TopicName` and
`LookupName` in 1sat-stack's `pkg/gib/config.go` and against the live
`listTopicManagers` / `listLookupServiceProviders` on api.1sat.app. The
stack hosts other overlays; this site has nothing to do with them.

Both values are `${STACK_URL}/1sat/gib/overlay`, built with `stackApiUrl`,
so the manifest follows NEXT_PUBLIC_ONESAT_STACK_URL instead of repeating
the hostname. The path matters: BRC-180 keys name BRC-22 topic managers and
BRC-24 lookup services, and the stack mounts `/submit`, `/lookup` and the
list routes under `/1sat/gib/overlay` — at the stack root they 404. The
stack's plain REST routes and ORDFS `/content/…` resolve against the root,
but a BRC-180 consumer is not calling those. The Go CLI splits it the same
way, keeping a host-only `Base` and appending its own `OverlayPath`.

The PWA fields, the BRC-73 `groupPermissions` block, `babbage.trust` and
the CORS header are untouched.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01EM5trZ4BfZpW7pBjq2onqX
@vercel

vercel Bot commented Sep 20, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
gibhub Ready Ready Preview Sep 20, 2026 5:53pm UTC

Request Review

@shruggr
shruggr merged commit aadad1c into main Sep 20, 2026
3 checks passed
@shruggr
shruggr deleted the feat/brc-180-overlays branch September 20, 2026 17:53

This branch was successfully deployed

1 active deployment
Preview — a3d19e3d Deployed Sep 20, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant