Built to stay useful without sprawling.

1. Information Babblebox Collects

Babblebox only works inside the Discord context it is invited into and only with the permissions granted to it. Depending on the feature used, Babblebox may process or store the following categories of information.

Discord account and server identifiers

• User IDs, guild IDs, channel IDs, message IDs, role IDs, and timestamps.
• Basic metadata needed to route commands, produce links, respect scopes, or associate stored feature state with the right user or server.

Feature configuration and compact state

• Watch preferences, filters, ignored channels or users, and scoped keywords.
• Later markers with compact attachment labels, reminders, AFK state, AFK schedules, and related user preferences.
• Daily Arcade scores, attempts, streak counters, Buddy and profile state, and other compact identity or progression fields.
• Shield, moderation, Raid Guard, and admin configuration such as enabled modules, scope controls, allowlists, trusted roles, owner-control policy, trusted owner-control user or role IDs, confirmed Babblebox moderation staff role ID, defense bot IDs, log destinations, moderation cases, warning forgetting and escalation rules, moderator notes, appeal configuration, submitted appeal metadata, appeal review events, review panel delivery metadata, hashed short-lived appeal tokens, punishment DM policy, DM delivery metadata, default ban message deletion settings, effective ban purge-day source metadata, moderation log delivery status, Join Gate notice configuration, compact Join Gate delivery, pressure/backoff, matched-decision, and diagnostics metadata, Join Gate DM suppression metadata, moderation proof thumbnail delivery metadata, purge job metadata, quarantine restore state, Anti-Nuke thresholds, scoped permit configuration including trusted role automation, permit usage counters, bounded safe role-automation digests, compact incident records with release or revoke actor/time/reason/reversal metadata, bounded per-guild transient rows for high-churn Anti-Nuke, Join Gate pressure/diagnostics, and Raid Guard operational windows, bounded recent join metadata, bounded per-incident defense bot action counters, bounded defense bot decision history, modular log routes, compact log event metadata, modular punishment log delivery attempts, log delivery attempts, audit-log cursors, command locks, quarantine-hold markers, stored role rules with target and excluded channel/category IDs, current-plan Role Rules revoke snapshots, auto-role configuration, delegated role-tool configuration, and short-lived admin lifecycle state.
• Server-message automation configuration such as sticky channel IDs, boost announcement channel IDs, enabled state, message mode, configured copy, embed fields, optional direct HTTPS GIF URL, the last bot-owned sticky message ID, retry/error metadata, and compact boost dedupe records.
• Premium linking and entitlement state such as linked Discord and Patreon account IDs, encrypted provider tokens or secrets, resolved plans, guild claims, setup sync token hashes, setup sync import audit records, sync timestamps, webhook dedupe markers, manual overrides, and support-grade audit metadata.
• Optional Top.gg vote bonus state such as the Discord user ID, Top.gg vote event ID, vote timestamps, expiry, vote reminder preference, webhook trace/status fields, and weekend vote weight.
• Anonymous confession, vote, or reply submission text, one Confessions link field under the server policy, compact review metadata, limited private appeals or reports, a bot-private author mapping, poll-scoped voter blind indexes, bot-private owner reply opportunities, opt-in owner-reply DM notification preferences, and short-lived in-memory draft recovery for recoverable rejected Confessions submissions when a server enables the feature; lifecycle cleanup later scrubs or prunes terminal private payloads once they are no longer needed.
• For Confessions, Babblebox protects sensitive content and identity linkage with application-level encryption and separate lookup domains before those fields reach durable Postgres storage.

Babblebox is not designed to store payment card numbers or similar payment-instrument data. Premium payments and billing are handled by the relevant external provider.

Limited message and attachment context

• Babblebox may read message content or metadata needed to respond to commands, deliver Watch alerts, process Capture requests, or evaluate locally flagged Shield events, including visible message text, embed text, forwarded message snapshots, attachment labels, optional local OCR text extracted from eligible Discord-hosted images when Shield image scanning is enabled, and compact dangerous-file metadata or SHA256 prefixes when the opt-in Shield file layer is enabled.
• Server-message automation may read channel activity metadata to keep a bot-owned sticky message last and may process Discord server-boost signals to announce configured boost messages.
• Optional Shield Profile Monitoring may process Discord API-available identity fields, including username, global display name, server nickname, active display name, account age, join age, role IDs, profile quarantine status, stored role IDs for release, and bounded Profile Watch expiry state.
• Later markers keep compact attachment labels instead of raw attachment URLs, while private Capture transcript files may include currently available attachment URLs at send time.
• For anonymous confessions, raw attachment filenames and raw Discord CDN URLs are kept out of staff-visible review surfaces.

What Babblebox is designed not to store durably

• No general-purpose message archive.
• No media or attachment blob storage in Postgres.
• No raw image or full OCR-text storage from Shield image scanning.
• No raw attachment files from Shield dangerous-file scanning.
• No raw moderation proof image storage; slash moderation uses one slash proof attachment, prefix messages can contribute bounded proof attachments, and relevant moderation commands may locally create compact proof thumbnails for configured log delivery while storing compact proof metadata on the case.
• No deleted-message body storage from ban message deletion; Babblebox stores only the effective purge-day count, source, and delivery metadata needed for staff auditability.
• No bio, About Me, custom status, or profile-picture content from Shield Profile Monitoring.
• No durable raw attachment URLs in Later markers.
• No durable storage of raw confession attachment filenames or raw Discord CDN URLs in staff-facing moderation records.
• No durable Confessions draft recovery rows; recoverable rejected drafts are short-lived in-memory only and expire quickly.
• No full deleted-message archive table.
• No message-body or voice-content archives from modular logs.
• No raw setup sync tokens or raw appeal tokens.
• No deleted-message body storage from purge actions.
• No server backups, server backup snapshots, or full role/channel permission warehouse.
• No long-term permission history snapshots or member activity logs for Role Rules, Role Tools, or auto-role.
• No long-term storage of DM bodies or full Capture transcript archives, and no punishment-DM bodies or rendered Join Gate DM bodies.

2. How Information Is Used

Babblebox uses information only to operate its Discord features and to keep those features reliable, low-noise, and reasonably safe.

No advertising profile

Babblebox is not built as an ad network, data brokerage product, or engagement farm. Stored data exists to operate the bot, not to build a separate marketing profile about users.

3. Public vs Private Behavior

Babblebox deliberately treats visibility differently depending on the feature. Some commands are designed for public, shareable output. Others are intentionally private-first because they can contain personal context, reminders, server reading position, or moderation setup details.

• Public profile-style surfaces, Daily Arcade sharing, and similar outputs are intended to be visible in-server.
• Watch alerts are delivered through Discord DMs.
• Capture transcripts are delivered privately; private Capture transcript files may include currently available attachment URLs at send time, but Babblebox does not keep full transcript archives long-term.
• Later markers store compact attachment labels instead of durable raw attachment URLs, and reminders, anonymous confessions and votes, plus sensitive setup flows are designed to avoid unnecessary public exposure.
• Premium account linking, status, refresh, and guild-claim flows are private-first so entitlement checks and provider identity handling do not spill into public channels.
• AFK reasons, reminder text, public reminder delivery, watch keywords, bump reminder copy, and Confessions text/link/vote checks now use bounded private Shield feature-surface evaluation instead of bypassing Babblebox core safety entirely.
• Sticky channel messages and boost announcements are configured privately by admins, but their successful output is public in the selected channel; Shield checks configured server-message copy at save time and again before public delivery.
• Shield Profile Monitoring can check Discord API-available identity fields, quarantine high-confidence unsafe profile text with stored role IDs for release, and use bounded Profile Watch for weaker combined signals; it does not collect bio, About Me, custom status, or profile-picture content.
• Anonymous confessions and Anonymous Votes are optional, keep authors and voters hidden from staff, and are moderated by confession ID, vote ID, and case ID only while Babblebox still enforces safety internally.
• The /confessions root is permission-unfiltered at Discord's slash visibility layer because Discord cannot see Babblebox's configured staff role; manual Confessions moderation still requires Manage Messages plus that configured role at runtime, and setup and policy changes stay admin-only.
• Confessions moderation logs record staff actor, action, confession/vote/case/ticket IDs, result, purge counts, route status, delivery status, and safe error text without recording author identity, raw confession body, link URL, private media payload, encrypted payload, duplicate hash, or owner-reply private data.
• That privacy model is meant to reduce casual database readability and accidental exposure, not to claim that the service operator has been removed from the trust boundary.
• Deploying the Confessions privacy code and keys is not enough by itself; Babblebox now tracks a privacy-hardening readiness state because legacy rows remain weaker until the Confessions backfill finishes.
• Confessions, anonymous replies, owner replies, and pending self-edits allow up to 4000 characters; Anonymous Votes use a short question and 2-5 short text-only options up to 24 characters each, including emoji-only labels; appeals and reports stay capped at 1800.
• Servers can configure up to 3 public Confessions channels for both CF- confession posts and CV- anonymous vote posts; Babblebox stores the selected target channel ID so reviewed posts publish to the intended public channel without keeping raw published confession text long-term.
• If a submitted confession or Anonymous Vote is rejected after a private modal by recoverable destination drift, stale setup, Shield/safety checks, link/private-info/mention policy, vote validation, or practical image validation, Babblebox may keep a short-lived in-memory draft recovery copy for up to 15 minutes.
• Confessions draft recovery is scoped to the same server, member, draft kind, and random token; it retains only typed draft text such as confession body/link or vote question/options/duration/intended destination, and recovered drafts still pass current validation before anything posts.
• Confessions draft recovery does not retain files, images, attachment objects, raw Discord CDN URLs, clipboard state, staff-visible previews, logs, or durable draft rows; the private manual-copy view deactivates links and escapes mentions/code fences.
• Confessions link mode can be Disabled, Trusted Only, or Allow All Safe, but Babblebox Shield still blocks unsafe or high-risk destinations in every mode.
• Anonymous Votes are off by default, route through private review by default when enabled, block links, mentions, attachments, and images, publish public aggregate percentages and total voter count, and keep per-voter ballots in poll-scoped blind indexes instead of raw voter IDs; ballot lookup rows are scrubbed after close or delete while aggregate counts remain, and old closed vote metadata is pruned by the Confessions lifecycle cleanup window.
• Reply anonymously is off by default, stays text-only when enabled, stays anonymous, may go through private approval before posting, routes top-level replies to confessions or votes into one reusable thread when Discord allows it, keeps reply-confessions inside that same thread without nested threads, and labels the original root author's public reply as Anonymous OP Reply without exposing identity.
• The latest eligible live confession post can also show Create a confession so members keep one current in-channel launcher.
• Owner reply opportunities are bot-private, can trigger from explicit Discord replies to a published confession, public anonymous replies to it, or first public owner replies, and always remain available through /confess reply-to-user; expired, dismissed, or used opportunities scrub private source payloads while retaining compact status metadata during the retention window.
• Owner-reply DM prompts are opt-in; notification preferences use guild-scoped keyed lookup hashes, default absence means inbox-only, and enabling DMs creates Discord-visible DM messages that may remain in the member's DM history.
• Public owner replies and OP-labeled public anonymous replies post as Anonymous OP Reply, stay text-only, and do not expose the confession or vote owner or the responding member in public or staff-facing moderation surfaces.
• Self-edit is off by default and limited to pending submissions when enabled; self-delete is available privately for confessions, votes, and replies through Babblebox's internal ownership check.
• Clean top-level confessions and votes can move only between configured public Confessions channels; member moves are one-time and limited to 5 minutes after publication, staff moves are permission-gated and staff-blind, and posts with replies, owner-reply opportunities, or Discord threads cannot be moved.
• Permanent Confessions bans default to deleting the latest published top-level confession from that hidden author, with configurable disabled or all published top-level modes; temp bans and pauses do not purge by default.
• Confession images are off by default and only work after admins explicitly enable them; enabled image confessions always enter private review.
• Appeals or reports can be sent privately to a configured support channel without exposing the author's Discord identity to staff; resolved support ticket details and stale review-message metadata are scrubbed, and old resolved tickets/cases are pruned after the Confessions history window.
• Babblebox hides the sender's account identity, but a self-identifying link destination or image content can still reveal them if they choose to include it.
• Shield and admin configuration flows are intended for administrators and moderators, not general public broadcast.

4. Sharing and Third Parties

Babblebox may rely on infrastructure providers necessary to run the bot, such as Discord for platform delivery and Supabase or Postgres-backed storage for durable feature state.

Optional premium linking and entitlement checks

If premium linking is enabled, Babblebox may exchange data with Patreon to link a Discord user to a Patreon member identity, verify active tiers, refresh entitlement state, process webhook updates, and support manual recovery when provider delivery is stale or interrupted. That can include Patreon member IDs, tier IDs, campaign IDs, encrypted OAuth tokens, compact sanitized webhook event metadata, and guild-claim state. Babblebox deletes the local encrypted Patreon tokens when a user unlinks and is not designed to receive or store payment card data from Patreon.

Optional admin dashboard login

If the private admin dashboard is enabled, Babblebox uses Discord OAuth with only the identify and guilds scopes to sign in an administrator, fetch the user's current Discord guild list, and show only servers where the user has owner, Administrator, or Manage Server access and where Babblebox is present. Babblebox stores an opaque server-side dashboard session, the signed-in Discord user ID and basic display fields, and a short-lived guild permission snapshot needed for the server picker. Discord OAuth access tokens are used only during the callback and are not stored after the user and guild data are fetched. Dashboard session cookies are HttpOnly, Secure, and SameSite=Lax; tokens are not designed to be placed in localStorage, URLs, logs, or public JSON. Ordinary members cannot use dashboard settings unless their current Discord permissions already grant server-admin access for that server.

When dashboard setting writes are enabled, Babblebox still rechecks the live Discord member, guild, bot permissions, CSRF token, owner-control policy, and storage readiness before any safe server-configuration change. Dashboard writes cover durable server configuration only; runtime moderation actions, private review queues, provider internals, raw evidence, and personal or member-only commands stay Discord-only. Dashboard previews and audit history expose only sanitized feature ids, changed field names, readiness, and delivery status, not raw message bodies, provider payloads, Discord OAuth tokens, session tokens, CSRF values, or confession content. Operators can set BABBLEBOX_DASHBOARD_WRITES_DISABLED=true to force the dashboard into read-only mode without a code rollback.

Optional Top.gg vote bonus checks

If the Top.gg vote bonus lane is enabled, Babblebox may receive Top.gg webhook events and optionally query Top.gg for a user's current vote window when that user explicitly refreshes /vote. That can include the Top.gg vote event ID, created or expires timestamps, weekend vote weight, webhook trace metadata, and the user's vote reminder preference. Babblebox does not need to durably store a Top.gg username or avatar_url for the vote bonus lane.

Optional AI-assisted Shield review

Babblebox does not perform always-on AI scanning by default. If optional AI-assisted Shield review is enabled where available, it only runs after local Shield logic has already flagged live-message content. Owner policy controls whether Shield AI runs at all and can keep gpt-5.4-nano, gpt-5.4-mini, and gpt-5.4 configured by default, while effective higher-tier use still depends on Guild Pro entitlement and provider/runtime readiness. In that flow, only minimal, sanitized, and truncated flagged text needed for that review is intended to be sent to the configured AI provider, even when the local signal came from embed text, attachment labels, forwarded message snapshots, or sanitized OCR-extracted image text instead of the raw message body alone. AI does not scan images and must not receive image bytes, base64, screenshots, raw image URLs, raw QR payloads, filenames, or visual content. Shield's private feature-surface checks for AFK, reminders, watch keywords, bump reminder copy, server-message copy, and Confessions stay AI-free in this release.

Shield image OCR and QR decoding are local-only. Babblebox does not use external OCR APIs, QR APIs, paid OCR services, or OCR API keys. If the local Tesseract or zbar runtime is unavailable, Babblebox keeps running and falls back to hash, metadata, and override signals.

When Shield flags an image scam, the original flagged upload may be attached to the configured Shield log channel for moderator review. Babblebox does not persist those raw images in its database or action records, and AI review still receives only sanitized OCR text plus compact metadata.

Shield dangerous-file scanning is opt-in and compact. Babblebox may evaluate attachment filenames, declared size/content type, message context, and local known-bad SHA256s. When hash reputation is explicitly enabled, file hashes may be checked with configured reputation providers, but raw attachment files are not uploaded to reputation providers. Babblebox does not execute, decompress, inspect macros, or persist suspicious files, and malware-file alerts do not attach the suspicious file to Shield logs.

No sale of personal information

Babblebox is not designed to sell user data. Information is shared only when needed to operate the service, comply with law, protect the service, or deliver optional integrations that a specific feature requires.

5. Retention and Deletion

Babblebox aims to keep durable data small, specific, and tied to live product needs instead of retaining broad historical records.

• Daily Arcade raw result rows are designed to prune after 60 days while streak and lifetime totals remain in the profile row.
• Free Data Saver keeps server storage bounded while core features stay useful; Guild Pro Extended Audit/Analytics Retention applies only to the documented claimed-server resource windows.
• Free Question Drops raw analytics rows prune after 45 days; Guild Pro can keep Question Drops raw analytics rows for 180 days on the claimed server while compact mastery/profile aggregates remain.
• Short-lived admin lifecycle records are kept only while they are operationally relevant, such as pending follow-up review or active follow-up role management.
• Compact modular log events and delivery-attempt rows are pruned by a bounded scheduled cleanup job; the 7-day Free baseline applies unless a later plan-specific retention policy applies, and Guild Pro can extend modular log retention to 30 days for the claimed server.
• Confessions lifecycle cleanup keeps active review/support flows, active Anonymous Vote data, pending owner reply opportunities, bot-private author mappings, and compact keyed duplicate/accountability metadata while those states still need them.
• Resolved anonymous confession rows scrub previews, body text, link fields, private media metadata, expired owner-reply payloads, resolved support details, closed vote ballots, and stale review-message metadata after the workflow no longer needs them.
• Free uses a 7-day Confessions case/support/history retention baseline after private payloads are scrubbed; Guild Pro can extend Confessions case/support/history retention to 30 days for the claimed server, and Babblebox Plus does not unlock this server-resource retention.
• Expired dashboard OAuth states/sessions, setup sync tokens, appeal tokens, Shield temporary action records, Top.gg webhook dedupe rows, provider webhook rows, and ops redeploy attempt rows are pruned in small scheduled batches.
• Ban-return candidate records are intended to have a bounded purge window rather than indefinite retention.
• Resolved anonymous confession rows scrub previews, body text, link fields, and attachment metadata after the moderation workflow is complete while compact keyed duplicate signatures are retained for abuse prevention.
• Keyed duplicate-abuse signals are guild-scoped instead of global across every server.
• Shield image hash or OCR/QR-fingerprint overrides are guild-scoped, expiry-bound, and store compact hash/fingerprint evidence rather than raw images, full OCR text, or raw QR payloads. Free servers can retain those overrides up to 30 days; Guild Pro can extend that server-side retention to 180 days.
• Role Rules revoke history keeps 5 actions for 7 days on Free; Guild Pro can keep 15 Role Rules revoke-history actions for 30 days, with compact before/after overwrite bitmasks for revoke only.
• Shield dangerous-file known-bad matching uses operator-owned SHA256 entries and short-lived diagnostics with hash prefixes rather than raw files, Discord CDN URLs, or file bytes.
• Raid Guard stores bounded recent join metadata, compact first-message pressure signals for recent joiners, trust target IDs, defense bot IDs, bounded per-incident defense bot action counters, bounded defense bot decision history, incident evidence summaries, failed-containment retry metadata, and reversible containment action metadata in bounded per-guild transient rows where appropriate so it can recover after restart; it keeps no message-body archive and does not store deleted-message bodies.
• Profile quarantine records are guild-scoped and store the quarantine role, stored role IDs for release, compact evidence summaries, retry token expiry, and release state; Profile Watch records are temporary and expire automatically.
• Delegated role-tool configuration stores only command-user, /giverole add-target, and /removerole remove-target role IDs; role-tool action records are delivered to the configured admin log channel rather than kept as a separate Babblebox case archive.
• Watch configuration, Later markers, reminders, AFK settings, and similar utility records remain until changed, cleared, expired, or removed, with Later retaining compact attachment-label state rather than raw attachment URLs. Later markers older than 60 days are cleanup targets.
• Server-message configuration remains until an administrator changes or disables it; server-message boost-event history is compact operational state used to avoid duplicate announcements and is pruned after 90 days.
• Premium link, entitlement, claim, provider state, and manual override records remain until they are superseded, unlinked, expired, revoked, or no longer needed for support, abuse prevention, or operational recovery; provider webhook dedupe rows are kept only for a compact support/abuse window, normally no more than 90 days.

Deletion timing can depend on when a reminder expires, a schedule ends, a configuration is removed, or a short-lived moderation workflow finishes.

6. Security

Babblebox takes a data-minimization approach because the safest archive is often the one that was never created. Even so, no internet-connected service can promise absolute security.

• Storage is intended to be compact and purpose-limited.
• High-volume or high-risk archive behavior is intentionally avoided where possible.
• Private-first flows are used for utilities and other sensitive feature surfaces when appropriate.
• Sensitive Confessions content and identity linkage use separate application-managed encryption domains and keyed lookup hashes.
• Babblebox exposes operator-facing warnings when Confessions privacy hardening is only partial and the backfill or key rotation cleanup is still incomplete.
• Public status endpoints expose only non-sensitive liveness/readiness summaries plus sanitized premium-provider aggregates; they do not expose table names, index names, row contents, raw Confessions internals, provider payloads, or secret-bearing connection details, and they are not authenticated operator consoles.
• Administrators remain responsible for the Discord permissions, channels, and server practices they configure around the bot.

Babblebox does not claim to be zero-knowledge or operator-proof. Infrastructure operators with code, runtime, and key control are still part of the trust model even after these privacy hardening measures.

7. Choices and Requests

Users and server administrators can often control Babblebox directly through the feature itself, such as clearing Later markers, removing reminders, disabling Shield live moderation, or changing Watch settings. Server owners also control whether Babblebox is invited, where it can see content, and which channels are used for logs or moderation workflows.

If you need help with a privacy-related request, a correction, or a removal question related to Babblebox-managed state, use the support contact points listed below and include enough context to identify the relevant server, user, or feature state.

8. Contact and Policy Updates

Babblebox may update this policy when the product, storage model, or privacy practices materially change. When this page is updated, the effective date at the top will also be updated.