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, defense bot IDs, log destinations, moderation cases, warning forgetting rules, moderator notes, appeal configuration, submitted appeal metadata, appeal review events, hashed short-lived appeal tokens, punishment DM policy, DM delivery metadata, moderation proof thumbnail delivery metadata, purge job metadata, quarantine restore state, Anti-Nuke thresholds, scoped permit configuration, permit usage counters, compact incident records, bounded recent join metadata, bounded per-incident defense bot action counters, modular log routes, compact log event metadata, log delivery attempts, audit-log cursors, command locks, quarantine-hold markers, stored role rules with target and excluded channel/category IDs, seven-day last-five 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, and opt-in owner-reply DM notification preferences needed to run staff-blind confession moderation when a server enables the feature.
• 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; relevant moderation commands may locally create compact proof thumbnails for configured log delivery and store compact proof metadata on the case.
• 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 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.

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.
• 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.
• 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.
• 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, and keeps reply-confessions inside that same thread without nested threads.
• 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.
• 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 post as Anonymous OP Reply, stay text-only, and do not expose the confession 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.
• 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.
• 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 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 180 days while streak and lifetime totals remain in the profile row.
• 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.
• 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.
• 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, incident evidence summaries, and reversible containment action metadata 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.
• Server-message configuration remains until an administrator changes or disables it; boost dedupe records are compact operational records used to avoid duplicate announcements.
• Premium link, entitlement, claim, and webhook-dedupe records remain until they are superseded, unlinked, expired, revoked, or no longer needed for support, abuse prevention, or operational recovery.

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