Privacy Policy

Effective Date: June 24, 2026 · Last Updated: July 26, 2026

1. Information the Bot Can Access

Discord gives the bot a limited set of privileged data feeds ("intents"):

• Message content: text, attachments, and embeds in servers where the bot is present, checked in memory as messages arrive to enforce channel rules, run optional staff filters, and notice when someone talks to it. Message text is not stored.
• Server and channel information: basics such as channel IDs and types, so the bot knows where it may operate.
• Member, role, and ban status: the roles you hold, join, leave, and role-change events, and whether you are banned, so the optional appeals site can confirm a ban is genuine.
• Message authorship and reactions: each message's author, and who reacted with which emoji on which message. Only identifiers and content-shape flags reach the stored records described in the next section, never the text.

2. How That Information Is Used

The bot uses that information to run its features:

• Enforce moderated-channel rules and posting limits: check each message, remove what breaks the rules, and tell the author why. If a media link never got a Discord preview, the bot may send a HEAD request to that URL to learn its file type, downloading nothing.
• Purge a member's attachment posts across the server on an admin's command or when they leave.
• Manage combo, verification, and interest roles.
• Send one-time messages (a media overview, a welcome) and reply with a short quip when someone directs a message at the bot.
• Run Marshal's Lab when an administrator enables it: create a temporary channel, reply to some of what is said in it, and delete the channel when the room closes. Inside it the bot may also delete a message or briefly revoke a member's Send Messages. Section 5 covers what that sends.
• Carry out staff moderation and run the optional filters an admin enables. Anti-spam works from short-lived in-memory fingerprints, lengths, and tagged IDs rather than text. Phishing screening tries local patterns first and may send a URL alone to Google Web Risk if configured. Message logging posts edited or deleted text into a staff log channel that lives in Discord, not the bot's database.
• Operate the optional social features: ask-to-DM requests, ban appeals, and support tickets, whose private threads keep uninvited members out, apply a decision ticket's role changes, run anonymous suggestion votes, and close on resolution or after three quiet days.
• Authenticate web dashboard visitors, run its public and staff pages, and produce the aggregate reports on the staff Activity page.
• Let a Discord-authenticated person browse and delete their own indexed attachment posts, with destructive actions requiring a recent Discord sign-in, and show a signed-in person their own stats and warning record. Each person sees only their own figures.
• Respond to admin commands and configuration panels.

That is the whole list. The bot uses information only to provide, secure, maintain, and review the features in this Policy. No advertising, no unrelated profiling, and we never sell or rent your data.

3. Information the Bot Stores

Everything the bot saves lives in a MySQL database on its host. Credentials, a rebuildable cache, and appeal image evidence live in local files instead (a non-production test configuration may list Discord user IDs allowed to bypass the appeal ban check).

Server setup and housekeeping

• Configuration: whatever an admin sets up. Channel flags and limits, sticky text, role-combo and verification rules, the kink-role catalog map, the OC media-event catalog, the channel and role choices for each optional feature, moderation filter switches, and webhook credentials.
• Housekeeping: small operational records that let the bot finish or resume its own work, such as job checkpoints, digest tallies, short-lived posting-window, posting-lock, and violation-strike rows, and message-index catch-up progress. IDs, counts, or timestamps only, cleared once the work they track is done.

Member tracking

• One-time delivery lists and last-active day: who has already received the media overview DM or welcome, and, per member, the UTC date of your most recent message. No time, channel, or content. Deleted when you leave.
• Quip relationship stats: per member, light interaction counts and seven 0–100 "mood" numbers, like annoyance and kindness, that drift back to fixed defaults on their own. No message content.
• Quip conversation memory: a short rolling window of only the messages you aimed directly at the bot, meaning an @mention of it or a reply to one of its messages, and its replies to you. Up to the last 8 exchanges, so back-to-back exchanges read as one conversation. Nothing from general chat is ever stored. Each exchange is purged within 48 hours regardless.
• Emoji tallies: per member, how often each emoji appears in your messages. The emoji and a count only, no text and no post reference, shown only to you on your own page.
• Reaction records: who reacted with which emoji on which message, kept as server, message, user, and emoji IDs plus a timestamp, never message content. Removed when the reaction or the reacted message is deleted.

Message metadata and activity

• Message index: for every message in text channels and threads, the guild, channel, message, and author IDs, thread placement, timestamp, five content-shape flags, and bounded sanitized attachment display names. No message text, URLs, attachment bytes, or embed bodies. A message the bot observes is gone keeps its row marked deleted with its attachment names cleared, so all-time counts stay accurate. Wiped when the bot leaves the guild.
• Activity reporting: one aggregate report per server after a full index audit, covering totals, busiest channels, and a short top-poster list with names as they were at the time of the run. Alongside it, per-UTC-day counts only. Daily rows are pruned after a year, and both go when the bot leaves.

Moderation records

• Warnings: who, by whom, the reason, and a timestamp. One ages off per three months of clean behavior. A resolved warning stays reviewable for up to two years, visible to the warned member on their own page without naming the staff member.
• Temporary bans: who was banned, why, by whom, when it lifts, the single-use return invite code, and enough internal bookkeeping, including a random tracking ID, to finish or resume the ban after a restart. The record is deleted once the ban has ended and the return invite is cleaned up. If Discord is temporarily unreachable, the record is kept and retried later.
• Temporary role grants: the member, role, and moderator involved, when the role is removed, and whether the member already held the role. Deleted at the scheduled removal.
• Mod-log button references: enough to keep undo buttons on staff mod-log posts in sync. Removed once resolved, or within 90 days.

Optional features

• DM requests: asker and recipient, outcome, and the shared private thread as the ongoing record. Prior accepts and rejection counters are kept to flag possible harassment, and staff monitoring begins once a pair is flagged.
• Support tickets: per-server ticket configuration, and one record per ticket covering the opener, type, intake label and details, status and outcome, and any staff resolution text, plus the thread's participant list. Suggestion tickets also keep the suggestion text and its public vote post, which never names the submitter. The conversation itself stays on Discord.
• Ban appeals: your user ID, Discord username, and display name, the appeal and reply text from both sides, optional uploaded images stored on the bot host, and the status, resolution, and staff approval votes. Capped at 500 appeals per server, and image files are removed with the record.
• Self-service media deletion: a receipt for each deletion you confirm, covering who, scope, status, and counts, with a running checkpoint while it works. Finished receipts are deleted after 30 days.

Web sign-in

Discord OAuth with the identify scope only, and your access token is not retained. The browser gets a signed mb_session cookie (about 24 hours) and, during login, mb_oauth_nonce (about 10 minutes), both HttpOnly, SameSite=Lax, and Secure. Each new sign-in invalidates older sessions, and logging out revokes every copy. CSRF and rate-limit state stays in memory.

Member names and avatars, on the presence panel and on mirrored guide pages, show only to signed-in users verified as current, non-banned members. Everyone else sees a generic @user or no identity at all. Visitors who confirm they are 18 or older get a first-party mb_age_ok cookie whose value is a constant 1, recording only that the gate was acknowledged. It lasts a year.

Marshal's Lab

When an administrator enables the temporary room, the bot keeps per-server settings and the frozen decision for the most recently evaluated day, neither of which contains member data. It also keeps one record per room, silence records that never outlive the room, room-scoped and permanent opt-out records as consent records, and per-room tallies with no user IDs.

To judge how busy a server is, it holds a running message-rate count in memory only, with no content, user IDs, or channel IDs, plus a per-server activity calibration of a handful of numbers recomputed by each index audit. The room's own recent chatter is held in memory only and discarded when the room closes.

What it does not store

Apart from a sticky an admin creates, the bot does not keep:

• Message text, attachment bytes, or embeds. Sanitized attachment display names in the index are the one exception, and message-log and mod-log posts live in Discord, not the database.
• Usernames, or who holds which role, beyond the records above.
• Links checked for scams. A Google Web Risk lookup sends the URL alone.
• Rolling posting-limit counts. In memory only.

With those exceptions, message content and a member's roles stay in memory only long enough to act, then are discarded.

4. How Long Information Is Retained

Most records last as long as the thing they describe: settings until changed, pending items until resolved. A server's data is deleted when the bot leaves that server, or on request. The exceptions:

• Message index: when the bot notices a message is gone, its row is marked deleted and its attachment names are cleared, but the row itself stays so all-time counts remain accurate. These rows go only when the bot leaves the guild.
• Daily activity aggregates are pruned after a year.
• Web sessions: the browser cookie expires in about 24 hours. The server-side session record has no automatic expiry and lasts until an operator review. Removing it signs that user out everywhere.
• Warnings stop counting after three months of clean behavior. The resolved record stays reviewable for up to two years, then is deleted. Mod-log button references clear when resolved or, at the latest, after 90 days.
• Quip conversation memory is the shortest-lived thing the bot keeps: purged within 48 hours, capped at the last 8 exchanges, and deleted the moment the member leaves.
• Quip relationship stats and a member's last-active day are deleted when the member leaves. Emoji tallies and reaction records are kept even then, since they are re-derived from messages still in the server, and go only when the bot itself leaves.
• Self-service deletion receipts are deleted 30 days after the job finishes. Support tickets stay with their archived Discord thread as the server's support history.
• Ban appeals are capped at 500 per server and remain, with their uploaded images, until an admin purges them via /mod config or asks us to delete that data.
• Marshal's Lab: a silence never outlives the room. The room record, its room-scoped opt-outs, and its counters are pruned about 30 days after the room closes, and the channel and its in-memory chatter disappear the moment it does. Per-server settings and permanent opt-out records last until cleared. Lab messages keep their message-index rows on the same schedule as everything else.

There is no general message content log and no role history.

5. Who We Share Information With

We do not sell, rent, or otherwise pass along what the bot observes or stores, with these exceptions:

• Discord, since the bot runs on its platform (see Discord's Privacy Policy).
• Google Web Risk, only when the phishing filter is enabled and configured: just the checked URL, never message text, usernames, or user IDs (see Google's Privacy Policy).
• Anthropic (Claude API), only when the host has enabled the optional AI quip feature. Described below.
• Google Fonts, when a visitor opens the optional live web dashboard: the browser requests fonts from Google and may send ordinary request metadata such as an IP address and headers, but no member content. The standalone legal pages use system fonts and make no such request.
• When the law, legal process, or a valid government request requires it.

What goes to Anthropic

When a member aims a message at the bot, that text (capped around 500 characters) is sent with their quip relationship stats and conversation memory, so the reply reads as a continuation. If they @mention the bot while replying to another message, that one pointed-at message rides along too, capped around 240 characters, with user, role, channel, and emoji IDs replaced by neutral placeholders and attachments reduced to a count.

The member's display name and the names of the roles they wear are sent so the bot can address them properly and get pronouns right. Roles here are self-chosen public self-description, and they are the only pronoun signal the bot gets: told to use they/them when no role says otherwise, it never guesses. No usernames, user IDs, or channel names are sent, and a member with no display name distinct from their username has no name sent at all.

Beyond a single pointed-at message, only messages a member sent to the bot ever leave the host. Anthropic processes what it receives under Anthropic's Privacy Policy, and the bot falls back to its built-in reply pools when the feature is off.

Marshal's Lab, the one exception

Marshal's Lab is the one narrow exception to that boundary, confined to a single temporary channel the bot creates on its own initiative and later deletes. Inside it, and only inside it, messages not addressed to the bot may also be sent to Anthropic. Everywhere else the promise above stands exactly as written.

Even there the bot samples, so most messages in the room are never sent. What rides along is that message shortened to roughly 160 characters, plus up to about a dozen recent lines from that room, held in memory only. No usernames, user IDs, or channel names are sent.

Speakers are labelled with the display name the channel already shows. A member with no display name, or two who share one, gets a room-local stand-in such as "Member B", assigned in speaking order and discarded when the room closes. A member who has used the safe word or opted out has neither their words nor their name sent, and anything of theirs in memory is erased.

The member being answered is described the same way the ordinary path describes them, and for the same reason: a reply written from a thinner picture is a reply from a different bot. That means their display name and roles, their relationship stats and mood numbers, their recent messages to the bot, and a coarse impression of how long they have been around, all as covered above.

Reading that changes nothing. An overheard message never counts as one aimed at the bot, so it moves no mood and enters no conversation memory, and Lab room chatter is never stored there. Everything sent for a Lab reply is used for that one reply and never kept.

Inside the Lab the bot may also delete a message or briefly revoke Send Messages in that channel only, including when a member triggers it on themselves via the pinned button. Neither creates a warning, a strike, or a moderation record. Lab messages are indexed like any other and still count toward the all-time totals on the staff Activity page after the channel is deleted.

6. How We Protect Information

We take reasonable steps to protect what the bot stores. No system is perfectly secure, so we cannot promise absolute safety.

7. Adults Only

MediaBot is built for 18+ (NSFW) Discord servers, and you must be at least 18 to use it. We do not knowingly collect personal information from anyone under 18. If we learn that someone under 18 has used the bot, an operator reviews the user-linked records described here and deletes or de-identifies them where reasonably possible. A limited moderation, appeal, security, or legal record may be kept while it is still needed for that purpose.

8. Your Choices

• Remove the bot, or turn a feature off. An admin can do either at any time, and the stored setup goes with it. An admin can also ask us to delete that server's configuration and related records.
• Interest roles are ordinary Discord roles you can change or clear in the picker whenever you like. One nobody holds is deleted shortly after.
• Your attachment posts. Anyone with a valid Discord sign-in can open /me, including former members, non-members, and banned users, browse their indexed attachment posts by channel and filename, and delete one post, one channel's worth, or all of them after a fresh sign-in. A live preview is fetched from Discord at that moment and never downloaded or stored.
• Ticket threads are excluded from that self-service deletion and from the bot's mass cleanup, because they can hold evidence for open investigations.
• Everything else. That is the only user-initiated data control the bot offers. It does not provide data export, correction, or complete account erasure, and other records expire on the schedules above. Your account, profile, and message history belong to your Discord account and are managed through Discord itself.

Questions about this Policy, or about these tools, can go to a current server Administrator on Discord.

9. Changes to This Policy

We may update this policy and will revise the "Last Updated" date at the top when we do. Continuing to use the bot after a change means you accept the updated policy.