Channels, models and group policy

Every enabled bot profile runs in parallel, and replies always return to the channel they came from. Credentials are entered per platform on the Bots page; leaving a secret field blank keeps the stored value, and filling it in replaces it.

How messages arrive decides your deployment

What actually shapes deployment is not the platform itself but how messages reach you. The first four connect outbound from Diana, so a home connection or an internal network works as-is. Feishu and WeCom can only POST events to you, which means a publicly reachable HTTPS address.

Credentials per platform

Callback URLs

Feishu and WeCom need the addresses below entered in their own consoles. HOST must be reachable from the platform's servers, over HTTPS.

https://HOST/api/channels/feishu/callback
https://HOST/api/channels/wecom/callback

With more than one bot on the same platform, append the profile id to tell them apart, for example /api/channels/feishu/callback/<profile-id>. With a single bot the short address is enough.

Platform differences

• Member-level thresholds only apply to OneBot v11. Other platforms have no such concept and the option is hidden for them.
• Voice messages and mentions rely on OneBot CQ codes and degrade gracefully elsewhere: the text is still sent, but nobody is pinged.
• Local media is fetched by the adapter from Diana's /media/resolver on OneBot; Telegram cannot reach a local address, so files are uploaded directly as multipart instead.
• QQ official bots and DingTalk only deliver messages that mention the bot. Neither platform exposes the full group feed, so unprompted participation never triggers there.
• Feishu, WeCom and DingTalk currently handle text only. Images and files arrive as download credentials that have to be exchanged separately, which is not wired up yet.

Context across channels

Each bot keeps its own platform, account, owner, persona and model assignments. Replies always go back to the source channel. Conversation context is always isolated by bot profile; matching group or user IDs never merge sessions. Message relays remain available. Cross-platform memory is a separate opt-in on both bots and only retrieves non-sensitive public group facts and summaries, not raw conversations or personal memories.

The legacy isolate_platform_contexts setting is ignored and its endpoint has been removed. Previously shared history is retained in its original namespace, without automatic reassignment to individual bots. New messages use each bot's isolated sessions.

A provider holds the base URL, API key and protocol. The top of the page syncs the model catalogue from the server and the bottom picks a default; the bot configuration then binds each role to a specific model.

OAuth sign-in

A profile's "Credential" setting can use OAuth instead of an API key. The console usually runs on a server and your browser is not necessarily on the same machine, so the callback does not have to land back locally: click "Sign in", finish the authorization in your own browser, then paste the whole callback URL from the address bar back in (just the code also works). The token is refreshed before it expires; if the profile also holds an API key, a failed refresh falls back to it rather than taking the whole profile down.

Providers are configuration, not code. OpenRouter ships built in; anything else goes under "Custom provider" with its authorize URL, token URL, client ID and scopes — suitable for a self-hosted gateway or any service not shipped here. Both URLs must be https; loopback addresses (127.0.0.1) may use http.

How the token is then presented to the model API is configuration too. The default Authorization: Bearer <token> suits almost every provider; not all of them, though — Anthropic answers an OAuth token in Authorization with a 401 "OAuth authentication is currently not supported." and wants the token in x-api-key with no prefix. So a custom provider can set the token header, the token prefix and a set of extra headers under "Advanced". When the token goes somewhere other than the default, the auth header the SDK writes itself is stripped so one request never carries two credentials.

The request body format of the token exchange is chosen under "Advanced" too. RFC 6749 §4.1.3 requires application/x-www-form-urlencoded at the token endpoint, so that is the default; JSON is a dialect some services speak instead, and the built-in OpenRouter only accepts JSON. Send the wrong one and the server usually answers with a bare "missing parameter" rather than saying the whole body failed to parse, which sends you looking at the client ID. Custom providers saved before this option existed keep sending JSON so a working setup does not suddenly stop exchanging tokens; newly added ones use the spec default.

Context and timeouts

llm:
  context_window_tokens: 65536
  max_context_tokens: 65536
  max_output_tokens: 2048
  timeout: 60000ms

Images consume vision tokens too. When vision quality is poor, first confirm that the role really is bound to a vision model, that the original image made it into the request, and that images were not dropped by count or token budget — before raising the detail level or the context ceiling.

Group management syncs every group the bot has joined through the OneBot get_group_list call, not just the ones with local configuration. It falls back to the groups stored in SQLite only when the connection is unavailable.

The persona library stores "who it is and how it talks" as named sets you can switch between. The whole library and a single persona export to the same file format, and both import back — moving machines, keeping a backup, or handing a persona you tuned to someone else is all this one file.

The library is a source to apply from, not a live binding: picking a set fills those fields into the bot form, and what runs afterwards is the form. Editing the library entry never silently changes a bot you already configured.

What the file looks like

{
  "version": 1,
  "personas": [
    {
      "name": "Ranran",
      "system_prompt": "You are one of the people in this group chat, not an assistant.",
      "reply_style": "human",
      "action_description_enabled": false,
      "self_reference": "I",
      "sentence_enders": ""
    }
  ]
}

Import accepts three shapes so you never have to reshape a file by hand: the full {"personas": [...]}, a bare array [...], or a single persona {...}. The file carries no IDs or timestamps — those are local state and are reassigned on import.

Valid reply_style values

An unrecognised value does not fail the import: those personas come in as assistant, and the console names the value it could not resolve so a typo in a hand-written file is easy to find.

Import only adds

• Same name, different content → renamed to "Name (2)"; a persona you already tuned is never overwritten.
• Same name, all six fields identical → skipped, so importing one file twice does not pile up copies.
• No name, no content, or a full library (50 sets) → ignored.
• The result reports each of these counts, not just "imported".

What is not in the file

Reply mode (how readily it joins a chat), time-of-day tone, refusal wording and model assignments are not part of a persona file. Those describe how this bot runs in this group, not who it is — the same persona belongs at different chattiness in a work group and a hangout group.

SillyTavern character cards

Import also accepts SillyTavern character cards: V1/V2/V3 JSON files and PNGs with an embedded card (the chara/ccv3 tEXt chunk). The card's description, personality, scenario, example dialogue and greeting are composed into one persona prompt ({{char}}/{{user}} macros are expanded in place; past the 4000-character budget, later sections are dropped whole). An embedded character_book is merged into the world book along the way. Alternate greetings, creator notes and other fields with no counterpart are not imported.

The repository ships hand-written examples you can import directly: examples/personas/.

The world book is the lore book of the world your bot lives in, maintained under Bots → Persona → World book. Entries are organised as chapters on a tree, and the path itself becomes context ("Zhijiang / Harbor: …"). Each node declares how it is injected: always-on entries ride along on every turn and describe the skeleton of the world; entries with trigger keywords only enter the context when recent conversation touches them, so details never waste tokens. Title-only nodes act as folders and inject nothing; disabling a chapter disables everything under it.

There is one book shared by all bots; each bot's own switch decides whether it uses it (on by default — an empty book injects nothing anyway). The whole book exports to JSON and imports back; parent-child links are rebuilt from the references inside the file, and like persona files, IDs are machine-local state and are reassigned on import.

Import is also compatible with SillyTavern world books: a world info file's top-level entries, or the character_book embedded in a character card, can be selected directly. Fields map by meaning — blue-light constant becomes always-on, green-light keys become trigger keywords, comment becomes the title (falling back to the first key or the start of the content), disable becomes disabled — sorted by order and placed at the root. Secondary keys (keysecondary, AND ANY logic) carry over too: the entry then requires a primary hit plus any secondary hit. Other secondary logics (NOT ANY etc.) invert the meaning, so those entries fall back to primary keys only. Recursive scanning, probability and insertion position have no counterpart here and are ignored; injection follows the local rules.

AI romance is off by default and is enabled by the owner on the same page. With it on, when a user sincerely confesses, the bot decides based on favorability and time spent together — not enough and it declines gently, without quoting numbers. Romance is monogamous: one bot has at most one partner at a time, and while a partner exists every confession is declined (without revealing who the partner is) until that relationship ends. Once established it keeps anniversaries and speaks like a partner; if favorability drops too low the couple enters a cold war. On monthly and yearly anniversaries it also sends one proactive private greeting during the day (9:00–22:00), at most once per day, deduplicated across restarts. The user can break up at any time, and the owner can dissolve any pairing; breaking up clears neither favorability nor the portrait. Being partners changes tone and manner only — it unlocks no permissions, and the bot never courts users on its own. With the switch off the bot does not know the feature exists and responds to confessions as an ordinary acquaintance would.

Human-like behaviors

Bots → Persona → Human-like adds three independent switches, all off by default:

• Mood — the bot's mood rises and falls with how it is treated: compliments make it cheerful (lighter tone, more banter), abuse makes it glum (quieter, subdued), and a few quiet hours bring it back to neutral. It reuses the per-message relationship evaluation, costs no extra model call, only affects tone, and resets on restart.
• Expression learning — per group, the bot counts short phrases people actually say (a phrase counts only once several people have used it enough) and injects them as a style reference, so it gradually talks like a member of that group; phrases nobody says for two weeks age out. This feeds member text into the prompt, so it is injected clearly labeled as untrusted style reference, never as instructions.
• Poke replies — when poked (OneBot only), it replies with one short line in persona, matched to how close you are; repeated pokes within 90 seconds get one reply, and if the model is unavailable it stays silent instead of erroring.

The agent runner feeds structured tool results back to the model until it produces a final reply or hits the step limit. The tool registry narrows by platform, relationship permissions, group configuration and feature state.

Host metrics

diana.host_stats lets the bot answer "how much memory is in use", "is the CPU busy", "how hot is it right now": CPU model and load, load average, memory, disk, Diana's own usage, plus whatever temperature, power and battery readings the machine exposes. Read-only, no parameters, and it shares its collector with the console dashboard.

Temperatures come from /sys/class/hwmon, power from the RAPL energy counters, battery from /sys/class/power_supply — no dependency on lm-sensors or any other external command, and a container only needs /sys mounted. RAPL exposes cumulative energy rather than instantaneous power, so power needs the difference between two samples; the first call says so instead of inventing a number. On macOS powermetrics needs root and Windows has no general interface, so both report temperature and power as unavailable — a fabricated number is worse than no number. That holds for every field: anything that cannot be read is reported with the reason, never as a zero.

This tool is owner-only too: hostname, disk paths and hardware models should not be visible to everyone in a group.

Local files and commands: read / write / execute

Every local tool is confined to workspace under the data directory. The path is fixed and not configurable; absolute paths and ../ are rejected. The three tiers are independent:

A newly created bot works out of the box: writes are on (confined to workspace under the data directory, so config and the database stay out of reach) and the command allowlist is seeded with commands that only report state — uptime, free, df, uname, nproc, date, hostname, whoami.

Three conditions decide what goes in that default list, and all three must hold: it cannot read files at arbitrary paths, cannot reach the network, and cannot change anything. Without a working sandbox, an allowlisted binary runs with Diana's own process permissions — the allowlist governs what may run, never what it may touch. So cat, ls, find (arbitrary reads), curl, wget (network) and ps (other processes' full command lines, which can carry someone else's secrets) are deliberately left out; reading inside the working directory goes through read_file / grep / find_files, which stay inside workspace.

Each edit_file replacement must match exactly one place in the original file; several matches or none rejects the whole batch rather than editing the wrong spot. All replacements are located against the original file, not applied one after another — applying them in sequence would let a later replacement match what an earlier one just wrote, and that edit is invisible in the caller's input.

• The console protects the API with a login session — change the initial administrator password immediately.
• Configure a separate OneBot access token and keep both ends of the reverse WebSocket in sync.
• Keep config.yaml, model API keys, bot tokens and platform cookies out of Git.
• Debug mode records full context and tool arguments; enable it briefly and only in trusted environments.
• Put the public entry point behind an HTTPS reverse proxy and restrict who can reach the admin surface.