Nostr Kinds — Design and Schema

Load this skill when:

• Minting a new event kind for a Ditto feature.
• Extending an existing NIP with new tags.
• Deciding whether an existing NIP covers a use case or whether a custom kind is warranted.
• Documenting a custom kind or extension in NIP.md.

Not this skill — if an existing NIP/kind covers your use case and you only need to render it in Ditto's UI, use the nostr-kind-rendering skill instead.

Choosing Between Existing NIPs and Custom Kinds

1. Thorough NIP review first. Browse the NIP index, then read candidate NIPs in detail. The goal is to find the closest existing solution.
2. Prefer extending existing NIPs over creating custom kinds, even at the cost of minor schema compromises. Custom kinds fragment the ecosystem.
3. When an existing NIP is close but not perfect, use its kind as the base and add domain-specific tags. Document the extension in NIP.md.
4. Only mint a new kind when no existing NIP covers the core functionality, the data structure is fundamentally different, or the use case requires different storage characteristics (regular vs. replaceable vs. addressable).
5. If a tool to generate a new kind number is available, you MUST call it. Never pick an arbitrary number.
6. Custom kinds MUST include a NIP-31 alt tag with a human-readable description of the event's purpose.