Background
PR adding the brave-search extension ships an optional, paid Brave Search API wrapper with its own simple JSON shape (/v1/search?q=… → {query, results: [{title, url, snippet}]}).
That PR explicitly does not try to mimic searxng's API surface, because perplexica (and any other consumer that points SEARXNG_API_URL at it) speaks searxng's specific JSON format with engines, paging, and category metadata that a thin wrapper would only partially translate.
Proposal
Investigate whether it's worth adding an opt-in searxng-compatibility mode to the brave-search proxy — a second route (e.g. /search?format=json&q=…) that returns a response shaped like searxng's, so users could point perplexica at brave-search by changing one env var.
Why this isn't part of the initial PR
- Surface area: searxng's JSON includes fields perplexica might or might not depend on (
engines, category, score, infoboxes). Faithfully mapping Brave's response shape to all of them — or stubbing the fields perplexica ignores — needs investigation, not assumption.
- Risk of subtle compatibility bugs: a partial mimic that returns 200 but ranks/paginates differently than searxng would silently degrade perplexica's research quality. That's a worse user experience than no compatibility at all.
- Maintainer call: this is enough new surface that I'd rather get a thumbs-up before building it.
Open questions for maintainers
- Is searxng-compatibility for perplexica a use case worth the maintenance cost?
- Are there other existing consumers (open-webui's web search? agents?) that speak searxng's API and could benefit?
- Preferred shape: a second route on the same brave-search service, or a separate
brave-searxng-shim extension that depends on brave-search?
If yes to any of the above, I'll send a follow-up PR with concrete shape and tests against perplexica.
🤖 Filed via Claude Code while preparing the brave-search extension PR
Background
PR adding the brave-search extension ships an optional, paid Brave Search API wrapper with its own simple JSON shape (
/v1/search?q=…→{query, results: [{title, url, snippet}]}).That PR explicitly does not try to mimic searxng's API surface, because perplexica (and any other consumer that points
SEARXNG_API_URLat it) speaks searxng's specific JSON format with engines, paging, and category metadata that a thin wrapper would only partially translate.Proposal
Investigate whether it's worth adding an opt-in searxng-compatibility mode to the brave-search proxy — a second route (e.g.
/search?format=json&q=…) that returns a response shaped like searxng's, so users could point perplexica at brave-search by changing one env var.Why this isn't part of the initial PR
engines,category,score,infoboxes). Faithfully mapping Brave's response shape to all of them — or stubbing the fields perplexica ignores — needs investigation, not assumption.Open questions for maintainers
brave-searxng-shimextension that depends on brave-search?If yes to any of the above, I'll send a follow-up PR with concrete shape and tests against perplexica.
🤖 Filed via Claude Code while preparing the brave-search extension PR