CEP-15 web feature

[ContextVM-org]

Integrate CEP-15 in the website. Use CEP-15 tags to navigate a catalog of servers implementing these tools. Create a new page for catalog, and include backlinks between server page and catalog page

[abhayguptas]

Hi, @ContextVM-org! I did some research and here is the plan -

Approach that I am thinking

I went through the website codebase to understand the current data flow and figure out what's needed. The site already fetches kind:11317 events and renders tools on server pages, but the CEP-15 tags (i, k, t) and _meta.schemaHash are not being used anywhere in the UI yet. So the main job is to surface that data in a way that helps users discover and compare providers.

I'm planning to break this into three incremental PRs:

PR 1 - Data layer

• Utility functions to extract CEP-15 tags and _meta.schemaHash from events
• Nostr filters for #k and #i tag queries (from CEP-15 Section 4.1)
• Loaders and query hooks following the existing pattern used by the servers page

PR 2 - Catalog page

• New catalog page showing common tool schemas grouped by schema hash
• Each entry shows the tool name, provider count, and category tags
• Search by tool name, filter by category
• A detail page listing all providers for a given schema, linking to their server pages
• Add catalog link to the header navigation

PR 3 - Cross-navigation

• On server detail pages, show which common schemas the server implements in the sidebar
• On tool cards, add an inline badge when the tool implements a common schema, linking to the catalog
• Back-links between catalog and server pages so navigation flows both ways

Questions

Routing and structure

• What should the catalog route be - /catalog, /schemas, or something else?
• Should the catalog link go in the main header nav alongside Servers and Blog, or sit as a sub-section under Servers?
• For schema detail, should it be a separate page (/catalog/[hash]) or inline expansion on the catalog page?

UI and design

• For the catalog page, should the look and feel match the current servers grid layout, or are we going for a different style - something more like a marketplace with sidebar filters?
• On server detail pages, where should the common schemas info live - as a new sidebar card, a section within the About tab, or something else?
• How should we handle the schema hash visually? Truncated with a copy button, or hidden behind a tooltip?
• Any preference on how category tags should look - colored pills, plain text labels, or something else?

Data and scope

• Should categories come only from t tags that servers publish, or should we derive fallback categories from tool names when t tags are missing?
• Are there any test servers currently publishing CEP-15 tags that I can use during development?

Suggestions

A few things I think would be worth adding beyond the core requirements:

• Hash verification indicator - CEP-15 says clients should verify the schema hash. We could recompute the hash client-side and show a small verified badge on provider listings. Builds trust and aligns with the spec.

• Catalog summary on the landing page - A small section showing how many common schemas and providers exist, linking to the catalog. Makes the feature visible from the home page.

• Cross-schema discovery - On the schema detail page, if a provider also implements other common schemas, show those as secondary links. Helps users find multi-tool servers.

[ContextVM-org]

Great analysis, I think a /catalog page and /catalog/[hash] would be the right approach. In the root catalog path we can show the servers implementing a specific hash and group them by it.
In the other hand I think the catalog link doesn't need to appear in the header, it works as subs section in the servers page, and also in each server page if it implements a common tool schema. So we can have that backlink functionallity.
I think we can just render the hash truncated in the server information page and that serves as link. You can explore if bare strings or maybe use a badge, both can work. Copy button seems good, but not super useful.
Categories should come from the server announcement, no infer them from the name or similar, if they are absent just don't show them. Indeed I think that we could extend a bit the api surface of cep 15 in the sdk so server operators can set their categories through that api.
Wdyt?

[ContextVM-org]

In the other hand I will update relatr today to use cep-15 so we can have it as a way to test.

[abhayguptas]

Makes total sense! I agree with all these points.

Just to confirm the updated plan based on your feedback:

• I'll go with the /catalog and /catalog/[hash] routing.
• I'll keep the header nav clean and instead add the catalog link as a sub-section on the /servers page, as well as on individual server pages for the backlinks.
• I'll render the truncated hash as a badge/link (and skip the copy button to keep the UI clean).
• I'll stick strictly to the published t tags for categories. I completely agree that making it easier for server operators to set categories via the SDK API later on is the best long-term solution.

I'll get started on PR 1 (the data layer) and open it up for review soon!