[tnunamak]

No page on pdpp.dev tells someone whether an app they use has a PDPP connector, or whether the company behind it has signed the Principles or registered an implementation.

This PR adds a page at /apps, "Is your app on PDPP?", that answers this from lists PDPP already publishes. It stores nothing about visitors: the search runs in the browser over rows built on the server. Three sources feed it:

• The connector catalogue, an OCI artifact at ghcr.io/pdp-connect/connector-catalog:latest that is built from PDP-Connect/data-connectors and readable without a login. It says which connectors exist and what data each one brings.
• The Supporters register (public/principles/supporters.json), for organisations that have signed the Principles.
• The conformance register (public/register/index.json), for Registered and Verified implementations. It is empty until those statuses open.

Each entry is an open-source connector, shown with what it brings and a link to its source. A connector existing says nothing about the company, and many connectors are community-built, so the page names a company as a signer or a registrant only when one of the two registers names it. The intro says this in plain words, and a test asserts that no entry's first line says a company is on, supports or takes part in PDPP. Individuals in the Supporters register never appear.

The catalogue is loaded live, so the page follows data-connectors without a redeploy. apps/site/src/lib/connector-catalog.mjs fetches the artifact, checks its bytes against the digest and size the registry reports, and then reads each connector's manifest from GitHub (raw.githubusercontent.com, at the data-connectors commit the catalogue was built from) for its data labels. Each request has a 15-second timeout. The whole load is cached for an hour with Next's unstable_cache. The cache wraps the whole load rather than each fetch because the registry requests carry a fresh anonymous token in their Authorization header, so a per-fetch cache keyed on the request would rarely hit. If the load fails, or returns nothing or something malformed, the page uses src/data/connector-catalog.json, a copy in the repo that scripts/sync-connector-catalog.mjs regenerates. The copy is at data-connectors commit 23aee3a with 60 connectors. The module checks digests but does not verify the catalogue's cosign signature, and its header comment says so.

The page sits behind NEXT_PUBLIC_PDPP_APP_DIRECTORY, off unless set to true like the other site flags. With the flag off, /apps is a 404: the page calls notFound() before it reads any source, so it fetches nothing at build time or later. With it on, the page is linked from three places, following how Home Assistant, Meltano and Airbyte surface their integration directories: a "Participate" menu in the top navigation with "How to get involved" and "Is your app on PDPP?", a line under the register on /participate, and the footer.

The menu needed a fix in masthead.tsx. The dropdown wrapper had the class md:group, which Tailwind does not treat as a group marker, so the group-hover and group-focus-within rules that open the panel never matched. It now uses group, and the panel gets md:w-max so its entries do not wrap. A menu with one child still renders as a plain link, so with the flag off the masthead looks as it does today.

This PR and #468 each add a flag function to the end of apps/site/src/lib/site-config.ts, so whichever merges second will need that conflict resolved, keeping both functions.

Verified: the site's verify script (types, tests, lint, production build) passes on this branch alone and merged with #467 and #468. Tests cover each relationship a row can state, whole-name matching of companies, search, the 404 with the flag off, the menu entry following the flag, the live load winning over the copy, and the fallback when the live load is rejected, empty or malformed. Two tests run the full catalogue-to-manifests path against a fake registry, including a digest mismatch, which is rejected. A deployed preview with the flag on showed catalogue commit 23aee3a while the repo copy was still at an older commit, so the live load is what it rendered; its build log has no fallback warning. On that preview, the menu opened on hover and with the keyboard, and the mobile menu listed the entries.

Not verified:

• How the page behaves when the registry or GitHub is slow but does not fail. The 15-second timeout applies to each request, not the whole load, and a timeout sends the page to the fallback. The catalogue takes three requests in sequence and then each manifest up to two, so a load where every request is slow but within its limit could take over a minute. I have not measured this.
• Screen readers on the new menu.

Assisted-by: AI

[vercel]

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

Project	Deployment	Actions	Updated
pdpp	Ready	Preview	Nov 6, 2026 3:38pm UTC