Fifteen Calls a Name

The resolver protects its caller and not itself

HttpResolver.hs is careful about exactly this: brReadSome maxResponseBytes, redirectCount = 0, an explicit timeout, with a comment explaining that adversarial endpoints must not be able to exhaust memory. The resolver then calls its own upstream with urlopen(req, timeout=15).read() — a timeout, and no size cap at all.

An RPC endpoint that is compromised, misconfigured or simply pointed at the wrong host can return a body large enough to end the process. The threat model was written down one layer up and not applied one layer down.

http.server is documented as not for production, and this is production

CPython's own docs say http.server "is not recommended for production. It only implements basic security checks." There are no request size limits, no header count limits and no slow-read protection. It is fronted by nothing — the compose file exposes the port directly.

This is a reasonable choice for a script and an unreasonable one for a service an smp-server depends on for name resolution. Worth a decision rather than an accident: either it stays a dev tool and the deployment path puts a real server in front, or it becomes a service and gets one.

Three error shapes, so a client needs three error handlers

An unhappy response is one of:

{"name": …, "error": …, "configured_tlds": [...]}   TLD not configured
{"error": …, "got": …}                              not fully qualified
{"address": …, "error": …}                          bad address
{"name": …, "status": …, "error": …, …}             lapsed / unregistered

The key naming the subject changes, status is present on some and not others, and configured_tlds appears in two of them and not the third. A client cannot write one function that turns a failure into a message.

Two casing conventions in one document

simplexContact, simplexChannel, checkedTlds, graceEnds are camelCase — the file says why, so aeson can derive field names without a rewriting layer. configured_tlds is snake_case, in the same response body.

I added checkedTlds directly alongside the existing configured_tlds without noticing they disagree, which is how a convention with one exception becomes a convention with two.

/health cannot tell an operator whether the new endpoint will work

Health reports registries and not REGISTRARS. Since /owned-by and every expiry field depend entirely on the registrar being configured, an operator who has set only the registry gets a healthy resolver, a working /resolve, "status": "unknown" on every name, and a 400 from /owned-by — with nothing in the health check hinting why.

I added the configuration and the dependency on it, and left the diagnostic reporting the older half.

Nothing anywhere says which resolver you are talking to

The response payload just grew three fields. A client written last month and one written today receive different documents from the same URL, and neither can ask which it is. There is no version in the path, no version in /health, and no capability list.

This matters more now than it did: status and expires are load-bearing for a renewal reminder, and a client cannot tell whether their absence means "not supported here" or "not knowable for this name".

Truncation is a dead end, not a page

/owned-by stops at SNRC_MAX_OWNED and sets truncated: true. There is no offset, no cursor and no ordering guarantee a caller could resume from, so an address holding more than 256 names in a TLD has no way to see the rest — the flag is honest about the problem and offers no way out of it.

truncated is also a single boolean over a merged multi-TLD result, so it does not say which registrar ran out.

The schema is a Haskell type in another repository

Names/Record.hs says "the Haskell type IS the schema", which serves the one consumer written in Haskell and nobody else. A TypeScript or Python client has the README and a curl example. There is no OpenAPI document, no JSON Schema, and no fixture file to test against.

The claim is also now slightly untrue: the resolver returns status, expires and graceEnds, and the record type has none of them — safely, since aeson ignores unknown fields, but the two have diverged and only a comment asserts they have not.