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, 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 and admin configuration such as enabled modules, scope controls, allowlists, trusted roles, log destinations, and short-lived admin lifecycle state.
- Anonymous confession or reply submission text, one trusted-link field, compact review metadata, limited private appeals or reports, and a bot-private author mapping needed to run staff-blind confession moderation when a server enables the feature.
Limited message and attachment context
- Babblebox may read message content or metadata needed to respond to commands, deliver Watch alerts, build Moment Cards from visible messages, process Capture requests, or evaluate locally flagged Shield events.
- Attachment names or URLs may be used at send time when needed for previews or private transcript delivery.
- 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 durable storage of raw confession attachment filenames or raw Discord CDN URLs in staff-facing moderation records.
- No durable quote-feed database for Moment Cards.
- No full deleted-message archive table.
- No long-term storage of DM bodies or full Capture transcript archives.
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.
Feature delivery
Running commands, building replies, sending Watch alerts, delivering reminders, and maintaining lightweight feature state.
Server safety
Applying optional Shield rules, admin lifecycle helpers, configured log delivery, and bounded moderation context where administrators enable those features.
State continuity
Preserving Daily progress, compact user identity data, Later markers, AFK schedules, and other small pieces of state across restarts.
Operational reliability
Keeping storage compact, avoiding unnecessary churn, and limiting what is retained so the bot remains practical on constrained infrastructure.
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.
- Moment Cards are built from visible server messages and remain tied to visible Discord context instead of becoming a hidden archive.
- Watch alerts are delivered through Discord DMs.
- Capture transcripts are delivered privately rather than kept as a long-term database archive.
- Later markers, reminders, anonymous confessions, and sensitive setup flows are designed to avoid unnecessary public exposure.
- Anonymous confessions are optional, keep the author hidden from staff, and are moderated by confession ID and case ID only while Babblebox still enforces safety internally.
- Anonymous replies are off by default, stay text-only when enabled, and always enter private review.
- Self-edit is off by default and limited to pending submissions when enabled; self-delete is available privately 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 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 content. In that flow, only minimal,
sanitized, and truncated flagged content needed for that review is intended to be sent to the configured AI provider.
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 verification 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, trusted-link fields, and attachment metadata after the moderation workflow is complete while compact non-reversible duplicate signatures are retained for abuse prevention.
- Watch configuration, Later markers, reminders, AFK settings, and similar utility records remain until changed, cleared, expired, or removed.
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.
- Administrators remain responsible for the Discord permissions, channels, and server practices they configure around the bot.
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, 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 or repository 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.