What it is, what it isn’t, and why it exists
Right now, there is no standard way to discover how to reach a Nostr-related service using Nostr itself.
In practice, service connection details are typically published in README files, project websites, or social posts. A human reads this information and configures the client manually. There is no standard way for clients to discover or resolve these details automatically.
This approach works most of the time, but it breaks down in predictable ways. Services move. Endpoints rotate. Onion services appear. Relays go offline. Clients are forced to rely on assumptions that are rarely written down in a form software can use.
NCC-06 exists to address this problem directly.
It defines an identity-first relay participation profile that allows relays to be discovered, resolved, and connected to using signed Nostr data, without relying on DNS or central registries.
This does not change the Nostr protocol. It does not introduce new message types. It does not move logic into relays.
Where NCC-06 fits
NCC-06 builds on existing conventions rather than replacing them.
The responsibilities are deliberately separated:
NCC-02 describes how service records are published and updated. NCC-05 describes how locators and endpoints are represented and resolved across network contexts. NCC-06 defines how relays, sidecars, and clients use those records together to decide how a relay is reached.
Each convention does one job. NCC-06 focuses on reachability and robustness, not naming, trust enforcement, or protocol changes.
What NCC-06 defines
NCC-06 defines an opt-in relay participation profile for relays that choose to publish and serve NCC-02 and NCC-05 records describing themselves.
Relays conforming to NCC-06:
Are addressed by Nostr identity, not by hostname
Publish their service state as signed events
Remain fully compatible with NIP-01 clients at the protocol level
Remain protocol-dumb with respect to resolution and trust
NCC-06 also defines normative client and sidecar behaviour to handle real-world failure modes, without moving that logic into relays.
Identity-first addressing
Under NCC-06, a relay is identified by its service identity, a Nostr public key.
Clients may refer to such relays using identity-based references (for example wss://), but these references are not network endpoints.
They are identity references only.
Clients must resolve these references using NCC-02 and NCC-05 before attempting any network connection. Relays must not interpret, dereference, or act on identity-based references.
This keeps identity, location, and transport cleanly separated.
What relays do (and do not do)
Relays conforming to NCC-06:
Implement NIP-01 normally
Accept, store, and serve NCC-02 and NCC-05 events as ordinary data
Publish at least one NCC-02 Service Record and one NCC-05 Locator describing themselves
Return their own records when queried using standard filters
Relays do not:
Resolve identities for clients
Select endpoints
Validate trust material
Enforce k bindings
Proxy or redirect connections
Relays remain neutral event stores.
The role of sidecars
NCC-06 assumes that service state is published by a sidecar or equivalent process operated alongside the relay.
The sidecar is responsible for:
Publishing NCC-02 Service Records
Publishing NCC-05 Locator records
Keeping published records aligned with actual service state
Rotating records when endpoints or keys change
To avoid single points of failure, NCC-06 requires publication redundancy.
Sidecars must publish records to:
the relay itself when reachable, and
at least one additional relay in a configured publication relay set
This ensures records remain discoverable even if the relay being described is temporarily unreachable.
Key and endpoint lifecycle management
Under NCC-06, sidecars are responsible not only for publishing records, but for ensuring that published records accurately reflect the material they describe.
This includes cryptographic keys and network endpoints.
Key creation and rotation
When a relay exposes a transport that relies on cryptographic identity, the sidecar is responsible for ensuring the corresponding keys are created, managed, and accurately reflected in published records.
In practice this includes:
Generating or observing TLS key material for wss:// endpoints
Computing and publishing the corresponding NCC-02 k value
Ensuring the published k matches the key actually presented by the endpoint
Republishing NCC-02 Service Records when keys change or rotate
NCC-06 does not mandate how keys are generated or stored. It requires only that published assertions remain aligned with reality.
Relays do not generate, validate, or reason about these keys.
Onion address creation and management
When a relay offers onion endpoints, the sidecar may be responsible for creating and operating the onion service, or for observing an externally managed onion service and publishing updates when it changes.
This typically involves:
Creating or monitoring a Tor hidden service using existing Tor tooling
Managing or observing onion service keys and configuration
Detecting onion address rotation or regeneration
Republishing NCC-05 Locator records when onion endpoints change
NCC-06 does not invent a new onion mechanism. It assumes the use of existing Tor services and tooling.
The sidecar’s responsibility is to observe changes and reflect them in NCC-05, not to expose Tor internals to relays or clients.
Keeping records aligned with service state
A core responsibility of the sidecar is to ensure that published records describe reality, not intent.
This includes:
Republishing NCC-02 Service Records when endpoint keys change
Republishing NCC-05 Locators when endpoints appear, disappear, or move
Avoiding stale records that no longer match reachable services
Publishing updates before expiry where possible
Failure to keep records aligned results in predictable client failure. NCC-06 makes this failure visible rather than implicit.
End-to-end flow (identity to connection)
User / App | v Client (given relay identity) | | fetch NCC-02 + NCC-05 records v Publication Relay Set ^ | redundant publish | Sidecar
- manages keys and onion service
- publishes service + locator records | v Client Resolution (NCC-06)
- validate + select records
- cache / stale fallback
- ordered endpoint attempts
- apply trust policy | v Concrete Endpoint | v Relay (protocol-dumb, NIP-01)
Deterministic client behaviour
NCC-06 defines explicit client behaviour for real-world failure and ambiguity.
Clients implementing NCC-06 are expected to behave deterministically when faced with:
Conflicting records
Partial endpoint availability
Relay unavailability
Stale or expired data
Multiple valid connection paths
The goal is convergence and predictable behaviour, not correctness enforcement by infrastructure.
What NCC-06 is not
NCC-06 does not:
Replace DNS
Define a naming system
Guarantee availability
Prevent Sybil attacks
Enforce trust or moderation policy
Require protocol changes
It is strictly about composing identity, location, and reachability using existing Nostr primitives.
Status
NCC-06 now defines a complete relay participation profile, including:
what relays publish and serve
how sidecars publish redundantly
how clients resolve, cache, and fall back
The remaining work is implementation and validation.
Who this is for
NCC-06 is not aimed at end users.
It is for:
Client developers
Relay operators experimenting with identity-first deployment
Builders of Nostr-identified services
Anyone interested in DNS-optional discovery
If you are not building software, this document can safely be ignored.
Closing
NCC-06 shows that robust service discovery does not require protocol changes, DNS dependence, or smarter relays.
It relies instead on:
signed assertions
redundant publication
deterministic client behaviour
- Relays stay simple.
- Clients stay in control.
- Failure is expected, not exceptional.
That is the design.