Implement CEP-15 Web Catalog Integration

[abhayguptas]

This pull request implements the CEP-15 (Common Tool Schemas) integration for the ContextVM website. It introduces a catalog that allows users to discover servers based on the standard tools they implement.

This PR is being built incrementally. The checklist below outlines the implementation phases.

Implementation Plan

• Phase 1: Data Layer & Core Utilities

  • Implement parsing utilities for i, k, and t tags and _meta.schemaHash.
  • Add Nostr filters for CEP-15 discovery (#k and #i).
  • Create reactive Applesauce models (CatalogSchemasModel) with strict pubkey deduplication.
  • Implement SvelteKit loaders and TanStack Query hooks for isolated data fetching.

• Phase 2: Catalog UI & Routing

  • Add "Browse Common Schemas" section to the /servers page.
  • Build the /catalog route grouping all schemas.
  • Build the /catalog/[hash] route listing providers for a specific schema.

• Phase 3: Cross-Navigation & Server Details

  • Render truncated hash badges as backlinks on the server information page.
  • Add inline badges on ToolCallForm.svelte to link back to the catalog.

Testing

The data layer is being verified locally using nak serve alongside the relatr test server to ensure isolated event parsing.

Closes #27

[vercel]

@abhayguptas is attempting to deploy a commit to the ContextVM's projects Team on Vercel.

A member of the Team first needs to authorize it.

[abhayguptas]

Hi, @gzuuus!

Phase 1 (Data Layer) is complete and pushed.

I have implemented the tag parsing utilities, Nostr filters, timeline loaders, and the Applesauce models for grouping the schemas. The model strictly deduplicates kind:11317 events by pubkey so we only process the latest tools list for each server.

Could you please review the Svelte 5 / Applesauce reactivity patterns in src/lib/models/catalogSchemas.ts and catalogQueries.ts before I begin building the UI in Phase 2? I want to ensure the data flow aligns with the existing architecture.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
contextvm-site	Ready	Preview, Comment	May 26, 2026 9:17am

[ContextVM-org]

Looking great, notice that we are already fetching tool announcements so check out we are not refetching them for this case

[abhayguptas]

@ContextVM-org please review the new commits!

[ContextVM-org]

I reviewed the PR and I don’t think it is ready yet. The implementation still needs work, and in its current state it feels unfinished, with several leftovers from previous iterations still present in the codebase.

My main concern is that the CEP-15 integration is not wired in a truly reactive way. Right now the discovery data is not available as soon as the servers page loads. Also users effectively need to hit a server page first before the hashes and categories become visible back on /servers. That points to the fact that the catalog data is not being loaded as a first-class reactive source on the servers page itself. The page reads from CatalogSchemasModel, but it does not subscribe to the common-schema tools announcements loader on mount, so the discovery strip is not initialized from the correct data flow.

I also think the parsing is attached to the wrong source in a few important places. On the server page, the code is deriving CEP-15-related tags from the server announcement tags in src/routes/s/[pubkey]/+page.svelte, even though the CEP-15 i, k, and t tags belong to the tools announcement path, not the server initialize announcement. That means the common schema tags shown in ServerTagCloud.svelte and the schema badges in ToolCallForm.svelte are based on the wrong event source. In practice this makes the implementation look partially broken, because the UI can only behave correctly in accidental cases where users have already triggered other fetches.

I also don’t think we are constraining the parsing tightly enough. The helper in extractCommonSchemas() currently treats any i tag as a schema reference, but CEP-15 requires that these are interpreted in the common-schema namespace, which should be confirmed through the matching k tag. Without that check, the parser is too permissive and can misclassify tags that are not actually common tool schemas.

From a product and UX perspective, I think the route structure still carries too much historical baggage. The /catalog route in src/routes/catalog/+page.svelte is just a redirect, and src/routes/catalog/[hash]/+page.svelte is also just a redirect. Those are clear leftovers from a previous approach. Since the agreed direction is that /servers is the catalog, keeping these routes around only adds confusion and makes the implementation harder to reason about. The “Browse Common Schemas” button on /servers is part of the same issue for me: it is unnecessary because the page itself should already be the discovery surface.

I also think the server page integration is incomplete. The design intent was that /s/[pubkey] should only show the categories and schema hashes relevant to that specific server. The current implementation tries to do that visually, but because it is sourcing tags from the wrong event, it does not really deliver the intended behavior. The result is that the PR gives the impression of having the UI pieces in place without actually completing the underlying integration.

There are also some code hygiene issues that reinforce the impression that this PR still needs cleanup before it is mergeable. The schema badge link in ToolCallForm.svelte still points to /catalog/${schemaHash} instead of directly using the new /servers/i/[hash] route shape. The query helpers in src/lib/queries/catalogQueries.ts and src/lib/queries/catalogQueryKeys.ts look unused. The filtered pages in src/routes/servers/i/[hash]/+page.svelte and src/routes/servers/t/[cat]/+page.svelte rely on a hardcoded timeout to stop loading, which feels fragile and not aligned with the reactive model used elsewhere.

My overall take is that the PR has the beginnings of the right feature, but it is still not coherent end to end. I would describe it as partially implemented and in need of another cleanup pass before review can be considered complete. The core direction should be to make CEP-15 discovery load immediately from tools announcements, ensure only actual common-schema servers and tools are parsed, remove the dead catalog leftovers, and consolidate the UX so that /servers is the real catalog entry point and /servers/i/[hash] and /servers/t/[cat] are the only filter/detail routes.

[abhayguptas]

Hey @ContextVM-org ! Just pushed a new commit addressing all the feedback points from your review. I think the integration is much more solid end-to-end now:

• First-class Reactivity: The discovery strip on /servers now subscribes to the tools announcements loader on mount, so the catalog data loads instantly as a reactive source (no more needing to hit a server page first to trigger it).
• Correct Event Sourcing: Re-wired the server page (/s/[pubkey]) tag cloud. It now correctly pulls the categories and schema hashes strictly from the tools announcement event, rather than the server initialization event.
• Strict Parsing: Tightened up the parser in extractCommonSchemas(). It now strictly verifies the matching k tag (io.contextvm/common-schema) before extracting any i tags, perfectly aligning with how the SDK injects metadata.
• Removed Fragile Hacks & Leftovers: Replaced the 5-second setTimeout loading logic on the filtered pages with standard Svelte Query loading states. Also completely deleted the dead /catalog routes and unused queries to keep the codebase clean.

Let me know if this aligns better with what you were looking for! Happy to make any further tweaks if needed.