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 push only messages that mention the bot by default. Once the group owner sets the bot's group message scope to all messages under the group settings, unprompted participation works there too. DingTalk pushes only messages that mention the bot, so those features never trigger 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.

Private chats are disabled by default, including ordinary messages and private notices from the owner. Enable all users, owner only or a whitelist under Bot → Behavior → Admission and limits when needed. Disabled messages are silently ignored without queueing, preprocessing or model calls; group chats and console login pairing are unaffected. Explicitly saved admission modes remain effective; missing or invalid modes disable private chats.

Each bot's persona is a single Markdown document: who she is, what she cares about, how she talks, what she looks like. It is placed verbatim at the very front of the system prompt, with no wrapper. Edit it under Bots → Persona; a group can replace it wholesale in group management, or leave it empty to follow the bot.

Diana's way of writing it is to give reasons, not rules: rules always miss cases nobody foresaw, while a character who understands why can work out situations the document never mentions. Only the few things that are costly to get wrong become hard lines. Write about her in the owner's voice ("we"), say that her identity holds under pressure, and describe her appearance. Output format, message splitting, tools, time and which group she is in need not be written — the runtime adds those. See docs/soul-md.md in the repository for the full guide.

Persona library

The library is a source to apply from, not a live binding: picking one fills its text into the editor, and it takes effect when you save the bot. Editing the library entry later never silently changes a bot you already configured.

• Six built-ins (Diana, human-like, catgirl, assistant, girlfriend, boyfriend) ship with the program and are read-only; apply one and save your own copy to change it.
• Every entry exports as name.md; importing a .md takes the name from the first-line heading, or from the file name.
• Import only adds: same name with different content becomes "Name (2)", same name with identical text is skipped; the library holds up to 50 entries.

Upgrading

Persona files are .md only; older JSON / YAML persona files no longer import. Nothing already stored is lost: on upgrade, the soul layer, self-reference, sentence-ending particles and action-description switch in bot configurations and in the library are rendered into the same text the runtime used to inject and folded into SOUL.md, so the model reads the same instructions — they are just visible and editable now. Prompt overrides and criteria that older library personas carried no longer travel with a persona and are dropped; each bot's own prompt overrides and criteria are kept as they are.

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 document ({{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.

Reply mode (how readily it joins a chat), refusal wording and model assignments are not part of the persona: they describe how this bot runs in a group, not who she is.

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.

Human-like behaviors

Bots → Behavior → 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.
• Style learning — about once a day per group, a background model reads recent member messages (senders replaced by letters) and writes a note of up to 300 characters on how that group talks: catchphrases and in-jokes with their meaning, message length, punctuation and emoji habits, how people tease each other. The note is added to replies. It shows up when editing the group on the Groups page, where you can rewrite it (manual notes are never overwritten automatically) or relearn it (after a confirmation, since it replaces the current note). You can also turn the style off for just that group: it is neither learned nor added to replies, and the note is kept. Groups the bot is off in, or doesn't reply in, are skipped. When a member asks the bot to stop saying a particular word in the group (for example a catchphrase), long-term memory records it as a group rule: it isn't tied to the person who asked, it is added after the style note, and the bot follows it no matter who it is replying to, even if the note lists that word. This works whether or not style learning is on. A group rule lapses after 30 days by default (or sooner if the member named a shorter period, like "not today"); asking again extends it, and anyone in the group can lift it by saying the word is fine again. Requests to add a catchphrase or switch tone still apply only to the person who asked.
• 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

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). run_command has no program allowlist, but it is registered only when the command sandbox actually works: commands stay in the workspace, cannot read credential files, are always offline, and are not reviewed before running. Without a usable sandbox, or with the sandbox set to off, the tool is not registered and the owner's commands go through host_access, which a model reviews before every execution; commands that need the network go there too. The rule is one sentence: anything that can change the machine or send data out gets reviewed. Member sessions and safe mode never register the tool.

"Allow plugin scripts and package installs to use the network" only affects install_package and the scripts and MCP servers a plugin declares. Their entry points are fixed at install time; they follow the sandbox setting and, without a sandbox, run with Diana's own process permissions, which the startup log reports.

write_file only writes text and refuses binary targets such as .png, .pdf, .mp4 or .zip; read_file likewise refuses binary files and points to view_image for pictures and manage_files stat for size and type. Images, audio, video, PDFs and archives go in through save_to_workspace, byte for byte: from a message in the current conversation (including images the bot itself sent), from a public URL (through the same private-address-blocking download cache as other fetches), or from an MCP media_id. The real type is sniffed from the bytes and the extension corrected (JPEG is always saved as .jpg). Without an explicit path, chat media and URLs land in downloads/ and the bot's own output in outputs/; existing files are never overwritten by default. When the owner has file writes on, images from image are still delivered as before and the original is also saved to outputs/. manage_files delete does not delete: it moves the entry into .trash/<timestamp>/, keeping its relative path; entries inside the trash cannot be moved or deleted again with manage_files, and nothing can be saved into it.

The workspace is split by purpose: tmp/ for drafts and intermediate files (cleaned after 1 day), downloads/ for downloads and files saved from chat and .agent-browser/ for screenshots (7 days), outputs/ for the bot's own output (30 days), and .trash/, purged 7 days after deletion, all by the daily storage maintenance. keep/<bot>/ is the long-term area and is never cleaned automatically: when the owner says to keep something, save_to_workspace is called with keep=true (or the file is moved into keep/ with manage_files) together with a short description. Each bot's long-term area is capped at 2 GB; beyond that saves are refused rather than evicting older files, and other bots' long-term areas are read-only. The index (path, description, source message, who saved it, when, size, type) lives in .diana/keep-index/ and the newest 20 entries are added to the tail of the owner's reply prompt. Loose files in the workspace root and coding/ repositories that no bot references and nobody touched for 30 days are only reported (log and WebUI), never deleted. Settings → System → Workspace lists files by area and lets you download, delete (to the trash) and empty the trash.

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 coding agent plugin (official.coding-agent) lets the bot hand a coding job to a coding CLI installed on the host: edit code, run tests and commit inside a persistent workspace, for minutes or for hours. You can ask for progress at any point, and when the run ends the bot reports back to the conversation that assigned it. Disabled by default — it changes code in the background and speaks up on its own, so enabling it is a decision you make, not one made for you.

The tool is coding, owner-only, with seven operations: submit, status, tail (the last few actions), cancel, followup (continue in the same CLI session), list and workspaces.

When a job is still running a few seconds after dispatch, Diana itself posts a fixed-format acknowledgement with the job ID, agent, workspace and a summary of the instruction; the model does not write it. That message is the proof a job was really dispatched: if the model claims it handed work to Claude Code without calling the tool, no acknowledgement appears. Jobs that end within those seconds (an auth failure, a suspended account) get no acknowledgement; the dispatching turn replies with the result directly, and when that result is longer than 1,500 characters Diana posts the full text first so the model only states the conclusion. The final report starts with a header that mentions the requester. Results up to 1,500 characters follow in the same message; for longer reports the header carries only the opening lines and the full text follows as one merged-forward card (or as split messages when the bot has merged forwards off or the platform lacks them; a forward that gets no acknowledgement is treated as delivered rather than sent again). If the full text fails, the retry sends only the full text, not the header again. The job record keeps the full result, capped at 20,000 characters; status gives the model only the first 1,500 and sets result_truncated.

Settings

Jobs survive a Diana restart

The CLI starts in its own session (setsid), detached from Diana's process group, with output written to workspace/coding/.jobs/<job>.log and the job record as JSON beside it. On startup Diana scans that directory: a live process is picked back up, a finished one is concluded from its log and any owed report is delivered. The reported flag is only stored after the report goes through, so a failed delivery is retried on the next start rather than silently dropping an hour of work.

PIDs get reused, so re-attaching does not trust a live PID alone: a log quiet for more than 30 minutes ends the job as interrupted. Windows has no setsid equivalent, so jobs there do not survive a restart and are concluded as interrupted.

Authorization boundary

The coding CLI does not go through the built-in agent's command sandbox: it needs network access and repo-wide writes. The presets use --permission-mode auto, so routine changes go ahead on their own and anything that needs a nod goes through chat approval below. The real boundary is four things: only the owner can call it (the tool is absent from the non-owner allowlist and re-checks identity itself), work happens only in registered workspaces (workspace names reject path separators and ..), dangerous operations need the owner to reply with a code, and every call is written to the operation log.

Approving dangerous operations from chat

A job runs unattended, but "and then push it" deserves a human nod. Diana installs a PreToolUse hook for the coding CLI: before each command the hook asks whether it may proceed. Anything not on the dangerous list goes straight through; a match stops the job and Diana sends the owner this:

编码任务 code-3f2a1b（工作区 diana）要执行一个需要你点头的操作：
Bash：git push origin main

同意就回 7c1d9e，不同意回 b40f22。10 分钟内没人回我就当拒绝。

The owner types the code in chat and the job continues; the deny code or a timeout blocks the step, and the CLI decides whether to work around it or end with an error. status reports awaiting_approval along with both codes, so a message that scrolled past can be asked for again.

Why a code rather than the word "yes". Same reasoning as the extension-change confirmation code: the decision reduces to one structural match with no semantic inference, so no phrasing can throw it off in either direction. More importantly the code appears only in the owner's own message — page text, tool output or someone else's message can say "approved" as often as it likes and nothing is released. The code must appear as a standalone fragment, so one embedded in a longer hash does not count; it is consumed on use, so replaying the same message a second time does nothing.

The hook process and Diana talk through a file mailbox under the job directory (.jobs/approvals/) — no local port, no token: the hook is a child of the CLI, its environment is not Diana's to decide, and that directory is always reachable. A useful side effect is that a Diana restart mid-wait loses nothing — the request file is still there, the hook is still polling, and the question is asked again after startup. The hook calls back into Diana's own executable (internal subcommand __coding-approve) rather than a generated script, which avoids executable bits and interpreter paths differing per platform.

This works with Claude Code and ACP agents. Claude Code goes through the PreToolUse hook; an ACP agent goes through the permission requests it sends itself, using the same mailbox and codes, so only operations the agent chooses to ask about can be approved. Codex and a custom command have no equivalent. With approval on and a backend that cannot do it, submitting fails outright instead of quietly allowing everything: silently not asking would be a lie.

When the approval path itself breaks (an unreadable policy file, say) the hook allows and the reason goes to Diana's operation log. That is deliberate: Diana's own plumbing failing should not strand a job halfway. What you truly do not want touched is kept out by the workspace allowlist, not by approval.

Writing the instruction

The coding CLI cannot see this chat. When a change depends on what was said, the model puts the relevant quotes in the context parameter and they are prepended as background. Instructions cap at 8000 characters — they land in argv, which the OS limits per argument; longer material belongs in a file inside the workspace for the CLI to read itself.

Once a job finishes with a session ID, followup continues in that same session, so the CLI remembers the previous round. A running job takes no additions: a non-interactive coding CLI has no channel for mid-run input, and forcing one would just be a second process editing the same checkout.

• 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.