Services without DNS: an identity-first model using Nostr - Now with punch-able Proof of Concept
## 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.
DNS becomes optional, not foundational.
---
### Code and references
* Proof-of-concept client
[https://github.com/imattau/ncc-client](https://github.com/imattau/ncc-client)
* NCC-06 sidecar and library
[https://github.com/imattau/ncc-06](https://github.com/imattau/ncc-06)
* NCC-02 spec and library
[https://github.com/imattau/ncc-02](https://github.com/imattau/ncc-02)
* NCC-05 spec and library
[https://github.com/imattau/ncc-05](https://github.com/imattau/ncc-05)
NPM Libraries used: `ncc-02-js`, `ncc-05-js`
#nostr #builders #privacy #p2p #tor #dns #decentralization #nostrdevs #ncc #npm #js
