1. Forum
  2. FidoNET
  3. SYNC PROGRAMMING

  • exec/chat_llm.js

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Friday, October 02, 2026 15:10:06
    https://gitlab.synchro.net/main/sbbs/-/commit/b503bdb9cbe54284353a706b
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: let the guru tell people which model it runs on

    Asked "what LLM are you using?" on IRC, the guru deflected ("whatever
    LLM is configured in chat_llm.ini") because nothing in its prompt named
    the model, and the question pulled the generic howto:llm-guru wiki text
    into retrieval, which it then parroted.

    Add an @llm_model@ persona macro, expanded from the configured model=,
    so a persona can state the real model and it tracks config changes.
    Classify "which model/LLM/AI are you" style questions as conversational
    so they skip retrieval like the other about-the-bot questions.

    Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
    --- SBBSecho 3.38-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Tuesday, September 22, 2026 20:05:24
    https://gitlab.synchro.net/main/sbbs/-/commit/397b470253e6b75bb98d38f9
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: stop the fabrication filter deleting real GitLab issue URLs

    The URL policing added in e77a8de727 (maximum-44-into, 2026-08-10) keys
    every URL in a reply against the set the tools and retrieval actually
    returned, and deletes the rest. It matches them by exact text.

    GitLab serves one issue at two paths: /-/issues/<iid>, which every
    human-facing link uses and which a model writes unprompted, and the newer /-/work_items/<iid>, which is what the git_issues tool returns. So the
    filter saw a URL no tool had produced and removed a link that was real,
    leaving the clause that introduced it pointing nowhere -- "check for the
    full list", "see the wiki: See for the full details".

    Normalize the two spellings to one key so either matches.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Friday, October 16, 2026 21:19:03
    https://gitlab.synchro.net/main/sbbs/-/commit/2a48d15a6f3e497f8af7b03a
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: reject a provider/endpoint mismatch at config load

    Ollama serves both its native /api/chat and an OpenAI-compatible /v1/chat/completions on the same port, so pairing the wrong provider with
    an endpoint doesn't fail at the HTTP level. provider=openai against
    /api/chat failed only after the full generation, with "no choices in
    response: <raw JSON>"; a sysop (Keyop) hit exactly that in #synchronet
    while following the advice to switch endpoints.

    load_config() now compares the endpoint's path with the provider
    (/api/chat = ollama, .../chat/completions = openai) for both endpoint and endpoint_fallback, and throws an error naming the fix, before any
    request. For URLs whose path doesn't say (e.g. behind a proxy), the
    response parsers also recognize the other API's reply shape and say so
    instead of dumping the raw JSON.

    Tested against Ollama: both mismatches fail at once (0.0s) with the new messages; both correct pairings still reply; the live config still
    loads; chat_openai() aimed at /api/chat reports the native shape.

    Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
    --- SBBSecho 3.38-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Thursday, October 29, 2026 22:22:33
    https://gitlab.synchro.net/main/sbbs/-/commit/745720a44f06eafb8f934ab2
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: ignore the #anchor when matching a wiki URL to the query

    append_wiki_url_if_missing() only appends a wiki link when a query
    word also appears in the URL. It tokenized the whole URL, #section
    anchor included, and anchors are full of generic how-to words ("step", "adding", "your"). So an off-topic "step on toes" matched howto:dove-net#step_3_adding_your_system and the reply got a DOVE-Net
    link. Match against the page name only; the appended URL still keeps
    its anchor.

    Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
    --- SBBSecho 3.38-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)