The Moshpit resolution policy: which namespace answers a name, and where a navigation ends up.
npm i @moshcoder/moshpit-resolveimport { destinationFor, decideResolution } from "@moshcoder/moshpit-resolve";
await destinationFor("blue.eggs", /* clearnetResolves */ false);
// → https://pit.moshcode.sh/n/blue.eggsApplications that also need to explain the navigation can get the registry answer, policy decision and destination together. This performs at most one registry lookup:
import { resolutionFor } from "@moshcoder/moshpit-resolve";
const resolution = await resolutionFor(hostname, dnsAnswered, settings);
status.textContent = resolution.decision.reason;
if (resolution.destination) navigate(resolution.destination);resolutionFor always returns { registry, decision, destination }. Invalid
names and unavailable registries still produce a complete trace with a
clearnet decision and a null destination, so an app does not need a separate
error shape for those cases.
These rules lived twice in TronBrowser: a TypeScript module, and a hand port of it into the extension because the extension is plain JS with no build step. A test ran both over the same inputs and required identical answers — a suite whose entire job was catching drift between two copies of one decision.
Clearnet wins by default. In clearnet mode the real internet keeps every
name it can answer, and Moshpit fills the gaps. In moshpit mode a registered
name beats a clearnet answer. Which applies is the resolver operator's call.
An unreachable registry degrades to clearnet. A registry that is slow or down must not take a name away from the browser — the failure has to be invisible rather than wrong.
A claimed name with nowhere to point parks rather than dead-ending on a DNS error, and an unclaimed one is an invitation to take it.
Parking and the gateway are the same route. /n/<name> serves a pointed
name and shows a directory for an unpointed one — the same question with two
answers.
destinationFor(hostname, clearnetResolves, config) takes its config. Where
that config lives is the caller's problem — chrome.storage in an extension, a
file on a server, a literal in a test. A library that reached for one of those
would only work in one of those places.
moshpit-resolve <name...> [--moshpit] [--clearnet-resolves] [--registry URL] [--console URL] [--parking URL] [--timeout MS] [--concurrency N] [--strict] [--json]$ moshpit-resolve california.oranges
california.oranges
registry {"registered":true,"resolved":"california.oranges","target":null}
decision park
reason registered in Moshpit but not pointed at an address yet
goes to https://pit.moshcode.sh/n/california.oranges
The reason line is the point: it is the same decision the browser makes on every navigation, and the thing you need when a name goes somewhere unexpected.
Use --json when another tool needs the registry answer, decision, reason, and
destination without parsing the human-readable summary.
By default, an unavailable registry still exits successfully after reporting
the clearnet fallback. Scripts can add --strict to exit non-zero when any
registry lookup is inconclusive; in a batch, one inconclusive lookup fails the
whole run. Resolved, parked, registry-backed clearnet, and reserved console
decisions still exit successfully.
Pass more than one name to inspect a batch in a single process. Results stay in
input order, normalized duplicates share one lookup, and no more than eight
registry requests run at once by default. Use --concurrency to tune that
limit for a self-hosted registry. Multi-name JSON output is an array, while the
existing single-name JSON object is unchanged.
moshpit-resolve blue.eggs red.eggs missing.eggs --json
moshpit-resolve one.eggs two.eggs three.eggs --concurrency 2Registry lookups use an eight-second deadline by default. Scripts and self-hosted deployments can lower it without changing the resolution policy:
moshpit-resolve blue.eggs --registry http://127.0.0.1:8787 --timeout 1500Self-hosted deployments can also route namespace-management names and
unpointed names independently. --console supplies the base for
mosh.<ending>, while --parking supplies the base for names that have no
destination yet:
moshpit-resolve mosh.eggs --console https://console.example --json
moshpit-resolve blue.eggs --parking https://parking.example --jsonMIT.