Services without DNS: an identity-first model using Nostr - Now with punch-able Proof of Concept

An overview of an identity-first service model using NCC-02, NCC-05, and NCC-06, showing how services can be owned, discovered, and reached without relying on DNS. - Now with working PoC client...

Services without DNS: an identity-first model using NCC#

This project demonstrates a working proof of concept for running and discovering services without relying on DNS. Instead of names and registrars, services are anchored to cryptographic identities and published over Nostr using signed, immutable records.

The result is a system where ownership, reachability, and trust are decoupled, verifiable, and client-resolved.

DNS becomes optional, not foundational.

This work is a proof of concept and reference implementation. The specifications, libraries, and sidecar are under active development and should not yet be considered production-hardened. The goal is to validate the model, explore client and relay behaviour, and provide a concrete basis for further review and iteration.

Although this project is demonstrated using Nostr relays, the model is service-agnostic. NCC-02 and NCC-05 apply to any networked service, including APIs, web services, media endpoints, and full web applications. Relays provide the discovery and distribution backbone. The service itself does not need to be a relay, or even Nostr-aware, to participate.

This includes standard web apps. A web application can be discovered, resolved, and reached via NCC records, with clients resolving identity and endpoints independently of DNS.

The components#

NCC-02 – Identity-bound service ownership

NCC-02 defines how a Nostr identity asserts ownership of a service.

An NCC-02 record is a signed Nostr event that binds:

a service identifier using the d tag,
to a controlling npub,
with optional descriptive metadata.

This record answers a single question: who owns this service?

Because the event is signed by the service key, ownership is cryptographically verifiable. Any client can confirm that the service belongs to that identity without relying on DNS, registries, or central authorities.

Key properties:

Services exist as identities, not hostnames
Only the private key holder can update or revoke the record
Multiple services can exist under one identity, distinguished by d
Updates are expressed as new signed events, not mutable records

NCC-02 does not describe where a service runs or how to reach it. It is purely the ownership anchor.

Service record attestations

Service record attestations extend NCC-02 by allowing other identities to make signed statements about a service, without changing ownership.

An attestation is a separate Nostr event that references an NCC-02 service record and asserts some claim about it.

Critically:

The attester does not control the service
The attestation does not modify or replace the NCC-02 record
The claim stands on the reputation of the signer

Ownership remains singular. Claims about the service can be plural.

Attestations are intentionally generic and client-interpreted. They can represent:

operational responsibility
observed availability
validation or compliance checks
authorisation assertions

The NCC system does not interpret or enforce these claims. Clients decide:

which attesters they trust
how many attestations matter
how to handle conflicting or missing attestations

Attestations provide evidence, not authority. They replace central trust anchors with explicit, signed statements evaluated client-side.

NCC-05 – Cryptographic location resolution

NCC-05 defines how a service publishes where it can be reached, independently of DNS.

An NCC-05 record is associated with an NCC-02 service and contains one or more locators, each describing a concrete endpoint:

IPv4
IPv6
Tor onion services

Locators may be public or encrypted using NIP-44, allowing private endpoints to be published safely.

Key properties:

Endpoints are cryptographically bound to the service identity
Multiple locators can coexist in parallel
Endpoints can rotate without changing identity
Clients resolve locations by following identities, not names

NCC-05 does not proxy traffic, establish tunnels, or provide anonymity by itself. It is strictly a location description and resolution mechanism.

Potential service patterns#

NCC-05 enables a range of service models beyond simple dynamic IP resolution:

Private and invite-only services Encrypted locators allow endpoints to be shared only with authorised pubkeys.
Paid or subscription services Access to locators can be gated behind one-off payments or ongoing zap-based subscriptions, with npubs removed from records or endpoints rotated as needed for easy user management.
Ephemeral services Short-lived APIs, temporary collaboration endpoints, or time-boxed access using tight TTLs.
Peer-to-peer rendezvous Two peers discover each other’s endpoints without public signalling, registrars, or coordination servers.
Agent and automation backchannels Bots or agents briefly exposing private control or callback endpoints.
Web apps without DNS Standard web applications reachable via IP or onion, discovered and resolved through identity-bound records instead of hostnames.
Onion-only and censorship-resistant services Services that never publish a public endpoint and rely entirely on private resolution.
Infrastructure mobility and failover Moving services between hosts or networks, or publishing multiple locators with deterministic priority.

Relays act only as the distribution backbone. The services themselves can be arbitrary protocols and do not need to be Nostr-aware.

NCC-06 – Sidecar and operational control plane

NCC-06 operationalises NCC-02 and NCC-05.

The sidecar is a local daemon that:

monitors services across IPv4, IPv6, and Tor
detects meaningful changes in endpoints, certificates, or metadata
publishes updated NCC-02 and NCC-05 records when required
sends encrypted admin notifications using NIP-44
supports secure remote administration via NIP-46

The sidecar does not forward traffic and is not a proxy. It acts as a publisher, monitor, and control plane that keeps service records accurate and current.

Because service identity is decoupled from network location, the sidecar enables rapid endpoint and metadata rotation under a stable identity. Services can move hosts, rotate IPs or onion addresses, update TLS fingerprints, or change publication relays and have the new state published within minutes.

Changing the service’s npub creates a new identity and is treated as a distinct service.

The client’s role#

This model only works because the client is an active participant rather than a passive resolver.

The reference client shows how a client discovers NCC-02 service records, verifies ownership, and then resolves NCC-05 locator records to determine where a service can actually be reached. When locators are private, the client handles decryption using NIP-44 and decides which endpoints it is authorised to see.

The client is also responsible for correlating service records, locator records, and any attestations into a single, coherent view of a service. Trust is not implicit. Each client applies its own policy about which attestations to accept, which identities to trust, and when to fail closed.

Endpoint selection is likewise a client decision. The client chooses between multiple locators deterministically, respecting priority, expiry, and freshness, and automatically follows changes as new records are published. When endpoints rotate or infrastructure moves, the client converges on the new state without manual reconfiguration.

Connections are made directly to the resolved service endpoints. Where required, the client can route traffic to onion services using a local bridge, allowing standard web applications and browsers to participate without special network configuration.

In this architecture, relays act purely as the distribution layer and the sidecar keeps service records accurate over time. The client is where meaning is enforced. What to trust, where to connect, and how to react to change are all resolved locally, without any global authority.

How it fits together#

NCC-02 answers: Who owns this service?
Attestations answer: What do others claim about it?
NCC-05 answers: Where can it be reached?
NCC-06 keeps all of the above accurate over time

All components use:

immutable, signed Nostr events
client-side resolution
no DNS, PKI, or naming authorities

Why this matters#

DNS-based service discovery couples identity, location, and trust into a brittle hierarchy. NCC separates these concerns:

identity is cryptographic
location is declarative and rotatable
trust is explicit and plural
resolution is client-driven

This makes services more portable, harder to censor, easier to migrate, and independently verifiable.