Privacy

Privacy policy

Last changed 19 October 2026.

What is stored

Server configuration you set through the bot’s commands: channel and role IDs, thresholds, toggles, and the text you type into a setting — a command prefix, a list of blocked words, a verification panel’s text, the phrase that triggers a scheduled channel wipe, the user IDs you exempt from a filter. Moderation records: the case number, who acted, who it was against, the reason you typed, and when. Where a feature needs it, the IDs of messages or channels it created so it can manage them later.

Configuration text is stored as you wrote it, deliberately: your moderators have to be able to read back what the server is set to do. It is not somebody’s private words about themselves — it is the rules of your server, written by whoever runs it.

Activity counts, from the moment the bot is added. How many messages each member has sent, how many minutes they have spent in voice, how busy each channel is, an hourly total for the server, and a record of who joined or left and which invite brought them. If the webhook relay is on, how many times it has posted a member’s blocked messages back, and when it last did. These are counters and timestamps and nothing else: there is no row anywhere saying what anybody said, or in which channel, or at what moment. The per-day breakdown the leaderboards are summed from is deleted after 120 days, and the join and leave history after 400 days.

Counting is on from the moment the bot arrives, unlike most of what it can do, because a history that begins whenever somebody remembers to find a setting is a history nobody can trust, and a month not counted cannot be recovered. Turning it off takes one line — /logs activity with off — counting stops immediately, and /stats goes on showing what was recorded before you did.

It is not the only thing switched on when the bot joins, and this page used to say it was. Text commands, the moderation log, the punishment ladder, giveaways, snipe, AFK and the bot’s language setting start on too; the docs page lists them beside every other module and marks which is which. Of those, snipe and AFK hold something about a member: snipe in memory rather than in the database, and AFK only once a member sets it themselves — the paragraph below is exact about what and for how long.

AFK, only if a member sets it. That they are away, the reason they typed, when they went, the nickname the bot replaced so it can put it back, and links to up to ten messages that mentioned them while they were away — which message, in which channel, by whom, and when, never the message’s text. All of it is deleted the next time they talk somewhere that counts (a server can list channels that do not), when they leave the server, or with /afk remove — and after thirty days whatever happens. A server can turn off keeping the mentions.

What the bot made of an account when it walked in. If member screening is on, the score it gave, the band, the signals that fired, whatever the bot did on its own, and what a moderator decided afterwards. It is kept so that “why was I kicked” has an answer that is not a reconstruction, and because “has this account joined and left here before” is a signal that needs a history to exist. Deleted after 90 days — a judgement about somebody is not the same thing as the moderation action it led to, and only the second one is a record.

What people submit to a feature, and what the feature made of it. Ban appeals and the staff vote on them; staff applications, their answers and their vote; tickets, their answers and the rating left when one closes; giveaway entries; event sign-ups and attendance; guild ranks, rosters, staff notes and contribution reasons; reviews somebody wrote about your server; partner applications and their pitch. The four fields in that list that are words written in confidence are encrypted — the section below names them exactly.

Server backups, if somebody takes one. /backup save stores a structural snapshot of the server so it can be rebuilt: role names and permissions, channel names, topics and overwrites, categories, emoji and sticker metadata, and the ban list with the reasons written on it. It holds no messages. It is your server’s own structure, kept where you told the bot to keep it, and /backup delete removes a slot outright.

Messages your staff build with /message. An unfinished draft (dropped after a week untouched), saved templates, posts scheduled for later, and a record of each post so it can be edited — forgotten after 90 days without an edit. This is text your staff wrote for the bot to send, with who wrote it; nothing a member said.

Your server’s greetings. The welcome message, goodbye message and welcome DM your staff built, the text on the welcome and goodbye cards, and a background picture if one was uploaded for a card — stored as a picture the bot redrew from the upload, so nothing of the original file is kept but its pixels. To draw a card, the bot fetches the joining or leaving member’s profile picture from Discord at that moment and keeps nothing of it.

Levels, if a server turns them on. With the Levels module on, the bot keeps one number per member — the XP they have earned from messages and time in voice — and when it last changed, and nothing else: no record of what was said, or where. A level and a rank are worked out from that number. It stays while the bot is in the server, even after a member leaves, so their reward roles can come back if they return; it is deleted with the rest of the server’s data thirty days after the bot is removed. If the server leaves its public leaderboard on — it is on by default, and one switch turns it off — that member’s server name, profile picture, level and XP are shown on a public page on this site to anyone with the link. The name and picture are taken from Discord when the page is drawn and are never written to the database; the drawn page is kept for under a minute so a busy board does not reach the bot on every view.

Raid replays, only when anti-raid catches a raid or staff mark a window. Which accounts joined during it and when, how old each account was, whether it had an avatar, a letters-only key made from its username to spot a batch of similar names (never the username itself), what the bot or a moderator did about each one (kick, ban, timeout), whether the server was locked, and how many messages were removed. Never a message’s text. Kept for 30 days, 25 raids per server at most, and deleted with everything else when the bot leaves a server.

Suggestions, if a server turns them on. A suggestion keeps what was typed, who sent it, where its card was posted and — once staff answer it — the answer, who gave it and why. Each vote is one row: which suggestion, which member, which way. An anonymous suggestion still records who sent it, because the per-member limit and the cooldown are counted from it, and it is shown nowhere. All of it is deleted with the rest of the server’s data thirty days after the bot is removed. A suggestion sent with /suggest bot is about the bot rather than about a server: it is passed to a channel in the support server with your name, your ID and the server it came from, and is not stored at all.

Birthdays, if a member sets one. /birthday stores nothing about a person until they give a date. Then it keeps the day and month they gave; the year, only if they gave one, encrypted with the same key as the confidential text below and read back only to say an age, and only in a server that shows ages; a time zone from a fixed list; the moment their next birthday starts; and which servers they chose to share it with, one record each, made by the person and by nobody else. A moderator can take a server’s record away and can never set or read a date that was not shared in their server. Nobody under 13 is kept: a year that makes someone younger is refused and nothing is stored. The bot never messages the person. /birthday remove erases the date and every server’s record at once; a server’s record also goes when the member leaves that server or when the server’s data is deleted; and the short record of which celebrations were already announced is deleted after 400 days.

Erasing a birthday with /birthday remove also deletes that person’s record of announced celebrations at once, without waiting for the 400 days.

Temporary roles. When a moderator lends someone a role for a while, the bot keeps who has it, which role, when it ends, who lent it and the reason they typed (at most 400 characters), until the role is taken back. A role lent for a birthday or for breaking a count is kept the same way, with the bot as the lender. The record is deleted when the role is taken back, when the member is banned, and — unless the server chose to keep the time for their return — when they leave.

Counting, if a server sets up a channel. For each counting channel the bot keeps the number it is at, who counted last, the rules that channel plays by and, for each member who has counted there, how many correct numbers they gave and how many times they broke the count — ids and numbers, never what anyone wrote. Messages in a counting channel are read as they arrive to judge them and are not stored. All of it is deleted with the channel, when counting is stopped there, or with the rest of the server’s data thirty days after the bot is removed.

Modmail, only if a server turns it on. When a member sends the bot a direct message, the bot reads it and passes it to the staff of the server they choose, in a private channel that server picked — everyone who can see that channel can read it, and so can whoever can see the server’s log channel if transcripts are posted there. Staff replies are sent to the member’s DMs; an anonymous reply hides the sender from the member, not from the other staff. The bot keeps no message text: it stores ids, counts and times, which DM message matches which message in the channel (deleted thirty days after the thread closes), the reasons staff typed for a close or a block, and the saved replies a server’s staff wrote. A closed thread’s record is deleted after the number of days the server set, ninety by default. The conversation itself and any transcript file stay in that server’s Discord, under that server’s own rules. A member ends a conversation with Close this conversation under the bot’s first reply, stops a server starting one with Stop messages from this server, or simply doesn’t write to the bot. No third party receives any of it.

The template store. If you rate a template, the bot keeps your account id, the stars and when. If you comment, it keeps your account id, the display name you had at the time, the text and when; you can delete your comment yourself, and the owner can remove it. A report keeps your account id and the reason you typed. So that only people who have used a template can rate it, the bot keeps which template you applied, to which server id and when, for as long as the template exists. The owner reads every submitted template before it is listed, and a comment waiting for review before it appears; a comment nobody has decided on is deleted after 30 days. To keep a limit on how often one account or one address can comment, report or rate, the bot keeps a keyed hash of the address — never the address itself — with the account id and the time, deleted after 30 days. A template you are still writing is kept sealed (encrypted) for 7 days. To have everything the store holds about your account removed, ask in the support server and the owner runs the removal. The text of a comment — and only the text, with no account, no name and no template attached — is sent to OpenAI’s moderation endpoint before the comment is posted, on the terms described under OpenAI above; a comment it flags, or that it does not answer in time, is held for the owner instead of being posted. Where the bot has no OpenAI key, that step is skipped and the other checks stand alone.

What is never stored

Message content. Nothing in the database retains what people say in your channels, and there is no exception to that — not one column in the database holds a message somebody posted. This page used to name ticket transcripts as an exception and they are not: a transcript is built from the history Discord itself holds, at the moment a moderator asks for it, and posted back into your server as a file. Nothing of it is kept here. Text somebody deliberately submits to the bot — a ban appeal, an application, the form when a ticket is opened, the comment left with a rating — is kept, because a review that cannot be read is not a review; it is encrypted, and the section below says exactly which fields. So is the reason a member gives with /afk, until they return — not encrypted, because it is not written in confidence: it is shown to anyone who mentions them.

Two things are held outside the database, and both are worth being exact about. The first is snipe: /snipe shows the last message deleted or edited in a channel, so it has to hold one: five per channel, for two hours at most, in memory. Nothing is written down, a restart forgets all of it, and it never leaves the process. Anybody who can read the channel can ask for it — that is what the command is for — and the bot checks that access at the moment it answers rather than when the message was removed. It will not show a message the bot itself deleted, or anything cleared in bulk, because a snipe must not become a way to read back moderation. A server that wants it narrower restricts it to moderators, or excludes channels outright, with /logs snipe; a moderator who has just removed something clears it immediately with /snipe clear.

The second is the protections’ counters. Anti-nuke, anti-raid, anti-spam and the others decide by counting — how many channels one moderator deleted in the last minute, how many accounts joined in the last thirty seconds — and those counts are copied to a Redis cache on the same machine every few seconds, so that restarting the bot does not hand somebody partway through an attack a fresh allowance. What is copied is the ids — of the server, and of the member or channel involved — and the times things happened, never what anybody said: anti-spam’s memory of recent messages stays in the process and a restart forgets it. Each copy expires on its own — within an hour, most within minutes — the cache never writes to disk, and nothing can reach it but the bot itself — not the website, and not the internet. During an update, when a new copy of the bot takes over from the old one, the ids of the messages and interactions the old copy answered in its last few seconds pass through the same cache, for thirty seconds at most, so that nothing is answered twice. One thing in that cache lasts longer than an hour: which new members are still waiting at a gate — Discord’s rules screen, verification, a quarantine — for the roles the server gives on joining, held as the server’s id, the member’s id and the moment the wait lapses, for a day at most, so that an update does not forget to give them.

IP addresses. The bot never sees one — Discord does not expose a member’s address to a bot, and nothing here works around that. The one place an address is ever read is the website’s connection check, described next, and it is read once and not kept: not stored, not logged, not hashed. A stolen database contains no addresses and nothing derived from one.

Voice messages, if somebody asks for one to be written out. /transcribe fetches that voice message and turns it into text on the bot’s own server, with a speech model that runs there. The audio goes to no other company or service; it is held only while it is listened to and deleted as soon as it is done. The words are posted in the channel where the command was used and kept nowhere else — no record is kept of what was said. To keep one person from tying up the machine, the bot counts in memory how many each person and each server asked for in the last ten minutes; those counts are forgotten afterwards, and a restart forgets them at once.

The five third parties, and what each is given

For most of its life this site could say that no third party ever saw your members. That stopped being true when the verification module gained Refuse VPNs and proxies, because whether an address belongs to a VPN is a fact only a reputation service holds. Every one of the five below is off unless a server turns it on, and when it is on, what follows is the whole of what happens.

proxycheck.io. A member the setting applies to is handed a single-use link to a page on this site. When they press the button on it, the connecting address is sent once to proxycheck.io with the question “is this a VPN, proxy or hosting range” and nothing else — no username, no server, no account id. The answer is read for that one bit and dropped. The bot, which knows who the member is, never receives the address; the website, which saw the address, never learns who the member is. What is left afterwards is a timestamp on the member’s verification record saying the connection was clean, and a refusal leaves nothing at all.

Cloudflare Turnstile. Optionally, that same page carries Cloudflare’s Turnstile widget so a script cannot press the button. The widget’s script is the only thing this site ever loads from another origin, on that page only, and this page’s Content-Security-Policy still forbids it everywhere else. Its answer is checked with Cloudflare without the address attached. Turnstile does not replace the CAPTCHA inside Discord, which is still drawn in process.

OpenAI. This is the largest of the three and the one that is given what people post, so it is worth being exact. A server can switch on AI image scan, which has a model decide whether a picture is sexual, gory, violent or shows self-harm. No keyword list can read a picture, and there is no version of that which runs on our own machines, which is the only reason it is here at all.

When a server has turned it on, each image posted in a scanned channel is sent to OpenAI’s moderation endpoint as the link to that image on Discord’s own servers, and nothing else — no text anybody typed, no username, no account id, no server name, no channel name. That covers uploads and, if the server leaves it on, the picture Discord shows under a link. The answer comes back as a score per category, it is read to decide whether the image breaks that server’s rules, and it is dropped. Nothing from it is written down here, and the image itself is never stored in our database.

What OpenAI does with it, in their words rather than ours. Their documentation states that data sent to the API “is not used to train or improve OpenAI models” unless you explicitly opt in, and we have not. It also states that abuse monitoring logs “may contain certain customer content, such as prompts and responses” and are “retained for up to 30 days” by default. So the honest version is not that the image vanishes the moment it is scanned: we keep none of it, and OpenAI may hold it for up to thirty days to police their own service. A server that is not willing for that to happen should leave this module off, which is how it ships.

It is off until an administrator enables the module. A server can exempt roles, skip whole channels or scan only some, scan only newer members, and skip its own moderators, and the module’s description says plainly that turning it on is what sends images out of the server. Turn the module off and nothing is sent again.

Two honest limits. It is good at general harms and it does not know what a threat to your server looks like — a raid being organised, a scam, an advert — because those are not categories the model has, and it does not read text at all. And OpenAI’s own documentation says the endpoint is not designed for detecting child sexual abuse material and is not a substitute for dedicated child-safety measures; nothing here claims otherwise, and that reporting route remains Discord’s.

Nothing else is loaded. No analytics, no font service, no script or stylesheet from anybody’s CDN: every page other than the connection check fetches nothing from another origin, and that is enforced by the Content-Security-Policy rather than promised. Cloudflare does sit in front of the site as its network — it sees the requests any network in front of a site sees, and it is why the site stays up under a flood — but it is handed nothing about your members, because the pages carry nothing about your members.

YouTube and Twitch. A server can follow a YouTube channel or a Twitch streamer with /alerts, and the bot then asks the service every few minutes whether there is something new. To YouTube it sends one request for the channel’s public RSS feed, which names only that channel’s public id. To Twitch it sends the streamer’s public login name — together with others, up to a hundred to a request — signed with this bot’s own Twitch application, never a member’s account. No member, server name or channel name is sent to either, and neither is told which server follows whom. The answer is read for the newest video, or the live stream’s id, title and game, and dropped. What is kept is the channel or login the server chose to follow, where to post, and the id of the last thing announced so that nothing is announced twice. Both are off until a server adds a follow, and removing the follow stops the requests.

A sponsored line

The people who run this bot may set one sponsored link: a short line marked Sponsored, whose words and destination they choose and whoever it points at pays for. It appears in the footer of this site and, now and then, under one of the bot’s replies in a server without premium: at most once every 45 minutes in any one server, only after at least 6 other replies there, and never under a moderation action, a warning, a private reply or a message with buttons. Premium servers never see it in Discord. The site cannot tell who is reading it, so the footer shows it to every visitor.

It is a link and nothing more. Nothing is loaded from the sponsor and nothing is sent to them. To keep to the rule above, the bot holds in memory — never in the database — when each server last saw the line and how many replies have gone out there since, and a running count of how often it has shown; no person is recorded, and the sponsor sees none of it. The bot records no clicks and runs no redirect, and the link carries no referrer from this site. If you click it you leave for their site, where their own policy applies. The sponsor’s text is shown as they wrote it and is not translated. When no sponsor is set, the line does not exist anywhere.

None of it is kept for long. A server’s record is forgotten 24 hours after its last reply. No more than 20,000 servers are held at once; when that fills, the one unheard from longest is dropped. All of it, the running count included, is gone whenever the bot restarts.

Premium tokens and your account

Premium by account is one row: your Discord id, whether it is monthly or for life, when it runs out, where it came from, and how many extra server switches you have bought. A token is stored only as a keyed hash of itself, so the database holds nothing that can be turned back into a token; the token exists in the owner’s reply when it is minted and nowhere after.

Every attempt to redeem a token is recorded — your id, whether it came from this site or from Discord, how it went, and a keyed hash of the address this site proved for the request, never the address. That record is what locks an account and an address after a handful of wrong tokens, and what lets the people who run the bot see one address behind many accounts. It is deleted after 90 days.

Each server records which account added sick to it, which is what makes the server premium when that account is. The servers you add sick to are also listed against your account — the server’s id and when — so your switches can be counted. That list is kept, and a server stays on it after sick leaves, because a switch spent is spent.

Mail on this domain

The site also carries a small mail service for the people who run it: the owner’s own address and the addresses of the accounts the owner has permitted to use it, each opened from the mail site after signing in here. Mail to one of those addresses arrives through Cloudflare Email Routing and a Cloudflare Email Worker, which hands it to this site; when the site cannot be reached the Worker keeps the message in Cloudflare Workers KV for up to seven days and tries again. Mail sent from one of those addresses leaves through Cloudflare Email Sending. Those are the four Cloudflare services involved, and no other party sees the mail.

Mail is sealed at rest. When a message arrives, this site parses it and seals it to a public key that belongs to the mailbox — AES-256-GCM under a one-time key for that message, which is itself sealed to the mailbox’s X25519 public key — and only then hands it to the bot, whose database keeps the sealed message: its subject, sender, recipients, text, HTML, attachments and their names, and the original bytes, which are kept for seven days so a message a parser misread can be downloaded whole. The private key that opens it is wrapped under a key made from your mail password (scrypt) and, if you make one, under a one-time recovery key; the bot never holds the private key, and stores only a one-way hash of your password. This is zero-access at rest, not zero-knowledge: this site reads your mail in memory while it parses an arriving message and while your mailbox is unlocked, so whoever can change the code this site runs could read it, but the owner cannot read it from the database. Your unlocked key lives only in this site’s memory, for at most a day, and a restart locks every mailbox until you type your password again. Remote images in a message are never fetched by the site: they load in your browser only when you ask, and an image load tells the sender when you opened the message and from where.

When you sign in to this site with Discord, your Discord id, username and avatar hash are recorded with the time, so the owner can see who has signed in before handing out an address. Trash and Spam delete their contents thirty days after a message entered them; a revoked mailbox is deleted fourteen days after the revoke. If you ask the owner for access, the request — the same id, name and avatar hash, and the time — is kept until the owner answers it or thirty days pass, and the owner is told by a direct message from the bot on Discord. Nothing else about mail is shared with Discord.

Sending is counted per recipient, from the outbox rows already kept to send the mail, so nothing new is collected for it. A mailbox whose mail keeps bouncing has its sending held until the owner looks at it. Mail sent to postmaster@ or abuse@ on these domains reaches the owner.

Some things are left in the clear, because the service has to read them without your key: which folder and tab a message is in, its flags (read, starred, important, snoozed), when it arrived, its size, which conversation it belongs to, how many attachments it has, their file types and inline-image ids, which of your addresses it came to, a plus-tag you used, the results of its sender checks, and keyed digests of its identifiers (Message-ID, References) and of its sender. The rules you set for senders — an address or a domain you filed, blocked or allowed images for — are in the clear too. While a message arrives, the bot reads its sender, recipients, subject, headers and attachment names in memory to file it into a tab and to apply the abuse rules, and writes none of them down in the clear. Mailboxes whose holder has not yet signed in with a password since sealing began keep their older mail as it was, readable by the service; the owner is shown which, and each is sealed as soon as its holder signs in.

Search works on keyed digests, not on your words. When your mailbox is unlocked, each sealed message gets up to 512 digests (HMAC-SHA256) of the whole words in it and of its sender and recipients, made under a random search key that exists only wrapped under your password and your recovery key. So a search can find whole words and exact addresses — not prefixes, word forms or phrases — and someone holding a copy of the database cannot test a guessed word against them. Two costs: mail that arrives while your mailbox is locked cannot be searched until you next unlock it; and the keyed digests of identifiers and senders that are left in the clear (above) are made under a secret the site holds and the database does not, so someone holding both could test whether a guessed address or Message-ID appears.

A message you send with Undo or at a later time waits in the outbox in the form the sender needs: because it has to be readable when it goes out, it is kept under the bot’s own server key until it is sent, cancelled or refused for good, and then deleted. The copy in your Sent folder stays sealed to you. Mail you send leaves over TLS like any other mail, through Cloudflare Email Sending, and mail to you arrives through Cloudflare Email Routing: Cloudflare sees the message in transit, before this site seals it and as it leaves.

Messages you send carry no Discord id, account id or address of your browser: a random Message-ID at the sending domain, no X-Mailer, User-Agent or X-Originating-IP header, and a From line that shows only the address you chose, with a display name only if you set one. An alias is a further address that delivers to your mailbox and that you can switch off, set to expire, or let answer once. This is not anonymity from the people who run the service, from Cloudflare, or from the person you write to: they see the address you wrote from, the time and what the message says.

If you lose both your password and your recovery key, your mail cannot be opened, and nobody can recover it for you, the owner included. When the owner resets a holder’s mail password, the key it opened is deleted too: the mail sealed under it can never be read again, and is deleted thirty days later.

Music and lyrics

When a server turns the music player on, the bot plays audio in a voice channel through a Lavalink node that runs beside it on the same machine. The node fetches the audio from the site a member asked for and nothing else: SoundCloud (soundcloud.com, on.soundcloud.com, api.soundcloud.com, sndcdn.com), Bandcamp (bandcamp.com), Twitch (twitch.tv), Vimeo (vimeo.com), a direct https link a member pasted, and — only if the owner has switched it on — YouTube (youtube.com, youtu.be, music.youtube.com). A Spotify link (open.spotify.com, spotify.link) or an Apple Music link (music.apple.com) is looked up on that site for the track’s name and the match is played from SoundCloud; no audio comes from either. Each of those sites sees the request the node makes for the track, as any browser opening the page would, and nothing about the server or the member who asked.

What the bot stores for the player: the voice and text channel it is in, the queue — each track’s title, artist, length, source and the node’s own handle for it, and the id of the member who queued it — and the last twenty tracks it played, which go when the player stops or the bot leaves the server. A playlist a member saves is theirs, kept under their id until they delete it. Lyrics come from LRCLIB (lrclib.net), an open database with no account: it is sent the artist, the title and the length of the playing track and nothing else, and the answer is shown and not kept.

Your account’s security

Your mailbox opens with your own password, set in the mail client itself and kept separate from Discord. This site sees it only while you type it, to unwrap your mailbox’s key, and does not keep it; the bot, which receives it to check it, stores only a one-way scrypt hash of it — a value nothing can turn back into the password, not even us — and checks what you type against that. The password itself is in no log, no database column and no cookie.

A second step is optional and yours to add. An authenticator app’s secret and the address a code is mailed to are encrypted at rest with AES-256-GCM, by the same bot-only key as the confidential text above; a passkey is stored as its public key alone, which can verify a sign-in but never produce one; recovery codes are kept only as keyed hashes, like the premium tokens. A mailed code goes out through Cloudflare Email Sending from an address on a domain of ours. No second-factor method is shared with anyone.

Trusting a browser for thirty days stores a random token in a cookie and, on the bot’s side, only a keyed hash of that token — never the token itself — so the list of your trusted browsers holds nothing that identifies the browser to anyone else. Beside the dashboard’s three sign-in cookies, the mailbox sets a few of its own while it is open: the one that keeps it unlocked for a day, one that holds a login or a password while its second step is answered, one that lives ten minutes and marks the browser that started a mail sign-in so it cannot be finished from another, the trusted-browser token, and one that lasts thirty days and remembers you closed the second-step reminder. A mail session ends six hours after it opens, or sooner if you sign out of the site on a shared host. Every wrong password or code is counted against your account and against the address this site proved — your id and a keyed hash of that address, never the address itself — which locks the account after a handful of tries within a quarter of an hour; those records are deleted within a day.

Listening — only if you link something

What is stored. /fm stores nothing about a person until they link a source. If you link Last.fm or ListenBrainz we store your username there. If you also turn on scrobbling out, we store the key that lets the bot send plays for you, encrypted, only while that is on — turning it off, or unlinking, deletes it. If you use Discord’s Spotify status, the bot reads the Spotify song in your status, in servers it shares with you, only after you agree, and records a play when you have heard about half of it. Nothing else in your presence is read.

What is kept, and who sees it. The plays the bot heard itself — from your Spotify status or its own music player — are kept for a year. Your top artists, albums, tracks and genres, up to a thousand of each, are copied from your service every few hours so a server can show who listens to what. Friends, a few display settings and the servers you chose to hide yourself in are stored too. Plays and lists are shown only to people in servers you are in; your Last.fm or ListenBrainz username appears in a global who-knows only if you turned that on, and it is off until you do. /fm account shows all of it and deletes all of it at once, and unlinking your last source does the same.

Last.fm and ListenBrainz. When someone uses /fm, the bot asks Last.fm (ws.audioscrobbler.com) or ListenBrainz (api.listenbrainz.org) for the linked person’s public listening data, using their username and nothing else about them. Only if scrobbling out is on, the bot also sends the plays it heard for that person to the service, signed with their key. Album covers are fetched from Last.fm’s image servers by the bot, never by your device. Each service has its own privacy policy, and what it holds about your listening was already yours there.

Linking Last.fm happens on Last.fm’s own page: the bot asks Last.fm for a one-time token and hands you the address where you approve it, then learns you did by asking Last.fm. The token lives only in the bot’s memory until it is used or an hour has passed, and is never stored or logged. Typing just your Last.fm username links without approving anything and sends Last.fm that name and nothing else. Linking Discord’s Spotify status needs the bot’s Presence intent; until that is switched on, only the other two are offered.

Importing history. If you give /fm import a Spotify or Apple Music file, the bot reads it once and keeps only each play’s time, artist, track and album. The file itself is held in a temporary file for the minutes the import runs and deleted straight after; nothing is sent to anyone. Imported plays are kept until you remove them (/fm account has a button) or delete everything, and are shown like any other plays: only to people in servers you are in.

Crown history. When a server’s crowns or a who-knows board are read, the bot notes who holds each artist’s crown there and, when it changes hands, who took it from whom and when — kept for up to a year. Deleting your listening data removes the crowns you held and forgets whom you took one from.

Encryption

Free text people write in confidence is encrypted with AES-256-GCM before it is stored, and decrypted only as it is shown to the staff it was written for. That is five things: ban appeals, staff application answers, the answers given when opening a ticket, the comment left with a ticket rating, and the year somebody gives with their birthday. The key is derived from a secret that exists only in the bot’s own environment — the website runs as a separate service that does not have it and could not use it — so a copy of the database on its own yields ciphertext.

It said three until 19 September 2026, and the fourth was the reason: the comment left with a ticket rating — “the moderator who closed this was short with me” is the kind of thing written in it — was stored as plain text from the day the feature shipped. It sat two declarations below the ticket answers that were encrypted, in the same file, and nothing held the two against each other. It is encrypted now, everything already stored was converted, and a check in the build refuses any new field of that shape until somebody has written down which of the two it is.

Half-finished applications. A long application form is asked in pages. The answers to the pages already sent are kept, encrypted in the same way, until the last page is sent — when they become the application — or for an hour, whichever comes first, and the applicant can discard them at any time. Nothing is kept for someone who never starts.

What is not encrypted, said plainly: the question a staff member wrote beside each answer, moderator-typed reasons on a moderation record, the reason a member gives for being AFK — which the bot shows to anyone who mentions them — and your server’s settings. None of those are somebody’s private words about themselves, and encrypting them would cost your moderators the ability to search their own records.

Deletion

Remove the bot from your server and everything held for that server is deleted thirty days later, automatically, with no request needed.

The delay is the feature, not the catch. By far the commonest reason a server removes the bot is to add it straight back with different permissions, and a deletion that fired the instant it left would take every setting, every warning and every moderation record with it. Re-invite inside the window and your server is exactly as you left it; pass the window and there is nothing to come back to. Nothing new is recorded while the bot is gone — it cannot see the server — and the clock restarts from the last departure, so leaving twice does not shorten it.

If thirty days is too long, a server owner or administrator can have it done immediately: ask in the support server. That happens on request rather than on a schedule.

Signing in to the dashboard

This site is sykbot.com, and the docs at sickenn.info. Signing in happens on sicken.me and nowhere else, and the cookies below belong to it alone — a browser never sends them to any other address. A page anywhere else that asks you to sign in with Discord for sick is not this site. Mail is read and written at mail.sicken.me. It has no sign-in of its own: it sends you to sicken.me to sign in and brings you back, and its cookies belong to it alone.

The website has no database, so a login is kept in one cookie in your browser. Signing in asks Discord for two scopes, identify and guilds — your name and the list of servers you are in, nothing else — and the cookie holds what comes back: your Discord id, username and the id of your profile picture, and the access and refresh tokens for those two scopes. It is encrypted and authenticated with AES-256-GCM under a key only the website holds, so it cannot be read or altered in your browser, and nothing about it is written down on the server. It also remembers up to four servers you opened recently, so they come first on the list.

Your profile picture and your servers’ icons are fetched by this site from Discord and handed to your browser, so your browser never contacts Discord’s image servers and they never see your address. This site keeps none of them: each is fetched when a page asks for it, and your browser and the network in front of this site may hold a copy for up to a week, under an address that changes whenever the picture does.

While a feature’s settings page is open and on screen, it asks this site — never anybody else — for your server’s channel and role lists again once a minute, so a channel made a moment ago is there to pick without reloading. That request carries the same cookie and is answered only to somebody who could open the page; it is the one thing any page here fetches after it has loaded, and the Content-Security-Policy permits it on those pages alone.

It lasts thirty days from when you sign in, which is what lets somebody come back without connecting Discord again; after that the browser is sent through Discord without the consent screen, for an app you already approved. A month is only safe because Discord stays in charge of it: every few minutes the site asks Discord whether the login still stands, logging out revokes the tokens at Discord — so a copy of the cookie stops working as well — and removing sick under Authorized Apps in Discord’s own settings ends it from your side, on every device at once.

A second cookie holds only the digit 1, and exists only after you log out. It records that you did, so the next login shows Discord’s consent screen — with Discord’s own “Not you?” on it, which is how you switch account — instead of skipping it. Signing in again removes it. A third lives for ten minutes while a login is under way and holds a random value that proves the answer coming back from Discord belongs to the login this browser started. Those three are the only cookies the dashboard’s sign-in sets; your mailbox sets a few more while it is open, named under Your account’s security above. Cloudflare, which sits in front of it, may set its own short-lived __cf_bm cookie to tell browsers from bots; that one is Cloudflare’s, and nothing here reads it.

Who can see what

Configuration is visible to people who can change it — by default that means Manage Server, and more for the few features that ask for Administrator. Moderation records are visible to your moderators. Nobody operating the bot reads your server’s data as a matter of course, and there is no interface that would make it convenient to.