The introduction described the mechanism before the purpose. It now
states what the plugin does, that it is meant for a local LLM server
speaking the OpenAI chat completions API, and -- the part that was
missing -- that the summary exists to condense the results the query
actually returned rather than to recite training data.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Furo renders its own page-local table of contents and reports an error
when a page adds one with contents::. No other page in the tree uses
that directive; these two now follow suit.
The plugin is named "AI Summary" where the name of the plugin is meant,
and "AI summary" where the generated text itself is meant. That also
fixes the entry in the plugin navigation, which takes its label from the
page title.
Two references to the configuration page rendered as its title, the bare
YAML key "ai_summary:", which reads as a typo in a sentence. They now
carry explicit link text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The documentation was written from the perspective of someone who had
just implemented the plugin: it opened with SSRF caveats and settings
keys, and explained decisions rather than usage.
The admin page now starts from what the feature is, followed by a
four-step quickstart (install Ollama, pull a model, configure, restart)
and a troubleshooting section for the failures that actually occur. The
quickstart repeats the default plugins because a plugins: block replaces
that list instead of merging into it -- following the short version of
the instructions would otherwise switch every other plugin off.
The developer page gains a rendered data flow diagram. The two-request
design -- placeholder first, streamed answer second -- is the part of
this plugin that is hard to convey in prose, and the SSE to NDJSON
change is easier to see than to read about.
The module docstring now describes the module and links to both pages,
instead of restating administration guidance.
Add Jason Witty to AUTHORS.rst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Grounding is on by default, and it sends the top search results along
with the query. Which data leaves the instance depends on where the LLM
server runs -- per the privacy-by-design directive the reader has to be
able to see that from the documentation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three changes to the ai_summary plugin:
- The *AI Summary* preferences tab is only rendered when the plugin is
activated in settings.yml. An instance that does not offer AI
summaries no longer shows an AI tab at all. The gate is the
administrator setting, not the user opt-out, because the per user
on/off switch lives inside that tab -- hiding it on opt-out would
leave no way to opt back in.
- Users can configure an API key for their own LLM server
(ai_summary_api_key). The administrator key is still only sent to
base_url and the user key only to a server the user configured, so
neither key can be captured through the other. The setting is marked
secret: credentials are excluded from the preferences URL, which users
copy around to transfer or share their preferences.
- Grounding summaries on the search results is now the default; the
extra cost of the longer prompt is moderate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Servers that require authentication (e.g. vLLM or llama.cpp started with
--api-key, or an LLM server behind an authenticating reverse proxy) can
now be configured with an ai_summary.api_key, sent as "Authorization:
Bearer".
The key is administrator configuration only: there is no preference for
it, and it is only sent to the configured base_url. Users can point the
ai_summary_server preference at a server of their own, and such a server
must not be handed the instance API key -- otherwise every user of the
instance could capture it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Talk to the LLM server via GET /v1/models and POST /v1/chat/completions
(SSE) instead of Ollama's native API. Any OpenAI compatible server now
works (Ollama, vLLM, llama.cpp, LM Studio, Hugging Face TGI, ...);
Ollama serves this API natively, existing setups keep working unchanged.
The Ollama specific keep_alive option is dropped, the ai_summary.grounding
setting is added as instance wide default of the grounding preference.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add an optional, disabled-by-default plugin that shows an AI generated
summary at the top of the result page, generated by a (local) Ollama
server:
- async: the result page is never delayed; a client plugin streams the
answer (NDJSON over a new /ai_summary endpoint) into a placeholder
answer with a typing indicator, collapsed behind a More button, with
an inline follow-up chat
- trigger: first page of general searches only, skipped when an infobox
or instant answer already answers the query
- grounding (per-user preference): send the top result snippets as
context, the model answers from them instead of its own knowledge
- configuration: new AI Summary preferences tab (server URL, model,
grounding) with instance defaults in a new ai_summary: settings
section; all three preferences can be locked for public instances
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
TBH: Some of the parameters such as engines or plugins still theoretically exist
in SearXNG, but we will no longer support them. They are usually accessed via
cookies and should not pollute the API / it is these supposed features that
hinder SearXNG in further development.
Closes: https://github.com/searxng/searxng/issues/6003
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Drop outdated engine attributes: supported_languages, language_aliases
Complete, normalize and document the type definitions for the engine-module and
engine-class.
For the ``engine.about`` section of the configuration, a type check is performed
based on structure ``searx.enginelib.EngineAbout``.
The property ``engine.about.language`` no longer exists; existing values have
been migrated to ``engine.language``.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
The engine is using very aggressive Cloudflare blocking for
a while now, no matter if using a normal browser like Firefox
or not.
Closes: https://github.com/searxng/searxng/issues/5976
[mod] normalize variable name for the max number of results per request
In the past, we have used different names for the variable that specifies the
maximum number of hits in the outgoing request.
- ``page_size``
- ``number_of_results``
- ``nb_per_page``
Since *page_size* is the most accurate term and is also used in the XPath
engines, all other engines are adjusted accordingly within this
patch .. documentation adjusted accordingly.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
- add button for editing docs source on GitHub
- add links to GitHub repository and public instances (searx.space)
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
The readability can be improve with the following two changes:
Slightly increase the content width to make the engine list more readable::
.content {
width: 52em; /* instead of 46em */
}
To avoid word wrap in bang::
p code.literal {
text-wrap: nowrap;
}
Sugested-by: https://github.com/searxng/searxng/pull/3408#issuecomment-2094082144
* [mod] client/simple: client plugins
Defines a new interface for client side *"plugins"* that coexist with server
side plugin system. Each plugin (e.g., `InfiniteScroll`) extends the base
`ts Plugin`. Client side plugins are independent and lazy‑loaded via `router.ts`
when their `load()` conditions are met. On each navigation request, all
applicable plugins are instanced.
Since these are client side plugins, we can only invoke them once DOM is fully
loaded. E.g. `Calculator` will not render a new `answer` block until fully
loaded and executed.
For some plugins, we might want to handle its availability in `settings.yml`
and toggle in UI, like we do for server side plugins. In that case, we extend
`py Plugin` instancing only the information and then checking client side if
[`settings.plugins`](https://github.com/inetol/searxng/blob/1ad832b1dc33f3f388da361ff2459b05dc86a164/client/simple/src/js/toolkit.ts#L134)
array has the plugin id.
* [mod] client/simple: rebuild static
SourceHut uses a foss bot protection tool called `go-away` (which I can
recommend BTW). It blocks common crawler user agents, such as the standard
Firefox user agent. Hence, we're now using our custom SearXNG user agent to
clarify we're not a crawler.
Closes: https://github.com/searxng/searxng/issues/5270
Co-authored-by: Markus Heiser <markus.heiser@darmarit.de>
Since #5280 has been merged, msgspec, like yaml, is a fixed part of the SearXNG
*settings framework* and therefore, like yaml, must be installed in the virtual
environment before installing SearXNG (``searx``).
The actual reason is that in SearXNG we store settings in the configuration that
are required for the installation of the ``searx`` package. This means that
these settings (from settings.yml) are read in during the installation, and all the
necessary tools for this (pyyaml, msgspec, setuptools, etc.) must be installed
beforehand (chicken or the egg dilemma).
Related:
- https://github.com/searxng/searxng/pull/5346
- https://github.com/searxng/searxng/pull/5280
- https://github.com/searxng/searxng/pull/5254
Closes: https://github.com/searxng/searxng/issues/5352
This PR adds a new result type: File
Python class: searx/result_types/file.py
Jinja template: searx/templates/simple/result_templates/file.html
CSS (less) client/simple/src/less/result_types/file.less
Class 'File' (singular) replaces template 'files.html' (plural). The renaming
was carried out because there is only one file (singular) in a result. Not to be
confused with the category 'files' where in multiple results can exist.
As mentioned in issue [1], the class '.category-files' was removed from the CSS
and the stylesheet was adopted in result_types/file.less (there based on the
templates and no longer based on the category).
[1] https://github.com/searxng/searxng/issues/5198
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Adds a new engine `searx/engines/azure.py` to search cloud resources on Azure.
A lot of enterprise users have to deal with Azure Public Cloud. This helps them
easily search for cloud resources without logging in to the Portal first
How to test this PR locally?
You should create an App Registration on Azure Entra Id with Reader access on
the resources you want to search for. You should create a Secret for the App
Registration. After that, you should set up appropriate values in the
`settings.yml` file [1]::
- name: azure
engine: azure
...
azure_tenant_id: "your_tenant_id"
azure_client_id: "your_client_id"
azure_client_secret: "your_client_secret"
azure_token_expiration_seconds: 5000
[1] https://github.com/searxng/searxng/pull/5235#issuecomment-3397664928
Co-authored-by: Bnyro <bnyro@tutanota.com>
Co-authored-by: Markus Heiser <markus.heiser@darmarit.de>
The settings are currently an untyped key/value structure, whose types are
dynamically built at runtime. The construction process of this structure
is *hand-crafted*.
In the long term, we want a static typing of this structure, based on a standard
tool. The ``msgspec.Struct`` structures are suitable as a standard tool.
This patch makes a first step towards static typing and implements the "brand"
section using ``msgspec.Struct`` structures.
BTW: searx/settings_defaults.py - ``git_url`` and ``git_branch`` had been
removed in aee613d256, this is a leftover.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
jasonwitty