## Semantic Catalog of Nostr Kinds

### Goal

The goal of this project is to create a catalog of Nostr kinds that can be searched by user intent, rather than only by kind number, name, or referenced NIP.

The catalog should help answer practical questions such as:

* Which kind should be used to publish a product for sale?
* Which kinds and tags should be queried to find product listings?
* Which kind is appropriate for an editable long-form article?

### Kind Documents

Each kind will be represented as a separate, mostly self-contained document.

The document should include:

* the purpose of the kind,
* typical use cases,
* event structure,
* required and optional tags,
* validation rules,
* limitations,
* client and relay behavior,
* rules inherited from all related NIPs,
* differences from similar kinds.

Some information may intentionally be repeated across multiple kind documents. This denormalization is useful because semantic search works better when each record contains enough context to be understood and ranked independently.

### LLM-Based Generation and Maintenance

The catalog will be created and maintained with the help of an LLM.

The model will analyze NIPs, identify kinds and their extensions, extract rules, tags, constraints, and dependencies, and then generate complete descriptions for the affected kinds.

When the Nostr specification changes, the relevant documents can be regenerated or updated automatically. Because this maintenance is performed by an LLM, duplication is less costly than it would be in a manually maintained database.

Each extracted rule should retain a reference to its source NIP. Normative requirements such as `MUST`, `SHOULD`, and `MAY` should also be clearly separated from model-generated explanations, interpretations, and implementation notes.

### Main Use Cases

The catalog will support two main workflows.

First, it will help search the existing Nostr graph by identifying which kinds, tags, and relationships are relevant to a specific need.

Second, it will help create new events by recommending the appropriate kind, event structure, tags, and constraints for a planned feature.

The final system should return the most relevant kinds, explain why they match the request, and show important differences between possible alternatives.

