Protocol · Semantics

HNS

The Hop Name System

1 · resolve a name one HTTPS GET · /.well-known/hop 2 · no internet use the address directly client TLS ✓ · sig ✓ acme.hop 🔒 TLS · well-known acme.hop → hop:7f3a…9c2 · a key, not an IP · TLS + sig ✓ GET well-known signed reach record radio-only hop:7f3a…9c2 · self-certifying, no lookup
Resolving acme.hop is one HTTPS GET of its /.well-known/hop. The TLS certificate proves the responder is really acme.hop; the signed reach record proves the Hop address, signed by the address itself. The client checks both, then talks straight to the key. A device with no internet skips the lookup and is handed the self-certifying address directly.
How it works
  • Resolving a name is a single HTTPS fetch of the domain's /.well-known/hop, no DNS, no central resolver. The domain serves a signed reach recordReach record: a signed statement "I, address X, am reachable at this endpoint". The signature is by X itself, so it self-certifies, a forged address or endpoint just fails the check. that binds its name to a Hop address.
  • Two independent proofs make the bind trustworthy: the fetch's TLSTLS / WebPKI: the same certificate check a browser does. It proves the responder really is example.com, so only the domain's operator can serve the record. certificate proves the domain, and the reach record's signature proves the address, signed by the very key it claims.
  • Resolution needs the resolving device's own internet, on purpose: there's no relayed lookup to trust. A radio-only device can't fetch a name and is handed the address directly instead, which is self-certifying and needs no lookup at all.
Why it matters
For developers

Names map to keys, not IPs. The host does one HTTPS GET of /.well-known/hop and hands hop-core the raw bytes; core verifies the self-certifying signature and caches it. Publish an endpoint by serving a signed reach record at your domain's well-known.

For business

Verifiable names anchored on the certificate your domain already has. A name can't be spoofed without both the site's TLS key and the endpoint's identity key, and the client checks both itself.

Deeper implementation detail is coming in the Hop whitepaper.

Ready to build on it?