BRC-180

Overlay Service Discovery at an Internet Domain

If you know a domain runs some kind of overlay service, there was no standard place to find out where to actually send requests for it. You'd end up guessing at conventions like an api. subdomain, or asking around, with no way to be sure you weren't just hitting the wrong host. This gives a domain one clear file where it states, service by service, which URL to use.

David Case20 Sept 2026changed 22 Sept 20262 min read

Reference for an AI

Everything an assistant needs to answer questions about BRC-180 accurately, including what it depends on.

Why: A client that knows a domain offers an overlay service still has no way to find the URL it actually runs on without guessing at naming conventions.
What: BRC-180 defines a metanet.overlays object in a domain's manifest.json that maps each overlay service name it hosts to the base URL a client should use to reach it.
How: A domain adds a metanet.overlays object to its /manifest.json mapping each BRC-22 topic manager or BRC-24 lookup service name to the base URL that serves it, and a client fetches that file to resolve where to send requests for a named service.

What this lets you do

Publish a list of overlay services a domain hosts, in its manifest.json
Look up which base URL serves a given topic manager or lookup service for a domain
Point different services at different hosts, even ones the domain doesn't run itself
Skip probing or guessing hostnames like api.example.com
Ignore unrecognised entries safely when reading another domain's manifest

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

The specification

Read the original

Abstract

A domain declares the overlay services it hosts in a metanet.overlays object in its /manifest.json, mapping service names to the base URL that serves them.

Motivation

Application URLs name domains, and a domain's overlay is routinely hosted somewhere other than its website. Without a declaration a client is left guessing at conventions such as an api. prefix. BRC-68 established /manifest.json as where a domain publishes details about itself, and BRC-73 and BRC-169 added their own objects there; this adds one for overlay services.

BRC-88 answers a different question. [object Object] tells a client which hosts serve a topic anywhere on the network. This tells it what one named domain hosts. The two are complementary.

Specification

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119.

A domain hosting overlay services publishes a metanet.overlays object in the /manifest.json served at its root:

{
  "metanet": {
    "overlays": {
      "tm_example": "https://api.example.com",
      "ls_example": "https://api.example.com",
      "tm_other": "https://other.example.net/overlay"
    }
  }
}

Each key is the name of a BRC-22 topic manager or BRC-24 lookup service, exactly as it is named in submission and lookup requests. The BRC-87 naming conventions distinguish the two, so the map needs no further structure.
Each value is the base URL a client resolves that service's routes against. Those routes are defined by BRC-22, BRC-24 and the service's own specification, and MUST NOT be respecified here.
Services MAY name different hosts, including hosts the domain does not control.
A client MUST ignore keys it does not recognise.

To resolve a domain, a client fetches https://<domain>/manifest.json and reads metanet.overlays. If the document, the object, or the entry for the service sought is absent, that domain does not offer that service; the client MUST NOT probe hostnames or contact a host the user did not name.

A domain declares what it chooses to declare, secured by control of the domain. A client MUST NOT infer that a declared host is trustworthy, only that the domain claims it.

Was this helpful?