Nostr NIP archive

NIP-23: NIP-23

Archive reference for NIP-23: what it covers, why it exists and how Crays should read it without copying the standards text.

NIP-23 belongs to the publishing, communities and curated spaces area of Nostr. The public NIP repository is the source of truth; this page gives Crays readers an independent explanation and a navigation point.

What the source document covers

The source headings captured for this NIP include Example Event. That places the document in the product area of long-form content, communities, groups, labels and moderated context.

A NIP is not a landing page and not a promise that every client supports the feature. It is an interoperability document. Readers should treat it as a map of what builders may implement, not as a guarantee of consumer-ready behavior.

  • NIP number. NIP-23.
  • Primary area. publishing, communities and curated spaces
  • Source status. Check the live NIP repository before implementation.

Plain-language interpretation

In plain language, this specification helps clients, relays or services speak a more common language around long-form content, communities, groups, labels and moderated context. The value is interoperability: one app can create or read a structure that another app can recognize.

The tradeoff is that interoperability by itself does not create good UX. A product still has to decide defaults, warnings, labels, recovery paths, empty states, moderation behavior and what happens when another client only partially supports the same convention.

Implementation questions

Before using this NIP in a product, a team should ask whether it is stable enough, whether key material is exposed, whether relays need special support, whether the user can understand the consequence, and whether there is a fallback when support is missing.

For a Crays product, the next question is whether NIP-23 helps profiles, content access, status, payments, venue context, voting, governance or developer operations. If it does not serve one of those paths, it may belong in the archive but not in the first product build.

  • Client support. Which current clients support this NIP well?
  • Relay support. Does the feature require relay behavior beyond storage and subscriptions?
  • Security. Does it affect signing, private messages, authentication, payments or identity?
  • Crays fit. Does it strengthen a real Crays workflow?

Crays relevance

Crays should read NIP-23 through a product lens. The goal is not to expose NIP numbers to normal users. The goal is to turn useful standards into clear actions: create a profile, follow, publish, buy access, receive a zap, show status, enter a venue, vote, authenticate or participate in future governance.

If this NIP becomes relevant to a Crays surface, the page should be expanded with implementation notes, screenshots, supported clients and tested relay behavior.

Back to the Crays Nostr page