Crays NIP Strategy
The product decision matrix for which Nostr standards we should use now, prepare next, keep as reference or avoid.
The Crays Nostr product should not chase NIP numbers for their own sake. Each standard has to earn its place in a real user flow: login, discussion, source review, project submission, moderation, relay strategy, media, search, People | Users or crawler evidence.


The key correction
NIP-72 was requested because it describes Reddit-style moderated communities, but the current upstream NIPs repository marks it unrecommended and points new group work toward NIP-29. We still keep NIP-72 as compatibility because existing clients and references use it, but the durable our product path should be NIP-7D forum threads, NIP-22 comments, NIP-29 relay-based groups, NIP-32 labels and NIP-56 reports.
That lets us build a product that feels like a Nostr-native Reddit without betting the whole architecture on one discouraged standard.
- Forum roots. NIP-7D kind 11 starts durable topic threads.
- Replies. NIP-22 kind 1111 attaches comments to pages, events and forum roots.
- Groups. NIP-29 becomes the enforced community layer when Crays runs or partners with a relay.
- Compatibility. NIP-72 stays supported for clients and communities that already understand it.
Decision tiers
This is the practical gate for implementation. Use-now NIPs can appear in the current product design. Prepare-next NIPs are planned but need backend, relay, media, wallet or moderation infrastructure. Reference-only NIPs stay in the archive. Avoid NIPs are deprecated, unrecommended or wrong for new our product surfaces.


What this lets the community do
The community product is not a comment box. It is a signed work system: ask, answer, submit, nominate, review, label, report, vote, claim projects, attach sources and eventually merge accepted evidence into stable our pages.
The NIP choices below map directly to those jobs.
- Community login. NIP-07, NIP-46, NIP-19, NIP-49 and NIP-98 keep identity usable without server-side private keys.
- Discussions. NIP-7D, NIP-22, NIP-25, NIP-32 and NIP-56 create forum threads, replies, votes, labels and reports.
- Groups. NIP-29 gives the future Crays relay a real membership/moderation boundary.
- Project submissions. NIP-34, NIP-78, NIP-89, NIP-99 and NIP-B0 map repos, app handlers, listings and source bookmarks.
- People | Users. NIP-05, NIP-24, NIP-39, NIP-51, NIP-65 and NIP-85 support identity, public links and trust signals.
- Crawler and search. NIP-11, NIP-45, NIP-50, NIP-66, NIP-73, NIP-84 and NIP-B0 turn fresh discoveries into reviewable evidence.
- Media. NIP-92, NIP-94 and NIP-B7 are the safer media direction; NIP-96 is deprecated.
- Moderation. NIP-09, NIP-32, NIP-36, NIP-40, NIP-56, NIP-70 and local review states keep the archive from becoming chaotic.
All current NIPs: Crays decision matrix
This matrix is intentionally product-oriented. It does not claim every NIP is bad or good in general; it says whether we should use it for the living Nostr hub now.
Hard product rules
A NIP is not a feature until the user can understand what they are signing, where it appears, how it is moderated and whether it can change an editorial page. These rules protect the product while still inviting the Nostr community in.
- No server-held keys. The Community login path must never send private keys to us.
- No NIP-72-only bet. NIP-72 remains compatibility, not the only community architecture.
- No blind crawler publishing. Crawler output becomes findings and review items, never instant editorial content.
- No deprecated media path. Use Blossom/NIP-B7 for the future media path instead of NIP-96.
- No DVM core dependency. NIP-90 is interesting for automation history, but not the first automation spine because upstream warns against it.
