WIP! Feature tapestry discovery

[vcavallo]

local relay concept:

foreign relay concept:

relay discovery UI when selecting the "dog" concept:

---

foreign concept Element:

local concept Element:

---

Concept Discovery (This instance):

Concept Discovery foreign concept:

---

Concept Discovery: cross-instance schema sharing

Adds a "View through concept" picker on /kg/relay-discovery so the canonical relay view can be re-scoped to any installed ConceptHeader — including foreign concepts imported from another instance's TA. Picking a foreign concept narrows the table to events under that coordinate, surfaces a banner naming the schema fields this UI doesn't natively render (e.g. country, language from nostr-relay-v2), and adds an "Extras" column that pills out their values per row. Picking a non-relay concept (like dog) yields an empty state that explains the mismatch — making the schema-as-contract relationship visible.

New src/api/concept-discovery/ module wires the import path: suggested-authors (config-backed today, DCoSL-backed later), concepts-by-pubkey, concept-preview, import (lands foreign events in strfry, runs buildImportCypher, applies content-aware Neo4j labels, wires the 7 structural ConceptHeader edges via coreMemberOf, then triggers the existing Pass-3 derive pipeline). installed-concepts exposes the catalogue for the picker. New /kg/concept-discovery page provides the import UX with bootstrap suggestion cards + free-form pubkey search + schema preview modal.

relay-discovery/aggregated is now multi-TA aware — it resolves every installed concept coordinate matching a slug instead of hardcoding our TA, and accepts conceptCoord to scope the view. extras and appearsUnder are exposed per row so the UI can render schema divergence and which concept(s) each row is published under. Demo panels (Demo Setup + GrapeRank Pipeline) move below the table — operational, not primary.

mint-foreign-concept.js now mints the full 8-event firmware-shaped bundle plus 3 seed relay elements with the v2-only fields, so the foreign concept appears properly populated in the existing Concepts UI and has real demo data to render.

Concept Discovery caveats

The "suggested concept authors" comes from tapestry/config/suggested-concept-authors.json — the bootstrap config file we set up. Concretely:

1. Seeded by the demo script. When you run node mint-foreign-concept.js --seed-config, the script appends Magic Mirror's pubkey + name + description to that JSON file (alongside the self-referencing entry that ships by default).

2. Served by the API. GET /api/concept-discovery/suggested-authors reads the file at request time, filters out malformed entries, and returns { success: true, authors: [...] }.

3. Rendered by the UI. ConceptDiscovery.jsx fetches that endpoint on mount and renders one card per author in the "Suggested concept authors" section. Click → it pre-fills the search input and triggers a concepts-by-pubkey fetch.

The TODO item below changes only step 2: the same endpoint stops reading the file and instead resolves a DCoSL "concept-author" DList from Neo4j. UI and config-file consumers are unchanged because the response shape stays the same.

TODO (at least)

• Migrate suggested-concept-authors to a DCoSL concept-author DList; make the canonical DList coordinate configurable in brainstorm.conf

....also....

• Allow per-import override of which DList to consult, so users can subscribe to multiple curators (and rank their suggestions by GR)
• Surface concept-author trust scores on suggestion cards (use useTrustWeights against the configured POV)
• Concept "uninstall" / "unsubscribe" flow — today removing an imported concept requires direct Cypher
• Concept "refresh" / re-import — re-pull when the foreign TA updates schema or supports
• Exempt any pubkey that has authored a :ConceptHeader from reconciliation pruning, so imported foreign TAs aren't repeatedly dropped + their concepts orphaned
• Verify event signatures on import (currently uses strfry import --no-verify)
• Persist provenance ("imported from relay X on date Y") on each ConceptHeader node and surface it in the Concepts UI
• Diff-view: when re-importing or comparing two concepts, highlight schema changes (added/removed/renamed fields)
• Detect schema-shape compatibility for the relay-discovery picker so non-relay concepts can be visually grouped or down-ranked rather than mixed in
• Allow the concept-lens picker to scope to multiple coordinates simultaneously (multi-select for "show me v1 + v2 together")
• Expose appearsUnder on collapsed rows (icon or tooltip) so users can see at a glance which concepts a relay is endorsed under without expanding
• Concept-author profile cards: render kind-0 metadata (name, picture, NIP-05) on suggestion cards so foreign TAs are visually identifiable
• Per-publish concept picker on PublishRelayForm (and RelayTagPanel) once a real "publish to a foreign concept" use case emerges
• Bulk-import: "import all concepts from this TA" action when a user trusts an entire instance's ontology
• Conflict resolution UI when an imported concept's schema differs from another concept with the same slug — currently coexist silently under different coordinates
• Auto-discover concept authors from kind-3 follows + their published 39998s (passive discovery via your existing WoT)
• Versioning + supersedes: a TA publishing nostr-relay-v2 could declare it supersedes nostr-relay-v1 via a tag, and the UI could suggest migration
• Element migration: when adopting a new schema version, offer to convert your existing kind-39999 publishes from old coord to new coord
• Concept "explorer" page that visualizes the multi-TA graph: which slugs exist across which authors, who imported what, schema-overlap heatmap
• Negentropy-style sync of concept events from external relays so concept import works without the foreign TA having to be online
• Schema validation on user publishes: when publishing under a coordinate, validate the payload against that concept's JSONSchema before signing
• Test data for concepts other than relays — e.g. a foreign tag concept with different vocabulary — to demonstrate plurality across the whole feature surface
• Documentation page describing the conceptual model (decentralized concepts, coordinates, schema-as-contract) for users encountering this feature for the first time