Discord: per-channel random styles, message metadata, moderation tools, and public-data isolation #26

New issue

Closed

opened 2026-09-01 01:48:03 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-09-01 01:48:03 +00:00

(Migrated from github.com)

Goal

Extend zara-discord so Mara can inspect opted-in new Discord messages with bounded message/member metadata, make scoped moderation decisions, and use per-channel spontaneous-reply behavior.

Requirements

Pass new-message content plus Discord metadata to Mara when the channel is configured for random/inspection mode: message/channel/guild IDs, author ID/username/display name, roles, account creation/join timestamps, message timestamp, reply/reference IDs, attachment metadata, and relevant moderation state.
Keep this metadata internal to the Mara turn by default; do not echo identifiers in public output unless explicitly required.
Isolate Discord conversation IDs per guild/channel/user to stop one Discord user inheriting another user's transcript context.
Per-channel random configuration: enabled, chance, trigger/inspection prompt, reply style. Support a build-updates style such as only replying to red/failed builds with a short funny response.
Mara may return a no-reply sentinel for inspected messages that do not meet the channel trigger.
Add scoped moderator tools for the current message author: inspect, delete message, warn/reply, timeout, kick, ban. Require an ephemeral message-context token and refuse actions outside that token's guild/message/author.
Moderation is opt-in per channel and off by default. Refuse owner/admin/moderator/self targets; rely on Discord hierarchy as a second gate.
Ban/timeout/etc. actions use bounded reasons and an optional configurable funny public acknowledgement (no personal data), e.g. uwu, moderation bonk deployed.
Never log/store bot token or raw message content in plugin settings. Context tokens expire and live in memory only.
Add deterministic tests for routing, metadata formatting, per-channel policy persistence, no-reply suppression, action scoping, protected-target refusal, and conversation isolation.
Bump plugin version and update docs/registry.

Security follow-up

The plugin can harden Discord-side routing and action scoping, but Zara core currently dispatches service-plugin SubmitTurn calls through the host principal. Open/track a Zara-core follow-up for a true guest/public principal + tool/memory capability boundary so Discord turns cannot reach operator-private memories/files by construction.

## Goal Extend `zara-discord` so Mara can inspect opted-in new Discord messages with bounded message/member metadata, make scoped moderation decisions, and use per-channel spontaneous-reply behavior. ## Requirements - Pass new-message content plus Discord metadata to Mara when the channel is configured for random/inspection mode: message/channel/guild IDs, author ID/username/display name, roles, account creation/join timestamps, message timestamp, reply/reference IDs, attachment metadata, and relevant moderation state. - Keep this metadata internal to the Mara turn by default; do not echo identifiers in public output unless explicitly required. - Isolate Discord conversation IDs per guild/channel/user to stop one Discord user inheriting another user's transcript context. - Per-channel random configuration: enabled, chance, trigger/inspection prompt, reply style. Support a build-updates style such as only replying to red/failed builds with a short funny response. - Mara may return a no-reply sentinel for inspected messages that do not meet the channel trigger. - Add scoped moderator tools for the current message author: inspect, delete message, warn/reply, timeout, kick, ban. Require an ephemeral message-context token and refuse actions outside that token's guild/message/author. - Moderation is opt-in per channel and off by default. Refuse owner/admin/moderator/self targets; rely on Discord hierarchy as a second gate. - Ban/timeout/etc. actions use bounded reasons and an optional configurable funny public acknowledgement (no personal data), e.g. `uwu, moderation bonk deployed`. - Never log/store bot token or raw message content in plugin settings. Context tokens expire and live in memory only. - Add deterministic tests for routing, metadata formatting, per-channel policy persistence, no-reply suppression, action scoping, protected-target refusal, and conversation isolation. - Bump plugin version and update docs/registry. ## Security follow-up The plugin can harden Discord-side routing and action scoping, but Zara core currently dispatches service-plugin `SubmitTurn` calls through the host principal. Open/track a Zara-core follow-up for a true guest/public principal + tool/memory capability boundary so Discord turns cannot reach operator-private memories/files by construction.

nsaspy closed this issue

2026-09-08 02:02:50 +00:00

nsaspy referenced this issue

2026-09-08 02:02:50 +00:00

Discord: opt-in message-content intent for inspection/moderation channels #27

nsaspy commented

2026-09-08 02:04:54 +00:00

Owner

Auto-RAGE compatibility handoff after #72/#73: current Zara Core SubmitTurn (lost-rob0t/zara at 7cb047a390644c7da96cfb4620bfb8d569450fff) exposes text, conversation_id, and context_ids, but no guest/public principal or per-turn tool/memory capability field. zara-discord can isolate transcripts and apply a fail-closed public-output filter, but it cannot enforce the required public principal boundary from this repository without bypassing the canonical runtime contract. Core needs an explicit public/guest principal + capability surface before #26's isolation requirement can be claimed complete. Plugin work can continue independently.

Auto-RAGE compatibility handoff after #72/#73: current Zara Core `SubmitTurn` (`lost-rob0t/zara` at `7cb047a390644c7da96cfb4620bfb8d569450fff`) exposes `text`, `conversation_id`, and `context_ids`, but no guest/public principal or per-turn tool/memory capability field. `zara-discord` can isolate transcripts and apply a fail-closed public-output filter, but it cannot enforce the required public principal boundary from this repository without bypassing the canonical runtime contract. Core needs an explicit public/guest principal + capability surface before #26's isolation requirement can be claimed complete. Plugin work can continue independently.

nsaspy referenced this issue

2026-09-08 02:17:51 +00:00

[WORKER] Integrations+Registry — plugin expansion, packaging and security hardening loop #52

nsaspy referenced this issue

2026-09-08 02:20:11 +00:00

Security: isolate Discord conversations per user #492