Skip to main content

The resolver

The resolver is the product. Everything else is a client of it.

Ask it about a name and it returns a manifest: display name, verification, public contacts, collections, and which collection is active right now.

GET https://api.appsterisk.me/r/metallica

The rendered public profile is one consumer of that manifest. A mobile app is another. So is anything you build.

Designed to be cached

A resolution should be fast and should not require us to be fast. Responses carry cache headers and an ETag derived from the content, so intermediaries can serve them and a burst of traffic to one name is absorbed before it reaches a database.

What it will not tell you

Ask about a name that does not resolve — one nobody has registered, one that is available, one that is suspended, one held back — and you get the same answer: not found.

That is deliberate. Distinguishing them would turn the resolver into a way to discover which names exist and which are in trouble, which is worth more to someone enumerating the namespace than to anyone using it.

QR codes

Every namespace has a QR code, and it encodes the resolver, never a current destination.

That is the entire promise in one property: a code printed on a poster, a business card or a television backdrop keeps working after you change where it sends people, because the code names the identity rather than the destination.

The code is served as SVG, because these end up on posters and a raster QR is the one that fails when someone scales it up.

Scans are counted separately from links and from people typing the name — the third being the case the product exists to make possible.