Gokurakugai

This Privacy Policy explains what happens to your information across the whole Gokurakugai fan ecosystem: the website at gokurakugai.wiki, our Discord server, the Tao Discord bot that runs it, and Tao's Modmail feature (the DM-based way of contacting staff).

These systems are related but not identical, and this policy is written to explain each one honestly rather than lump them together as "our services." Where the website, Discord, and Tao overlap — for example, an appeal that starts on the website and is posted into Discord by Tao — we explain the handoff.

Before using any of these, you should understand: Discord itself is a separate platform with its own account, its own data practices, and its own Terms and Privacy Policy (see §32). We do not control Discord's infrastructure — we build features on top of it. This policy covers what we — the fan-run team, our website, and our bot's own code and databases — do with information, not what Discord does on its own platform.

This document was written by directly reviewing the source code of the website and the Tao bot, rather than from a generic template. Where the code doesn't specify something precisely (for example, an exact retention period), we say so instead of guessing.

Gokurakugai Fan Community ("we", "us", "our") operates the website at https://gokurakugai.wiki, the Gokurakugai Discord server, and the Tao Discord bot that supports it. This is an unofficial, fan-made project and is not affiliated with Yuto Sano, Shueisha, or Jump SQ.

We are a small, volunteer-run staff team. You can reach us about anything in this policy through our Discord server at discord.gg/gokurakugai, including via Modmail (see §5–§6).

Different parts of the ecosystem can see different things. Broken down by system, not just "personal information":

Website

• Discord identity (via OAuth) — when you log in on the website (theory submissions, appeals, the staff dashboard), we receive your Discord user ID, username, global display name, and avatar hash directly from Discord's API, using a token your browser obtained from Discord.
• Guild membership & roles — for appeals and dashboard access, the site's backend queries the Discord API (using the bot's credentials) for your server membership, roles, timeout status, and ban status.
• Form content — text you type into the theory-submission modal, staff-application form, or appeal questionnaire.
• Standard web request data — our host, Cloudflare, necessarily processes IP addresses and request metadata to serve the site and route API calls; see §28.

Discord Server / Tao Bot

• Message content — Tao is granted Discord's Message Content privileged intent. This is used for specific features (Modmail relay, moderation filters, sticky messages, embed tools, starboard, link-embed fixing) described in §7 — not general surveillance of every channel.
• Member data — user IDs, usernames, display names/nicknames, avatars, join dates, roles, and presence/voice-state information available through Discord's gateway (see §8).
• Direct messages — Tao has the Direct Messages intent, used specifically for Modmail conversations and DM notifications (ticket confirmations, appeal-adjacent notices, staff-application replies).
• Moderation events — bans, timeouts, and audit-log entries relevant to anti-raid/anti-nuke protection.

Tao's persistent storage is a Firebase Firestore database, plus a small number of flat JSON/config files on the bot's own server for per-guild settings and caches. The website reads and writes some of the same Firestore project. Broken down by how the data is handled:

How information is handled

Category	What it means here
Actively stored	Written to Firestore or a config file and persists until deleted — e.g. modmail ticket records, ban lists, fan-theory submissions, server configuration.
Accessed but not stored	Read from Discord's API for a single action and not saved anywhere by us — e.g. checking your current roles or ban status to process an appeal.
Cached / in-memory	Held temporarily in the bot's or worker's memory (not a database) and lost on restart — e.g. the appeal rate-limit counter and duplicate-submission guard described in §13.
Provided voluntarily	Text you choose to type into a modal or form — theory submissions, application answers, appeal answers, Modmail messages.

Message content sent through ordinary Discord channels (not Modmail, not a form) is not separately copied into our database by Tao — it stays in Discord as a normal Discord message, subject to Discord's own retention. Where Tao does read message content for a specific feature (§7), we say whether that content is stored or only processed in passing.

When you open a Modmail ticket (DMing Tao or using the ticket form), Tao creates a Firestore record for that ticket containing:

• Ticket ID and a sequential ticket number
• Discord thread ID of the private staff-side forum post created for the ticket
• Your Discord user ID
• Status (open/closed) and category you selected
• Subject line you provided
• Creation timestamp

The ticket record itself does not include your username, the full message body, or attachments — those live in the Discord thread messages themselves (see §6), not as separate database fields. Separately, if a ticket is locked by staff, a small lock record (ticket ID, staff name, timestamp) exists while the lock is active and is deleted when the lock is lifted.

Only members of our Support Team role (or those with the Manage Messages permission) can see the staff-side forum thread where ticket conversations happen.

Modmail works by relaying messages between your DMs with Tao and a private forum thread visible to staff. Based on the code:

• Message text is relayed live between your DMs and the staff thread and lives as ordinary Discord messages in that thread — it is not additionally copied into Firestore.
• Attachments are never re-uploaded, re-hosted, or copied to our own storage. Tao reads the Discord CDN URL Discord already generated for your uploaded file and reposts that URL (rendered as an inline gallery) in the staff thread. The file itself stays on Discord's CDN.
• Staff replies are relayed back to your DMs the same way, with the same handling for any attachments staff include.
• Because Modmail conversations are ordinary Discord thread messages, staff members with access to that private forum channel can view the full conversation and any linked attachments, and Tao does not automatically scan, analyze, or forward attachment contents to any external service.

Retention of the thread and its messages follows Discord's own message retention within that channel — see §23.

Tao runs with Discord's Message Content privileged gateway intent, which lets it read the text of messages in channels it has access to (not just its own commands). This intent is enabled to support specific features, not blanket message logging:

• Modmail — reads your DM content to relay it into your ticket thread (§6).
• Language filter — scans guild messages to detect non-English text. Messages flagged as a genuine non-English phrase are sent to Google Cloud Translate for detection/translation so the bot can post an English translation; this content is processed for that single reply and is not separately stored by Tao afterward.
• Anti-spam & honeypot — inspects message frequency/content patterns to detect spam or raid behavior, and treats any human message sent in a designated trap channel as groundsfor an automatic ban.
• Sticky messages, embed tools, starboard, social-link embed fixing (sns-embed) — read message content or links to repost/pin/reformat them as designed by server staff (e.g. re-embedding a TikTok/Twitter link so it previews correctly).
• Tenor/GIF filtering — inspects GIF/embed content attached to messages against moderation rules.

Outside of these specific features, Tao does not read, log, or forward the content of ordinary messages elsewhere. The one external destination for message text is Google's Translate API, used only for the language-filter feature described above (see §29).

Tao runs with the Guild Members and Guild Presences intents, plus voice-state and moderation intents. This means Tao can access, at the Discord API level:

• User IDs, usernames, global display names, and per-server nicknames
• Avatar and banner hashes (used to build CDN image URLs — not the images themselves)
• Server roles and permissions
• Join dates and server membership status
• Online/idle/offline presence status
• Voice channel state (for the music feature, §19)

Most of this is used transiently — to check permissions, render a welcome message, or verify identity for an appeal — and is not separately stored. What Tao does persist about members is limited to what's described elsewhere in this policy: modmail tickets, bans, blacklist entries, theory/application submissions, and booster-role records (a Discord Nitro booster's chosen custom role name/color, tied to their user ID, for as long as they keep boosting).

Our "notification list" is a self-assignable Discord role menu, not a separate mailing list. Tao stores the configuration of that menu (which roles are offered, their emoji/labels/icons, and where the menu is posted) in Firestore. It does not maintain its own list of who has opted in — that is simply your Discord server role, and Discord itself is the system of record for who holds which role. Any member with permission can see the role list on Discord's member list; staff can see and manage the menu's configuration.

You can add or remove yourself from a notification role at any time via the role menu; doing so is instant and reversible through Discord's own role system.

This is a security feature, separate from the Modmail ban list in §12. Tao maintains an anti-nuke "blacklist" of Discord user/account IDs associated with known raid, nuke, or server-attack activity, built from a seed list plus any custom entries added by our own staff.

• What's recorded: the flagged ID, a confidence tier (confirmed / associated / affiliate / flagged / reference), a short label, a source note, who added it, and when.
• Why someone is added: credible evidence tying the account to a raid/nuke incident, either from the original seed report or added manually by staff after an incident.
• Who can access it: server staff with anti-nuke configuration permissions; enforcement is entirely opt-in per server and off by default.
• How it's used: if enabled, matching accounts can be automatically flagged, kicked, or banned on join, depending on server configuration.
• Removability: entries can be removed per-server by staff at any time (a seed entry can be locally suppressed; a custom entry can be deleted outright). There is no built-in end-user "request removal" flow in the code; removal requests should go through §33 Contact.

Separately from §11, Tao maintains a Modmail-specific ban list for users who have abused the Modmail system (e.g. spam tickets, harassment of staff). A record consists of your user ID, the reason given, the staff member who issued it, and a timestamp. A Modmail ban only blocks you from opening new Modmail tickets — it does not affect your ability to use the Discord server otherwise, and is unrelated to §11's anti-nuke list. Staff can remove a Modmail ban at any time, which deletes the record entirely.

Appeals are submitted through the website's appeal form and are handled by our Cloudflare Worker backend, not stored in a database of appeal answers:

• You log in with Discord OAuth so we can verify the appeal is genuinely from your account (we forward your token to Discord's API to confirm your identity — we never see your Discord password).
• The worker checks, via the bot's Discord credentials, whether you actually have an active ban or timeout/mute — appeals can't be submitted otherwise.
• It also checks a small appeal block list (Firestore collection appealBlocks, mirrored from the bot) of users staff have barred from appealing, along with a reason and who applied it.
• Your appeal answers, Discord tag, user ID, avatar, current roles, ban reason (if Discord has one on file), and timeout/join dates are compiled into a single embed and posted directly to a private staff channel in Discord — this is the only place your appeal answers end up. They are not written to Firestore or any other database by the appeal endpoint.
• A short-lived, in-memory rate limiter (max 3 attempts per 10 minutes per user) and a duplicate-submission guard exist purely to prevent spam; both live only in the worker's memory and reset whenever the worker restarts — they are not a persistent record of your appeal attempts.

Because the appeal itself lives as a Discord message, its retention follows that channel's Discord message history (see §23) rather than a database retention period.

Staff-application submissions are written to a Firestore applications collection by the website, then picked up by Tao and posted as a forum thread in a private staff channel with role/status tags. Records include your application answers, and staff can Accept, mark Under Review, Reject, or message you (a "Contact Applicant" action that DMs you and relays your DM reply back into the thread). Application status and thread linkage are updated on the same record as decisions are made. Applications can be deleted by staff, which removes the underlying record.

The /submit-theory command and the website's theory form both write to a Firestore theories collection, storing: your title, category tag, referenced chapters, theory body text, your Discord user ID, username, display name, avatar hash, submission source (Discord or website), a status (pending/approved/rejected/deleted), and a timestamp. Approved theories may be posted publicly (Discord and/or the site); rejected or deleted ones are marked accordingly and can be permanently deleted by staff. You can view your own submission history and status via the /theory-status command, and you're DMed automatically when a submission's status changes.

Tao stores per-server (per-guild) configuration in Firestore and local config files, needed purely to run its features. This includes, depending on which features a server enables: guild ID, relevant channel and role IDs (welcome, sticky, rolemenu, modmail forum, log channels), moderation and anti-nuke settings, the notification role-menu layout, sticky-message content, booster-role and starboard settings, and similar operational settings. None of this is about individual members beyond the role/channel IDs needed to run the feature that server's staff configured.

The website has no separate account system — there are no site-specific passwords or emails. Login is exclusively "Sign in with Discord" (OAuth), and the resulting access token is stored in your browser's localStorage, not in a server-side session or cookie. Logging out (or clearing the token) simply removes it from your browser; it does not revoke anything on Discord's side beyond what Discord's own token expiry handles.

The staff dashboard checks your Discord identity against a Firestore admins collection (kept in sync with a specific Discord role) to decide whether to show staff-only tools. Regular visitors never touch this collection.

The staff dashboard reads an aggregate analytics collection (totals, per-day counts, per-page counts, referrer sources) to show usage trends to staff. Based on the code we reviewed, these are aggregate counters, not a per-visitor log tied to your Discord identity or IP address — we did not find code that attaches a personal identifier to an individual pageview record. We do not run Google Analytics or a similar third-party visitor-tracking script on the site.

Tao's music commands (play, queue, lyrics, etc.) send your search query and, necessarily, the voice channel you're in to third-party services in order to work:

• Lavalink audio nodes (third-party audio-streaming relays) — receive the track/search request to locate and stream audio into your voice channel.
• Spotify (via the Kazagumo/Spotify plugin) — used to resolve Spotify links/metadata for playback.
• A lyrics lookup API — receives the song title you request lyrics for.
• Last.fm (where configured) — used for music similarity/recommendation features.

These requests are made per-command and are not stored by Tao beyond normal in-session queue state (cleared when playback ends).

The website uses Google AdSense to display ads and help cover hosting costs. AdSense may use cookies and similar technologies to serve ads based on your visits to this and other sites. You can opt out of personalized advertising via Google Ads Settings, and read more at policies.google.com/technologies/partner-sites.

What's stored in your browser

Item	Purpose
Theme preference	your dark/light mode choice, kept in localStorage and never sent to us.
Discord OAuth token	kept in localStorage after login so you stay signed in across visits (§17); never sent anywhere except back to Discord/our own API to verify identity.
Cached Discord user/member info	a local copy of your username/roles fetched at login, used to avoid refetching on every page load.
Per-appeal submission flag	a local marker so the appeal form knows you've already submitted once this browser/session.
Staff "last seen notifications" marker	per-staff-member, used only inside the dashboard to track unread items.
Advertising cookies	set by Google AdSense — §20.

You can clear any of this at any time via your browser's site data/storage settings. Clearing your OAuth token simply logs you out; it does not delete any server-side record described elsewhere in this policy.

• Providing the feature you used — Modmail, applications, theories, appeals, music, moderation, and so on only function by processing the data described for that feature above.
• Moderation & safety — the blacklist, Modmail ban list, appeal block list, honeypot, and anti-spam/language filters exist to keep the server usable and reduce raids/spam/abuse.
• Communicating with you — DM confirmations and status updates for tickets, applications, and theories.
• Operating and configuring the server — server configuration data lets staff run features the way they've set them up.
• Troubleshooting & reliability — console/error logs during operation (see §28) to diagnose bugs.
• Advertising revenue — AdSense, to help offset hosting costs.

We do not use your information for purposes beyond what's described in this policy, and we do not sell your data.

Being transparent about what we can and can't confirm from the code:

• Modmail tickets, applications, theories: retained in Firestore indefinitely until staff deletes them; the code contains delete operations for staff to use (e.g. removing an application's records) but no automatic expiry job. We do not have a fixed retention period to disclose.
• Modmail bans, appeal blocks, anti-nuke blacklist entries: retained until manually removed by staff — these are meant to persist as long as they're relevant to server safety.
• Modmail thread messages, appeal embeds, application threads: these are Discord messages, so their retention follows however long our staff keep that Discord channel's history — we do not separately purge them on our own schedule.
• Appeal rate-limit/duplicate-guard data: in-memory only; cleared automatically whenever the website's backend worker restarts (which happens routinely).
• OAuth tokens, theme preference, cached profile data: stay in your browser until you clear them or they expire; we hold none of this server-side.

Where information is no longer necessary for the purpose it was collected for and isn't needed for moderation, security, or legal reasons, we aim to remove it on request (§25) even absent an automatic schedule.

You can ask us, via Discord (§33), what information we hold about your account across the systems in this policy — Modmail history, theory/application submissions, blacklist or ban status. Because our only identity system is Discord, we'll verify a request by confirming it comes from the Discord account in question (e.g. by DMing that account) before sharing anything. We may decline or limit requests that can't be reasonably verified or that would require exposing another person's private information.

You can request deletion of records tied to your account (e.g. a resolved Modmail ticket, a rejected theory submission) through Discord (§33). Some things we may need to keep regardless of a deletion request:

• Active bans, Modmail bans, blacklist entries, or appeal blocks, while they remain relevant to ongoing moderation or security
• Records reasonably needed to investigate abuse, fraud, or a safety incident
• Anything we're legally required to retain (§27)

Deleting a Firestore record does not retroactively delete Discord messages already sent (e.g. a Modmail thread's message history, or an appeal embed already posted) — those follow Discord's own message deletion, which staff can also action on our side within that channel.

• Discord — inherently, since all of these features run on Discord's platform.
• Hosting & infrastructure: Cloudflare (Workers, static hosting, and R2 object storage for uploaded article cover images), and whatever server or host runs the Tao bot process.
• Database: Google Firebase/Firestore, which stores the records described throughout this policy.
• Third-party APIs: Google Cloud Translate (flagged non-English message text, §7), Lavalink/Spotify/lyrics/Last.fm APIs (music search terms, §19).
• Advertising: Google AdSense (§20).
• Our moderators/administrators — staff with the appropriate role can see the records relevant to their duties (Modmail threads, applications, theories, blacklist, appeal channel).
• Law enforcement or government authorities — only where legally required (§27); we do not otherwise proactively share information with third parties beyond what's listed here.

We do not sell, rent, or trade your information.

We may access, retain, or disclose information where we believe in good faith it's necessary to: comply with a valid legal obligation or request; investigate or respond to a security incident, fraud, or abuse; protect the rights, safety, or property of our users, staff, Discord, or the public; or enforce our community rules. We distinguish this from routine practice — the sections above describe what we actually do day-to-day; this section describes what we're legally able to do if the circumstances require it.

• Secrets management: the bot's Discord token, Firebase service-account credentials, and third-party API keys are kept in environment variables, not hardcoded or committed to source.
• Access control: staff-only features (Modmail, applications, theories, blacklist, anti-nuke, dashboard) are gated behind Discord role/permission checks (e.g. a Support Team role or Manage Messages permission) or, for the site's admin sync, a Firestore admins collection kept in sync with a Discord role.
• Identity verification: the appeal endpoint independently re-verifies your Discord identity against Discord's API using your OAuth token rather than trusting a client-supplied user ID.
• Firestore security rules restrict public read access to a small number of intentionally-public collections (e.g. published articles, the appeal block list for client-side UX checks); writes to sensitive collections are restricted to the bot's own admin-SDK credentials.
• Bot-scope restriction: Tao is coded to automatically leave any Discord server it's added to that isn't explicitly authorized by its developer, reducing exposure of these features to unintended servers.
• Logging: the bot and worker log operational events (errors, key actions) to their own console/host logs for debugging — these are operational logs, not a separate user-facing analytics product.

We have not implemented, and do not claim, field-level encryption of database contents beyond what Firestore and Cloudflare provide by default (encryption in transit via HTTPS, and Google/Cloudflare's own at-rest protections for their infrastructure).

• Discorddiscord.com/privacy
• Google Firebase / Firestorefirebase.google.com/support/privacy
• Google Cloud Translatepolicies.google.com/privacy
• Google AdSensepolicies.google.com/privacy
• Google Fontspolicies.google.com/privacy
• Cloudflare (Workers, Pages, R2)cloudflare.com/privacypolicy
• Spotify (metadata only)spotify.com/legal/privacy-policy
• Last.fmlast.fm/legal/privacy

Each is used strictly for the purpose described in the section that mentions it (e.g. Translate is only for the language filter; Spotify/Last.fm/Lavalink are only for music commands). We do not send Modmail content, theory submissions, or application answers to any of these services.

We're a small volunteer fan project, not a registered data controller with dedicated legal counsel, so we describe applicable rights carefully rather than claim a specific law governs us. If you're in the EEA/UK, rules like the GDPR/UK GDPR may give you rights to access, correct, or delete your data and to object to certain processing. If you're a California resident, the CCPA/CPRA may give you similar rights. We aim to honor reasonable access and deletion requests (§24–§25) regardless of where you're located, as a matter of practice rather than a specific legal determination — we are not asserting that any particular framework legally applies to us.

Our services are not directed at children under 13 (or the minimum age required to use Discord in your region), and Discord itself requires users to meet its own minimum age. We do not knowingly collect information from children under that age. If you believe a child has provided us with personal information, contact us via Discord (§33) and we'll take steps to remove it.

Tao and our Discord server operate within Discord's platform. Discord independently operates its own infrastructure and processes your account information under its own Privacy Policy and Terms of Service — things like your Discord account credentials, Discord's own message storage and moderation systems, and Discord's device/network-level data are entirely Discord's, not ours.

This Privacy Policy governs only what we — our website, our Firestore database, and Tao's own code — do with information, as described in this document. We do not control, and are not responsible for, Discord's own data practices. If you have concerns specifically about how Discord (the platform) handles your data, that's a matter for Discord's own policy and support channels, not ours.

For privacy questions, data access or deletion requests, Modmail privacy concerns, security concerns, or anything else in this policy, reach us through our Discord server at discord.gg/gokurakugai — either by opening a Modmail ticket or messaging a staff member directly. We're a small volunteer team and will respond as promptly as we can.

We may update this Privacy Policy as our website, Discord server, or Tao's features change. Material changes will be reflected by updating the "Last updated" date at the top of this page, and significant changes may also be announced in our Discord server. Continued use of the website, Discord server, or Tao after a change constitutes acceptance of the updated policy.