Последнее обновление:
Last updated: July 15, 2026
Email is not sold and is not shared with advertisers. It is needed for the account, login, service emails, access recovery, payment features, and security.
Public publications are visible to other people: topics, replies, comments, profiles, mod/build pages, reactions, and similar activity may be available to users, site guests, search engines, and caches.
If a user violates the 16+ or NSFW/18+ rules, the account, account features, or content may be restricted, hidden, or deleted. Complaints, publications, and materials submitted for moderation are visible to the administration and moderators during processing.
IP addresses, errors, and technical logs are usually needed short-term for security and diagnostics. In practice, such logs most often live for days or weeks, not years, unless there is a dispute, violation, attack, or legal reason to store them longer.
If you connect the site to a Mod Manager, launcher, automation client, or another integration through the public API, the site sees only the API requests and the data that it receives or creates on its own side. What the third-party app itself does on your device or in its infrastructure is governed by that app's own privacy policy.
This Privacy Policy describes how the Moddingflow site at <https://moddingflow.com> processes users' personal data.
Moddingflow is a site and modding community. The site provides registration, a personal account, public profiles, a forum, publications and discussion of mods/builds, news, guides, search, complaints, ratings, notifications, Premium features, and related payment features.
This version of the policy is focused on data processing on the site. If the site provides separate service features for interaction with an external app, for example transfer of authorization through a short-term auth ticket or website session, this policy describes only data processing on the site's side.
Personal data is processed in accordance with the EU General Data Protection Regulation - GDPR/DSGVO, as well as applicable German rules, including the TDDDG with respect to cookies, localStorage, sessionStorage, and similar technologies.
The controller responsible for data processing is:
Valerii Semenov
Email: <moddingflow@gmail.com>
Postal address:
c/o Autorenglück #61208
Albert-Einstein-Straße 47
02977 Hoyerswerda
Germany
When the site is accessed, technical request data may be processed: IP address or another network identifier, date and time of access, URL, HTTP method, referrer, user-agent, information about the browser and device, request headers, response codes, error information, security events, and rate-limit events.
The site uses such data to deliver pages and APIs, protect against attacks and abuse, limit request frequency, diagnose errors, protect login forms, recover access, upload files, perform search, and process payment webhook events.
There is no separate proprietary long-term access-log table in the site's code for all visits to the site. At the same time, technical logs may be kept by infrastructure providers, for example hosting, database, CDN, and security services, in accordance with their settings, contracts, and policies.
Legal bases: Art. 6(1)(f) GDPR - legitimate interest in safe and stable operation of the site; in individual cases Art. 6(1)(c) GDPR - compliance with legal obligations.
#### Approximate active-audience measurement
After this feature is enabled, a visible, non-idle tab on user pages outside the administrative area sends a one-minute heartbeat to the server. The server accepts an IP only through the existing trusted-proxy chain, validates and normalizes IPv4/IPv6, and immediately converts it with a permanent dedicated secret into an HMAC-SHA256 pseudonym. The account, browser, device, and cookie are not used as identity. The raw IP is not passed to the RPC, is not written to the metric table, and must not enter this feature's logs; no new cookie, localStorage, or other browser storage is created.
One such IP pseudonym counts as one approximate unique visitor in the rolling windows for the last 24 hours, 7, 30, or 365 days (DAU, WAU, MAU, or YAU). A shared IP can merge several people, while a changing IP can count one person more than once, so the result is an estimate rather than an exact count of people. Only the HMAC-IP and the start, last activity, and end of a continuous online session are recorded; sessions are deleted in batches after 731 days. The first successful heartbeat date is retained so that partial windows can be stated and only equal-duration intervals are compared.
An HMAC-IP is pseudonymised, not anonymous, data. An IP address is an online identifier under GDPR Recital 30, and pseudonymisation does not take data outside the GDPR, as also emphasised by the EDPB. The purpose is to measure site use and reliability and to plan improvements. The legal basis is Art. 6(1)(f) GDPR, the legitimate interest in operating and improving the service, subject to the principles in Art. 5 and transparency under Art. 13 GDPR. A user may object to this processing under Art. 21 GDPR.
When registering and using an account, the following are processed: email, public nickname, login, user identifier in Supabase Auth, technical account data, session information, authorization tokens, registration date, last login date, history of acceptance of legal documents, language and profile settings.
The password is stored and verified by Supabase Auth. I do not receive or store the password in plaintext.
When you enable or press "Remember me" during sign-in, the site stores the technical setting `mf_auth_session_persistence` and extends the lifetime of the related authorization cookies/tokens on that device for up to 30 days. This means that after closing and reopening the browser, the user usually remains signed in. The feature applies only to the current device and browser and ends when the user signs out, the session is revoked, the period expires, or cookies/site data are cleared.
Creating an account requires explicit acceptance of the current Privacy Policy and Terms of Use. Without such acceptance, creating an account and/or using account features is unavailable.
When legal documents are accepted, the site records the accepted versions of the documents, document type, acceptance language, user identifier, and date/time of acceptance. This information is used to confirm which mandatory documents applied to the account at the time of registration or later acceptance.
If substantial updates to mandatory legal documents are published in the future, the site may require renewed acceptance before further use of the account. Acceptance of documents is a prerequisite for the account contract and use of account features; however, processing of personal data continues to be based on the relevant GDPR legal bases indicated for the specific processing purposes in this policy.
When logging in through external providers, the site may receive data transmitted by the relevant provider:
The site does not receive passwords from Discord, Google, Steam, or other external services.
For linked external accounts, the site may store provider, provider user ID, email, name, avatar, link date, and last synchronization date. If Steam does not transmit an email, the site may use a technical synthetic email only to create and link the account within the authorization system.
Purposes of processing: creating and maintaining the account, logging in to the site, protecting the account, displaying the profile, and fulfilling user settings.
Legal bases: Art. 6(1)(b) GDPR - provision of account features; Art. 6(1)(f) GDPR - protection of accounts and the service.
If you enable two-factor authentication, processing of the code from the two-factor protection application (TOTP) is performed through Supabase Auth. The site may also store technical information necessary to verify the security level of the session.
During access recovery, email, login/nickname for account lookup, a one-time recovery code in hashed form, code expiration period, number of attempts, and marks of confirmation and use of the recovery link may be processed. Service emails are sent through Mailgun and/or Supabase.
To protect the account, a limited history of hashes of previous passwords may be stored in order to prevent reuse of old passwords. Passwords are not stored in plaintext.
Legal bases: Art. 6(1)(b) GDPR - access recovery at the user's request; Art. 6(1)(f) GDPR - account security.
The following may be processed and displayed in the profile: nickname, login, mention tag, avatar, banner, language, public status, visibility settings, comment settings, profile appearance, avatar frames, emoji status, profile comments, likes/praises, view counters, information about public publications and activity.
If you upload an avatar, banner, or other public profile images, they may be stored in Supabase Storage and be accessible through a public link. Do not upload images containing other people's personal data or information that you do not want to disclose publicly.
Purposes of processing: providing the public profile, personalizing the account, operating the site's social features.
Legal bases: Art. 6(1)(b) GDPR - provision of profile features; Art. 6(1)(f) GDPR - operation of the community and protection against abuse.
When using the forum and publications, the following are processed: topics, messages, replies, news, titles, publication text, images, attachments, language, selected game, section, creation and editing dates, authorship, likes, reactions, subscriptions to topics, notifications, complaints, moderation decisions, and related technical data.
Public publications may be available to other users, site guests, search engines, and caching services. Deletion of an account or material does not always mean immediate disappearance of copies from search engine caches, CDNs, or external archives.
Purposes of processing: operation of the forum, publication and discussion of materials, notifications, moderation, protection against spam and violations.
Legal bases: Art. 6(1)(b) GDPR - provision of forum features; Art. 6(1)(f) GDPR - moderation, security, and development of the community; Art. 6(1)(c) GDPR - compliance with legal obligations, if applicable.
If you create or edit a mod/build page, the site may process: title, description, version, download links, homepage or source code, images, gallery, changelog, categories, dependencies, incompatibilities, requirements, FAQ, NSFW labels, complaints, suggestions, likes, views, and download events.
Mod/build archives uploaded through the built-in upload function are transmitted directly from the user's browser to Cloudflare R2 through a signed upload URL. This means the archive itself is sent to Cloudflare/R2 infrastructure without intermediate file storage on the Moddingflow application server, although the site creates and controls the upload session.
During this upload, the site and Cloudflare/R2 may process the original filename, size, content type, SHA-256, R2 ETag, staging/final bucket, object key, upload, verification, and publication status, related timestamps, IP address, user-agent, technical request headers, and other request/log data needed for upload, security, diagnostics, and file-integrity confirmation.
Such archives may be temporarily stored in a staging bucket until upload completion and technical verification, and after acceptance may be copied or moved to the main R2 storage for downloads. The temporary staging object may be deleted after finalization, rejection, or upload cancellation.
For users whose browser cannot reach the primary Cloudflare/R2 download route, the site may request a short-lived Bunny.net Pull CDN fallback URL for the same archive. Bunny pulls the file from the protected Cloudflare/R2-backed origin and may cache the immutable blob as a delivery layer only; Cloudflare/R2 remains the source of truth for archive storage, metadata, hashes, and permissions.
Images, galleries, and other public media for mod/build pages may be stored in Supabase Storage, Bunny.net Storage/CDN, or delivered through a CDN, if such delivery is enabled.
To protect statistics and prevent manipulation, view and download events, a user identifier, or a technical anonymous deduplication key for guest downloads may be stored.
Purposes of processing: publication of mods and builds, statistics, ranking, protection against manipulation, moderation.
Legal bases: Art. 6(1)(b) GDPR; Art. 6(1)(f) GDPR.
When using search, the search query, selected language, filters, result limit, and technical request data are processed. Search queries are used to return results and protect against abuse. By default, the site does not maintain a separate user search query history in its own table, but a query may end up in infrastructure technical logs.
The site builds a search index from public site materials, including public topics, messages, mod pages, news, guides, and other indexable public pages.
As of this update, no external embeddings or semantic search provider is used. The site does not transmit search queries or fragments of public materials to external embedding providers such as OpenAI or Hugging Face for building embeddings.
If an external embeddings provider appears in the future, the site will notify about this separately at least 30 days in advance. Such notice will indicate the provider, processing region, categories of data, legal basis, and transfer mechanism; where required, new consent will be requested through a banner before such processing begins.
If you submit a search quality report or complaint about smart search, the search query, expected result, actual result, language, consent mark and, if you are logged in to an account, user identifier may be stored. Such reports are visible to administrators in the smart search complaints queue and are used for manual review of result quality.
Complaints about smart search are deleted after the final verdict of the administration or automatically 180 days after creation if they have not been manually deleted by that time. If the complaint was submitted from an account and an administrator leaves a response, the user receives an account notification with the review result.
Ratings, statuses, and recommendations may be calculated based on public activity: publications, likes, views, downloads, complaints, and other actions on the site.
Legal bases: Art. 6(1)(f) GDPR - improvement of search, statistics, and site quality; Art. 6(1)(a) GDPR - if a specific feedback form requires separate consent.
The site may process notifications about new replies, mentions, moderation actions, updates to watched materials, changes to legal documents, and other account events.
Legal bases: Art. 6(1)(b) GDPR - provision of account and notification features; Art. 6(1)(f) GDPR - convenience and security of the community.
When a complaint about user content is submitted, an appeal against a suspension is filed, or moderation actions are applied, the following are processed: complaint or appeal author, object of the complaint or appeal, reason, text of the request, review status, moderator or administrator comments and response, processing date, moderator or administrator identifier, action type, and technical metadata. Complaints about smart search are described separately in section 3.7.
Administrators and moderators may see information necessary to review the complaint or appeal: who submitted the request, when it was received, what material, user, or moderation measure it concerns, the stated reason, review status, related comments, the administration's response, and service metadata. This is needed to verify complaints and appeals, show the result on the lock screen or in the account, prevent spam, mass false complaints, and other abuse of the complaint and appeal system, as well as to apply moderation measures to users who abuse this feature.
Complaints about user content are usually automatically deleted after review by the administration or after 90 days from creation if they have not been reviewed by that time. In rare cases, the administration may disable automatic deletion of a specific complaint, for example if it cannot be reviewed before the 90-day period expires or if longer storage is necessary to protect the site, prove violations, prevent repeated abuse, or comply with legal obligations.
Appeals against suspensions and other moderation measures may be stored until the administration's final response and then for as long as necessary to show the result to the user, prove review, prevent repeated abuse of the appeal system, protect the site, or comply with legal obligations. If access to repeated appeals is restricted because of spam, irrelevant requests, or other abuse, a record of the reason for that restriction may be stored.
Moderation decisions and administrative actions may be stored longer than ordinary user content if this is necessary to protect the site, prove violations, prevent repeated abuse, or comply with legal obligations.
Legal bases: Art. 6(1)(f) GDPR - protection of the community and service; Art. 6(1)(c) GDPR - if storage is required by law.
If you use paid features, the site may process: user identifier, Stripe Customer ID, billing email, subscription status, plan, validity period, renewal cancellation, checkout consent records, cancellation audit records, language, legal copy version/hash, email confirmation status, entitlements, short-term technical payload of Stripe webhook events, and long-term minimal Stripe IDs, statuses, plan, amounts, currency, timestamps, and information necessary to grant Premium access, reconcile, and keep records. Checkout consent and cancellation audit records do not store request IP addresses or user-agent strings.
Payments are processed by Stripe. I do not receive or store the full bank card number.
To prevent repeated processing of the same payment event, reconcile payments, diagnose errors, restore subscription status, and investigate disputed transactions, the site may temporarily store the technical payload received from Stripe for the webhook event in full, including metadata and the event object, but only for up to 90 days. After that, the full technical payload of the event is deleted from the webhook event record, while the technical record, in order not to process the payment twice, is retained with minimal fields: Stripe event ID, event type, Customer/Subscription/Invoice/PaymentIntent/Charge/Checkout Session ID, subscription or payment status, plan/price ID, amounts, currency, event time, livemode, processing status, and a short error message if processing ended with an error.
If access was granted manually or transferred from an external subscription source, the access source, external reference, and minimal metadata necessary to confirm Premium status may be stored. The code also provides for legacy/manual sources of Premium status, for example Boosty, Patreon, Discord, or Telegram; such data is processed only if the relevant integration is actually used for your account.
Legal bases: Art. 6(1)(b) GDPR - performance of the contract and provision of paid features; Art. 6(1)(c) GDPR - tax and accounting obligations; Art. 6(1)(f) GDPR - prevention of fraud and abuse.
The site may store information about acceptance of the privacy policy, rules, terms of use, and other legal documents: user identifier, document type, version, language, date and time of acceptance.
Purposes of processing: confirmation that the user was informed, compliance with legal obligations, protection of the project's rights and interests.
Legal bases: Art. 6(1)(c) GDPR; Art. 6(1)(f) GDPR.
If you contact me by email or through other channels, your contact details, the content of the message, attachments, and technical correspondence data are processed.
Purposes of processing: responding to the request, user support, handling complaints, protection of rights.
Legal bases: Art. 6(1)(b) GDPR - if the request is related to an account or service; Art. 6(1)(f) GDPR - general interest in communication and protection of the project.
If the site provides an authorization or transition feature to an external app, the site may create a short-term auth ticket or website session linked to your account. This data is used only to transfer login state between the site and the application and to protect such transition.
The database may store technical information about the ticket/session: user identifier, one-time ticket hash, expiration period, use mark, device/session metadata, creation date, expiration date, revocation date, or last use date.
This policy does not describe in detail the local files, settings, and technical integrations of separate desktop applications, because this version relates to the Moddingflow site.
Legal bases: Art. 6(1)(b) GDPR - provision of the requested feature; Art. 6(1)(f) GDPR - security of authorization transfer.
The Moddingflow public API is used for reading the public catalog, search, install-plan generation, downloading allowed files, creator upload and publishing, OAuth login, personal access tokens/API keys, and delegated Agent Gateway tools. The API may be used by the site, the official Mod Manager, automations, and third-party apps, services, or launchers.
When the website interface itself calls the Moddingflow API on a user's behalf, the API is a technical delivery channel within the same Moddingflow service and does not by itself introduce a separate third-party controller. The same operator, purposes, legal bases, and this Policy apply. API use is also subject to the Terms of Use and the current public API documentation.
When the API is accessed, the site may process the technical request data described in section 3.1, including IP address or network identifier, user-agent, HTTP method, URL, headers, request ID, trace ID, response status, error information, rate-limit events, and abuse budget events. Client key/client ID, headers such as `x-moddingflow-client`, token fingerprint, user ID, scope, search and filter parameters, cursor/limit, install-plan parameters, artifact/mod/version IDs, preferred CDN, fallback probe data, and API operation result data may also be processed.
For OAuth and API access, the site may store OAuth client metadata, allowlisted redirect URIs, authorization code grants, device authorization grants, refresh token rotation chains, personal access token/API key metadata, revoke state, last used timestamp, and audit events. Authorization codes, device codes, refresh tokens, and personal access tokens/API keys are stored as hashes; the raw authorization code, raw device code, raw refresh token, raw personal access token, client secret, and user password are not meant to be stored in plaintext. Access tokens are short-lived bearer tokens; Agent Gateway receives a separate short-lived delegated token with audience `agent-gateway`, narrow scopes, and actor/delegation metadata, not the full user session token.
If you create or update materials through the API, the same categories of data are processed as when publishing through the site: title, slug, summary, description, language, categories, version labels, release metadata, URLs, NSFW flags, dependencies, upload session data, file metadata, validation status, moderation/publish state, and related timestamps. This data may become public if the material is published.
For uploads and downloads through the API, original filename, size, content type, expected SHA-256, actual SHA-256, R2 ETag, upload status, upload part ETags, final blob ID, artifact ID, download session ID, signed upload/download URL expiry, primary/fallback CDN metadata, fallback reason/probe data, and technical data needed for file integrity verification, short-lived link issuance, abuse prevention, and diagnostics may be processed. Private storage object keys, provider upload IDs, and signed URL material are not included in the user export and are not intended for public disclosure.
For repeatable write requests, the API uses `Idempotency-Key`. The site may store user ID, operation, idempotency key, request body hash, response status/body, lock/expiry timestamps, and replay audit events. This is needed to safely replay a result after a network error and avoid duplicate publications, uploads, or state transitions.
For API security, auth audit events, write audit events, Agent Gateway audit events, redacted Agent Gateway input/output snapshots, moderation review rows, webhook queue rows, rate-limit events, and abuse budget counters may be stored. Such records may include event kind, user ID, actor user ID, client ID, API key ID, scopes requested/granted, denied scope, resource kind/ID, idempotency key, request ID, trace ID, token fingerprint or hash, redacted metadata, tool name, decision, and timestamps. Raw tokens, passwords, client secrets, and authorization headers should be redacted, hashed, or not recorded.
Third-party apps, services, and launchers that connect to the Moddingflow API are independent external clients unless a separate data processing agreement is concluded with them. They may collect their own logs, telemetry, device data, local file paths, installed mods, settings, accounts, and other data outside the site. Moddingflow is responsible for processing on the site and API side, but does not control and is not responsible for the collection, storage, transfer, or deletion of data by such third-party apps, services, or launchers. Before using such a client, review its privacy policy and settings.
Purposes of processing: providing the public API, OAuth login and access revocation, publishing and downloading materials, security, rate-limit, abuse prevention, diagnostics, file integrity, action audit, moderation, and compliance with legal obligations.
Legal bases: Art. 6(1)(b) GDPR - provision of API features requested by the user or creator; Art. 6(1)(f) GDPR - security, abuse prevention, API stability, audit, and protection of the project; in individual cases Art. 6(1)(c) GDPR - compliance with legal obligations.
To create an account, email, login/nickname, password or external login provider data, as well as technical authorization and session data, are required. Without this data, registration, login, and use of account features are impossible.
Technical request data, technically necessary cookies, localStorage, and sessionStorage are needed for the operation of the site, security, protection against abuse, saving the session, language, theme, and local interface settings. If the browser blocks such data or it is deleted, individual site features may work incorrectly, login may be reset, and access to forms, uploads, or APIs may be restricted.
Public profile, avatar, banner, comments, publications, forum topics, mod/build pages, complaints, search quality reports, and support messages are voluntary. If you do not provide such data, the corresponding features will be unavailable or cannot be processed.
Premium features and subscriptions are voluntary. For their setup and maintenance, data required for payment, subscription, granting access, and confirming Premium status is necessary. If such data is not provided or the payment is not completed, paid features will be unavailable.
Interaction features between the site and an external app, if available, are voluntary. If you do not use an auth ticket or website session, transfer of login state between the site and the application will be unavailable.
Use of authorized public API features is voluntary, but without technical request data, an OAuth/API token, scopes, rate-limit data, and the required payload/metadata, the corresponding API request cannot be performed. Third-party apps and launchers may ask you for additional data separately from the site; providing such data is governed by their own terms and policies.
The minimum age for independent account registration and use of interactive site features is 16 years. The site is not intended and is not specifically targeted at children under 16 years of age.
If you are under 16 years old, you must not independently create an account, publish materials, send complaints, purchase Premium, or use other interactive features without consent or permission from a parent or legal representative, if such consent is required by applicable law. Art. 8 GDPR applies to a child's consent to information society services if processing is based on consent.
If I learn that an account was created by a child under 16 years of age without the necessary consent or permission of a parent or legal representative, I may restrict account features, request confirmation of consent, delete the account and/or delete or anonymize related data to the extent necessary and permitted by law. A parent or legal representative may write to <moddingflow@gmail.com> if they believe that a child under 16 has provided personal data on the site without the necessary consent.
The site may have features related to NSFW/18+ content. Only users who are already 18 years old and have reached the age of majority in their country of residence may unlock, view, publish, upload, or label such content. If applicable law establishes stricter age restrictions, the user must comply with such restrictions.
The site uses cookies, localStorage, sessionStorage, and, for forum drafts, IndexedDB. Some of these technologies are needed for login, security, language, theme, local interface settings, reply drafts, protection against repeated actions, and interface recovery.
The site's own local cookie banner is no longer used and does not collect consent for advertising. For Google AdSense and related advertising technologies in the EEA, the United Kingdom, and Switzerland, consent is requested and managed through Google Privacy & messaging - Google-certified Consent Management Platform (CMP) with support for the IAB Transparency & Consent Framework (TCF). The user may agree, refuse, or configure settings through the Google CMP message if it is shown for their region and page.
Main cookies and similar technologies:
| Name / key | Type | Provider | Purpose | Period | Necessary? | Basis |
|---|---|---|---|---|---|---|
| `sb-...-auth-token` and related auth cookies | cookie | Supabase Auth | Login, maintaining the session, refresh token, account protection | Until logout, session revocation, account deletion, token expiration/revocation, or clearing browser cookies | Yes, for the account | § 25(2) No. 2 TDDDG; Art. 6(1)(b) GDPR; Art. 6(1)(f) GDPR |
| `mf_auth_session_persistence` | cookie | Moddingflow | Stores the selected session mode: ordinary browser session or "Remember me"; with the `remembered` value, related auth cookies may keep the user signed in on the device after a browser restart | Up to 30 days for `remembered`; for `session` - until the browser session closes, logout, session revocation, or clearing cookies | Conditional, only if the user enables "Remember me" | § 25(2) No. 2 TDDDG; Art. 6(1)(b) GDPR; Art. 6(1)(f) GDPR |
| `cookie-consent` | cookie and localStorage | Moddingflow | Legacy record of the previous local choice of cookie preferences; it is not a source of consent for Google AdSense in the EEA/United Kingdom/Switzerland and may be deleted when privacy settings are reset | Until settings are reset or the browser is cleared | No, a new record is no longer created by the local banner | § 25(2) No. 2 TDDDG; Art. 6(1)(f) GDPR for previous storage of the choice |
| `whistle-external-media-consent` | cookie and localStorage | Moddingflow | Storing the user's choice to permanently allow embedded external Google/YouTube videos/materials without repeatedly showing the local placeholder | Cookie - up to 12 months; localStorage - until permission is reset, settings are changed, or the browser is cleared | Conditional, only if the user chooses permanent permission for external materials | § 25(2) No. 2 TDDDG for storing the choice; Art. 6(1)(f) GDPR; loading external content after consent/interaction - Art. 6(1)(a) GDPR |
| `forum-lang` | cookie | Moddingflow | Language of the forum, news, ratings, and authorization interface | Up to 12 months, language change, or clearing cookies | Yes, if the user chooses a language | § 25(2) No. 2 TDDDG; Art. 6(1)(b) or Art. 6(1)(f) GDPR |
| `whistle-theme` | localStorage | Moddingflow | Saving the selected interface theme | Until the theme is changed, settings are reset, or the browser is cleared | Conditional, if the user chooses a theme | § 25(2) No. 2 TDDDG; Art. 6(1)(b) or Art. 6(1)(f) GDPR |
| `whistle-privacy-lang`, `whistle-rules-lang`, and compatible language keys of legal pages | localStorage | Moddingflow | Saving the language of legal pages and related interface links | Until the language is changed, settings are reset, or the browser is cleared | Conditional, if the user chooses a language | § 25(2) No. 2 TDDDG; Art. 6(1)(b) or Art. 6(1)(f) GDPR |
| `forum-reply-draft:{topicId}` and IndexedDB `moddinghub-forum/replyDrafts` | localStorage and IndexedDB | Moddingflow | Local forum reply drafts | Until submission, draft deletion, removal of the topic from storage, or clearing the browser | Conditional, for the draft feature | § 25(2) No. 2 TDDDG; Art. 6(1)(b) or Art. 6(1)(f) GDPR |
| `forum:viewed:{topicId}` | sessionStorage | Moddingflow | Preventing repeated counting of a view in one tab | Until the browser tab/session is closed | Conditional, for correct statistics | § 25(2) No. 2 TDDDG; Art. 6(1)(f) GDPR |
| `forum-anon-session-key` | localStorage | Moddingflow | Anonymous deduplication key for guest views/downloads and protection of statistics against manipulation | In the browser - until localStorage is cleared; server-side deduplication records usually up to 7 days | Conditional, for protection of statistics | § 25(2) No. 2 TDDDG; Art. 6(1)(f) GDPR |
| `mfa-fail-count` and related temporary MFA keys | localStorage | Moddingflow | Temporary counter of two-factor login errors and protection against code brute force | Usually during the current MFA process; deleted after successful verification, logout, reset of attempts, or clearing the browser | Yes, for login security | § 25(2) No. 2 TDDDG; Art. 6(1)(b) or Art. 6(1)(f) GDPR |
| `moddingflow-header-auth-identity-v1` | localStorage | Moddingflow | Local cache of site header data: user ID, nickname, avatar, status, and administrative access flag | Until logout, account change, clearing the site cache, or clearing the browser | Conditional, for displaying login state | § 25(2) No. 2 TDDDG; Art. 6(1)(b) or Art. 6(1)(f) GDPR |
| Google Privacy & messaging / CMP consent signals | cookie, localStorage, and similar technologies | Google / Google-certified CMP | Displaying a consent message, storing and transmitting the user's choice for advertising purposes, vendors, and TCF/Google consent signals | According to Google CMP periods, message settings, browser settings, and Google account settings | Conditional, for managing advertising consent where it is required | For storing and transmitting the privacy choice: § 25(2) No. 2 TDDDG and/or Art. 6(1)(c)/(f) GDPR; for advertising cookies and personalization - consent: § 25(1) TDDDG; Art. 6(1)(a) GDPR |
| Google AdSense/DoubleClick identifiers, for example `IDE`, `NID`, `__gads`, `__gpi`, or similar | cookie, localStorage, and similar technologies | Advertising, ad frequency, measurement, and protection of ad impressions | According to Google's periods and browser settings | No | Consent: § 25(1) TDDDG; Art. 6(1)(a) GDPR | |
| Embedded Google/YouTube materials | cookie, localStorage, and similar technologies | Google/YouTube | The local placeholder is displayed without connecting to the provider; external content is loaded only after user interaction | According to Google/YouTube periods and browser settings | No | Consent or user interaction, if applicable: § 25(1) TDDDG; Art. 6(1)(a) GDPR |
Local forum reply drafts (`forum-reply-draft:{topicId}` in localStorage and IndexedDB `moddinghub-forum/replyDrafts`) do not have an automatic lifetime in the site's code. They may be stored in the browser for years until you submit or delete the draft, clear site data, or the browser deletes them itself. Do not write passwords, tokens, private contacts, or other information in such drafts that you are not prepared to store locally in the browser.
The following security settings are used for login sessions: potentially compromised refresh tokens may be automatically revoked; reuse of a refresh token is allowed only within a short interval of 10 seconds; forced limitation to one session per user, total session duration, and inactivity timeout are not enabled.
Technically necessary cookies and similar technologies are used on the basis of § 25(2) No. 2 TDDDG and Art. 6(1)(b) or Art. 6(1)(f) GDPR. Storage and transmission of the user's choice in the CMP may be necessary to comply with consent requirements and provability of the choice. If a technology is not technically necessary, it is used only after consent.
On public pages where advertising is enabled, the site's code may load the Google AdSense tag so that Google Privacy & messaging can show a certified consent message. For users from the EEA, the United Kingdom, and Switzerland, consent for AdSense is collected through Google Privacy & messaging, a Google-certified CMP with support for the IAB Transparency & Consent Framework (TCF) and, if applicable, Google Additional Consent or other consent signals. After consent through Google CMP, Google may set its own cookies, localStorage, advertising identifiers, and process data in accordance with its privacy policy.
Legal bases for optional advertising technologies: § 25(1) TDDDG and Art. 6(1)(a) GDPR. The choice made in Google Privacy & messaging is managed by Google CMP mechanisms, browser settings, or Google account settings.
Withdrawal of consent takes effect for the future and does not affect the lawfulness of processing carried out on the basis of consent before its withdrawal. The local cookie-preference banner is no longer used. The site does not store separate consent for advertising; all decisions are managed exclusively through Google Privacy & messaging. The advertising choice made through Google Privacy & messaging is changed through the Google CMP interface, if the message is available again, as well as through browser or Google account settings. You may change or withdraw consent at any time by reopening the Google CMP message (usually through a "Privacy settings" button in the corner of the screen) or by resetting site cookies. When cookies/privacy are reset, the site deletes local records available to the site's code, including the previous `cookie-consent` in cookie/localStorage, as well as the site's own advertising cookies available to the site's code, and reloads the current page.
When permission for embedded external materials is reset, the site deletes its own `whistle-external-media-consent` record in cookie/localStorage and reloads the current page. After reloading, embedded Google/YouTube materials are again displayed as a local placeholder and connect to the relevant provider only after new user interaction or new permission, if such a feature is available.
The site cannot technically guarantee deletion of cookies, localStorage, advertising identifiers, or similar technologies that have already been set by Google, YouTube, or another external provider in their own domains or are not accessible to the site's code. Management of such data is performed through browser settings, the Google account/relevant provider account, and the deletion or processing-limitation mechanisms provided by them.
Embedded Google/YouTube materials, if displayed on the page, are first presented as a local placeholder without loading the external player. Connection to the relevant provider and possible data processing occur only after user interaction with such content. If the user chooses permanent permission for external materials, the site stores this choice in `whistle-external-media-consent` and may load such materials without showing the placeholder again until permission is reset or the browser storage is cleared.
The following providers may be used for the operation of the site:
| Service | Function | Role | Data | Country/region | Transfer mechanism |
|---|---|---|---|---|---|
| Supabase | Auth, database, Storage, Edge Functions, Realtime, and technical infrastructure | Data processor; may use a chain of sub-processors. For certain usage/service data, it may act as an independent controller | Account data, authorization data, profile, user content, storage files, technical logs | Project region: EU; access and sub-processors may be located in the EU, the USA, and other countries | DPA under Art. 28 GDPR; SCC for transfers to third countries; adequacy decisions for recognized countries, if applicable |
| OVHcloud | VPS hosting of the site, API, background processes, and scheduled jobs | Data processor | Technical hosting data, application logs, request data, environment variables, and service metadata necessary for operation of the application | Primary VPS: Beauharnois (BHS), Canada; support and sub-processors may involve Canada, the EEA, and other countries under OVHcloud's terms | DPA under Art. 28 GDPR; EU adequacy decision for Canadian commercial organisations, where applicable; SCC or other applicable safeguards for other third-country transfers |
| Bunny.net | CDN, Storage for public media/static assets, fallback Pull CDN delivery for mod/build archives, and delivery protection | Data processor | IP addresses and technical request data to the CDN, access logs (for example, Datacenter, Request ID, country/region derived from the request IP address, requested content URL/path, request date/time, and browser/user-agent, including platform and operating system version details such as Windows, Android, iPhone/iOS, or Macintosh/macOS, as well as technical compatibility tokens such as `KHTML, like Gecko`), cached files, storage files for public media/static assets, and temporary CDN cache copies of archive blobs when fallback delivery is used | Company is located in the EU; CDN and sub-processors may use global regions | DPA under Art. 28 GDPR; for transfers outside the EEA - SCC, adequacy decisions, or other applicable safeguards |
| Cloudflare | Cloudflare R2 object storage, direct browser-to-R2 uploads, signed upload/download URLs, storage and delivery of private mod/build archives | Data processor; for certain security/service metadata, the role may be determined by Cloudflare's terms and policies | Uploaded archive files, original filename, file size, content type, SHA-256, R2 ETag, bucket/object key, upload/download session metadata, IP addresses, user-agent, technical headers, and request/log data when accessing Cloudflare infrastructure | Global Cloudflare network; metadata and sub-processors may include the EU, the USA, and other countries depending on service and configuration | Cloudflare Customer DPA under Art. 28 GDPR, incorporated by reference into the applicable Cloudflare agreement; EU-US/Swiss-US Data Privacy Framework and UK Extension, if applicable; SCC or other applicable safeguards for transfers outside the EEA/UK/Switzerland |
| Mailgun | Sending service emails | Data processor | Sender/recipient email, subject, Message ID, delivery status, delivery logs, and technical delivery data | EU, USA, and/or other regions depending on routing and sub-processors | DPA; EU Model SCC / SCC for transfers outside the EEA |
| Stripe | Payments, subscriptions, customer portal, webhook events, and receipts | Independent controller for part of payment processing; data processor for certain service functions | Billing email, short-term technical payload of webhook events up to 90 days; long-term minimal Stripe IDs, subscription/payment status, plan, amounts, currency, timestamps, webhook event processing statuses, receipts, and accounting-required data | EU, USA, and other countries depending on product, user, and Stripe entity | DPA/DTA; EU-US Data Privacy Framework for Stripe LLC in the USA; SCC if DPF is not applicable or unavailable |
| Google OAuth, AdSense, and embedded Google/YouTube materials | Usually independent controller for OAuth, advertising, and embedded services; the role may differ for individual Google services | OAuth/profile data, email, avatar, advertising and cookie data, interaction data with embedded content | EU, USA, and other countries | Adequacy decisions; EU-US Data Privacy Framework for Google LLC; SCC if required and the transfer is not covered by adequacy/DPF | |
| Discord | Login through Discord, if you use it | Independent controller for the Discord account and OAuth; data processor only if a separate feature uses the corresponding agreement | Discord user ID, name/nickname, avatar, email, if it is transmitted by the provider | USA and other countries | EU-US Data Privacy Framework for Discord and the specified US entities; SCC and adequacy decisions, if applicable |
| Steam | Login through Steam OpenID and receipt of public profile data, if you use it | Independent controller | Steam ID, public profile name, avatar, and other public data if available through Steam | USA, EU, and other countries | EU-US Data Privacy Framework for Valve; SCC and organizational-technical measures, if applicable |
| Boosty, Patreon, Telegram, or other legacy/manual sources of Premium status | Verification or transfer of Premium status, only if the relevant integration is actually used | Usually independent controllers for their own accounts, payments, and communications | External reference, account ID, name/nickname, subscription status, or minimal access-confirmation metadata | Depends on the selected provider | Transfer mechanisms and safeguards of the relevant provider |
Supabase Auth and Row Level Security restrict application and user access to data. At the same time, Supabase as a managed service and data processor has administrative access to the infrastructure under its internal security policies, SOC 2 controls, contracts, and access procedures. Based on a review of the site's code, Moddingflow does not use Supabase Database Webhooks to transmit raw data to third parties.
For Cloudflare additionally: under Cloudflare's Self-Serve Subscription Agreement, the relevant agreement becomes effective when the customer clicks to accept it, uses or accesses the services, or otherwise indicates acceptance. If Customer Content includes Personal Data, Cloudflare states that it handles such data under Cloudflare's Data Processing Addendum, which is incorporated by reference into that agreement. The Cloudflare Customer DPA itself also states that it forms part of the Enterprise Subscription Agreement, Self-Serve Subscription Agreement, or other main agreement for Cloudflare services. Therefore, when Cloudflare R2 is used, the DPA applies as part of Cloudflare's contractual documentation to the extent provided by the applicable Cloudflare terms, without a separate paper signature being necessary.
As of this update, no external embeddings provider is used, so it is not included in the list of current providers. If such a provider appears later, it will be described separately before processing begins.
Third-party apps, services, launchers, automation clients, and other external clients that use the Moddingflow public API do not automatically become Moddingflow data processors. If they act in their own name, they are responsible for their own notices, legal bases, retention periods, security, and deletion mechanisms. Moddingflow is not responsible for their independent data collection and processing outside the Moddingflow site and API.
When a provider acts as a data processor on behalf of the controller, processing is regulated by a data processing agreement or another legal act under Art. 28 GDPR. Such providers must provide sufficient data protection guarantees and engage sub-processors only within applicable contractual and legal mechanisms.
Some providers may be located outside the European Economic Area, including the USA. If the European Commission has recognized a country as providing an adequate level of data protection, transfer to such country may be carried out on the basis of an adequacy decision without additional safeguards under Art. 46 GDPR. For the USA, the adequacy decision applies only to commercial organizations that participate in the EU-US Data Privacy Framework and have valid certification.
Before using the EU-US Data Privacy Framework, the site checks that the relevant organization has valid certification in the official Data Privacy Framework List and that the certification covers the required category of data. If certification is absent, expired, or does not cover the relevant data transfer, SCC or another applicable transfer mechanism is used.
The following main mechanisms apply to the providers used:
| Provider | Possible third country | Main transfer mechanism |
|---|---|---|
| Supabase | USA and other countries of sub-processors, if access or processing goes beyond the project region in the EU | DPA under Art. 28 GDPR and SCC; for sub-processors in recognized countries, an adequacy decision may apply |
| OVHcloud | Canada (primary VPS in Beauharnois) and other countries if support or sub-processing occurs there | EU adequacy decision for Canadian commercial organisations, where applicable; DPA under Art. 28 GDPR, SCC, or other applicable safeguards for additional third-country transfers |
| Bunny.net | Global CDN regions outside the EEA, if delivery or sub-processing occurs there | DPA under Art. 28 GDPR; SCC or adequacy decision for the relevant country, if applicable |
| Cloudflare | Cloudflare global network, the USA, and other countries if processing, metadata, support, or sub-processing occurs outside the EEA | Cloudflare Customer DPA, incorporated by reference into the applicable Cloudflare agreement; EU-US/Swiss-US Data Privacy Framework and UK Extension, if applicable; SCC or other applicable safeguards if DPF/adequacy is unavailable |
| Mailgun | USA and other countries of sub-processors, if email delivery or technical processing goes beyond the EEA | DPA and EU Model SCC / SCC |
| Stripe | USA and other countries necessary for payments, fraud prevention, banking, and payment partners | Data Transfers Addendum; EU-US Data Privacy Framework for Stripe LLC; SCC if DPF is not applicable or unavailable |
| USA and other countries where Google services operate | Adequacy decisions; EU-US Data Privacy Framework for Google LLC; SCC if the transfer is not covered by adequacy/DPF | |
| Discord | USA and other countries where Discord processes account/OAuth data | EU-US Data Privacy Framework for Discord and the specified US entities; SCC or adequacy decisions, if applicable |
| Steam/Valve | USA and other countries where Valve processes Steam data | EU-US Data Privacy Framework for Valve; SCC and additional organizational-technical measures, if applicable |
| Boosty, Patreon, Telegram, or other legacy/manual sources of Premium status | Depends on the selected provider, only if the relevant integration is actually used | Transfer mechanisms and safeguards of the relevant provider; where the site itself transfers data, data minimization and applicable contractual/legal safeguards are used |
As of this update, no external embeddings provider is used, so there is no separate transfer of data to third countries for external embedding generation. If such a provider appears later, the applicable safeguards and transfer mechanism will be described in advance.
You may request information about the applicable data transfer mechanism by writing to <moddingflow@gmail.com>.
Profiles, forum publications, mod/build pages, comments, likes, reactions, public statuses, and other materials may be visible to other users and site guests if the corresponding feature is public.
Do not publish personal data, other people's images, private links, API keys, tokens, addresses, correspondence, or other information that you have no right to disclose.
Do not publish special categories of personal data within the meaning of Art. 9 GDPR: information about racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for unique identification, health information, sex life, or sexual orientation.
The site does not request and is not intended for targeted collection of such information in user content. If you voluntarily publish special categories of personal data in a public profile, topic, reply, comment, mod/build description, image, attachment, or other user material, such information may be processed to the extent necessary for publishing, displaying, technical storage, indexing of public content, moderation, review of complaints, security, enforcement of site rules, and protection of the project's rights. For information that the user has manifestly made public, Art. 9(2)(e) GDPR may apply; in other cases, the material may be restricted, hidden, or deleted if this is necessary to protect the user, other persons, or the site.
The retention period for such information is determined by the retention periods of the corresponding user material. Because public content may be visible to other users, site guests, search engines, CDNs, caches, and external archives, do not post such data if you do not want it to be publicly distributed.
Restricting profile visibility does not necessarily hide already published public forum content or mod pages.
Data is stored no longer than necessary for the purposes of processing, unless longer storage is required by law, security, moderation, dispute resolution, or protection of the project's rights.
In brief: forum publications and mod/build pages are stored until deletion of the material or deletion of the account under the current implementation. Technical logs are usually stored short-term, most often 7-30 days. Stripe payment and tax data may be stored for up to 10 years, but the site does not receive or store the full bank card number. The JSON export "My data" is available in the account's personal area.
The current account deletion implementation deletes forum topics and messages created by the user, related profile data, user settings, profile images, and a number of related activity rows if they are linked to the account. Individual records may be retained or anonymized only if this is needed for law, security, moderation, accounting, disputes, or technical integrity of the service. Moderation and administrative audit logs may be retained after account deletion for moderation, security, proof of violations, dispute resolution, protection of the project's rights, and compliance with legal obligations; where applicable, a direct link to the account of a deleted moderator or administrator may be removed or anonymized without deleting the audit event itself.
<details>
<summary>Detailed retention table</summary>
| Data category | Retention period | Comment |
|---|---|---|
| Account, profile, settings | Until account deletion or while the data is needed for site features | Some public data is visible to other users until deletion or change of visibility settings |
| Login sessions, login cookies, and authorization tokens | Until logout, session revocation, account deletion, expiration, clearing the browser, or up to 30 days on the device when "Remember me" is enabled | "Remember me" keeps the user signed in after a browser restart for up to 30 days. Several active sessions may exist at the same time; potentially compromised refresh tokens may be automatically revoked |
| Avatar, banner, and other profile media | Until replacement, deletion, or account deletion | Copies may be temporarily retained in CDNs, caches, and backups |
| Public topics, messages, news, comments | Until deletion by the user, moderator, administrator, or until account deletion, if applicable | Copies may remain in search engines, external archives, and caches |
| Mod/build pages, descriptions, links, galleries, files | Until deletion by the author, moderator, administrator, or until account deletion, if applicable | Statistics and service records may be stored separately |
| Cloudflare R2 staging objects for mod/build archive uploads | Until finalization, rejection, abort/expiry of the session, or cleanup | The staging object is temporary and may be deleted after copying to the final bucket, rejection, or cancellation; short-term signed upload URLs usually expire quickly |
| Cloudflare R2 final archive blobs and R2 object metadata | Until deletion of the corresponding material or while archive storage is needed for site operation; deduplicated blobs may remain while another published file references the same SHA-256 | Includes bucket/object key, size, content type, SHA-256, and provider ETag; copies may temporarily remain in provider technical copies according to the provider's periods |
| R2 upload/download sessions | Upload URLs usually expire after about 15 minutes, download URLs after about 5 minutes; audit/session rows may be retained while needed for security, diagnostics, abuse prevention, disputes, or legal obligations | May contain user/file/blob references, status, timestamps, and technical metadata; access to session rows is restricted to service-role access |
| Aggregated statistics of mod and build views/downloads | While the corresponding material exists or while the metric is needed for site operation | Stored as an overall counter/statistic without linking to a specific user |
| HMAC-IP sessions for approximate DAU/WAU/MAU/YAU active-audience measurement | 731 days after the online session ends | Contains the pseudonymised HMAC-IP and session timestamps; no raw IP, account, or browser storage is retained in this metric. The permanent collection-start date is stored separately |
| Deduplication keys of build and mod views/downloads | Usually up to 7 days | Used to prevent repeated counting |
| Rate-limit records | Usually up to 1 day after reset | Used to protect APIs and forms against abuse |
| Public API abuse budget counters | The window is usually 1 hour; expired counters are usually cleaned up up to 1 day after reset | Used to limit upload/download byte budgets and protect against overload |
| Inactive login attempt records without blocking | Usually up to 1 day | Blocked/suspicious records may be stored longer if needed for security |
| Access recovery codes and records | Until use or expiration, then usually up to 30 days | Stored as hashes and service metadata |
| History of hashes of previous passwords | While needed to prevent password reuse | Passwords are not stored in plaintext |
| Short-term site auth tickets for an external app | Used or expired records are usually deleted after 24 hours | Ticket is stored as a hash |
| External app website sessions | Expired or revoked records are usually deleted after 24 hours | Active records are needed for authorization between the site and the application |
| Public API OAuth authorization codes | The codes themselves are valid for about 5 minutes; records may remain longer until cleanup or while needed for security/audit | The code is stored as a hash together with client, user, redirect URI, PKCE challenge, scopes, nonce/state hash, timestamps, and consumed status |
| Public API device authorization codes | Device/user codes are valid for about 15 minutes; records may remain longer until cleanup or while needed for security/audit | Device code and user code are stored as hashes; the row contains client, user after approval, scopes, interval, status, and timestamps |
| Public API access tokens and Agent Gateway delegated tokens | Access tokens are short-lived according to client configuration; Agent Gateway tokens are usually no longer than 5 minutes | The raw access token is not stored as a long-term record; audit records may contain token ID/fingerprint, scopes, audience, and metadata without the raw token |
| Public API refresh tokens | Until expiration, rotation, revocation, account/client deletion, or while needed for security, reuse detection, disputes, or legal obligations | Stored as a hash and token family chain; reuse detection may revoke the whole family |
| Public API personal access tokens/API keys | Until revoke, expiry, account deletion, or while the record is needed for security, audit, disputes, or legal obligations | Stores token hash, display prefix, scopes, last_used_at, expires_at, revoked_at/revoked_by, and audit trail; the raw token is not shown again |
| Public API idempotency records | At least 24 hours; then until cleanup or while the record is needed for security, diagnostics, disputes, or legal obligations | Store user ID, operation, Idempotency-Key, request body hash, response status/body, and lock/expiry timestamps; raw request body is replaced by a hash |
| Public API auth/write audit events | While needed for security, abuse prevention, error investigation, moderation, proof of actions, disputes, or legal obligations | May be append-only and contain event kind, user/client/API-key references, scopes, denied scope, resource IDs, request/trace IDs, redacted metadata, and timestamps; raw tokens/secrets should not be stored |
| Public API Agent Gateway audit and decision records | While needed for security, replay/debugging, control of delegated tool calls, disputes, or legal obligations | Contain user/actor IDs, tool name, decision, scopes, delegated token ID, redacted input/output snapshots, and policy metadata; raw authorization, tokens, and secrets are redacted |
| Public API webhook deliveries | Event payload data and the latest sanitized receiver snippet: up to 30 days; individual attempt history: up to 90 days; terminal delivery metadata and orphaned source events: up to 180 days | May contain event type/version, opaque user/mod/version/upload references, status, attempts, bounded latency/status/error diagnostics, and timestamps. Raw signing secrets and raw receiver response bodies are not stored in these rows. |
| Topic subscriptions and watched materials | Until unsubscribe, account deletion, or expiration of a temporary subscription | Temporary expired subscriptions are usually cleared after 24 hours |
| Search index of public content | While the corresponding public material exists | When material is deleted/changed, the index may be updated or cleared |
| Search quality reports and complaints about smart search | Until the final verdict of the administration or automatically up to 180 days from creation | May contain the search query, expected and actual result, language, consent mark, and user ID if the user was authenticated. If a complaint is linked to an account and an administrator leaves a response, the user receives an account notification; after the final verdict, the complaint is deleted from the queue |
| User complaints about content | Until review by the administration or usually up to 90 days from creation | Administrators and moderators may see the complaint author, date received, object, reason, status, and service metadata for reviewing the complaint and protecting against spam, false complaints, and abuse. In rare cases, automatic deletion of a specific complaint may be disabled |
| Appeals against suspensions and other moderation measures | Until the administration's final response and then while the record is needed to show the result, prove review, prevent abuse, maintain security, or comply with legal obligations | May contain the appeal text, penalty object, administration response, status, review date, user-visible result, and record of restricted repeated appeals where applicable |
| Moderation actions and administrative decisions | While needed for moderation, security, proof of violations, dispute resolution, protection of rights, and legal obligations | May be retained after account deletion; where applicable, a direct link to the account of a deleted moderator or administrator may be removed or anonymized without deleting the audit event itself |
| History of acceptance of legal documents | While the account exists and/or while this is needed to confirm compliance with obligations | Versions of legal documents may be stored without an automatic deletion period |
| Technical payload of Stripe webhook events, including metadata and event object | Up to 90 days | Used for short-term diagnostics, reconciliation, and recovery of webhook event processing; then the full event payload is deleted from the webhook event record without deleting the technical record that prevents repeated processing of the payment |
| Minimal Stripe billing/accounting records: Stripe Customer ID, subscriptions, entitlements, Stripe event ID, event type, related Stripe IDs, statuses, plan, amounts, currency, timestamps, and webhook event processing statuses | While needed for Premium access, prevention of repeated webhook event processing, payment reconciliation, protection against fraud, disputes, and legal/accounting obligations | Accounting data may be stored for up to 10 years if required by applicable law |
| User data export log | Usually up to 30 days | Successful website exports are recorded for security and control of repeated requests |
| Rate-limit events for manifest signing, if such feature is used | Usually up to 14 days | Technical protection against abuse |
| Email correspondence and support | While a response, request processing, protection of rights, or compliance with obligations is needed | The period depends on the content of the inquiry |
| Supabase logs | Usually up to 7 days | Technical logs of Auth, API, Storage, Edge Functions, and database |
| Daily Supabase database backups | Usually up to 7 days | PITR and separate manual external backups are not used |
| OVH VPS application and container logs | Until bounded log rotation; no more than five files of 10 MB per container under the production Compose policy | Technical logs of hosting, application, reverse proxy, and scheduled jobs |
| Mailgun logs | Usually up to 1 day | Technical logs of sending service emails |
| Bunny.net CDN cache and browser cache | Usually up to 1 month | After deletion or change of a file, public media/static files and fallback archive-delivery copies may be temporarily retained in CDN or browser cache |
| Bunny.net CDN access logs | Usually up to 2 days, if logging is enabled | Technical CDN delivery logs, including the Datacenter that delivered data to the user, Request ID, the country/region derived from the request IP address (when a VPN or proxy is used, this may be the country of the VPN/proxy IP rather than the user's actual location), requested content URL/path (for example, an image), and browser/user-agent, which may contain the browser, platform and operating system version such as Windows, Android, iPhone/iOS, or Macintosh/macOS, as well as technical compatibility tokens such as `KHTML, like Gecko` |
| Backups, caches, and technical copies of providers | Until the technical retention periods of the relevant provider expire | After data deletion, copies may be temporarily retained by providers |
</details>
Payment and accounting data may be stored for the periods provided by applicable tax and commercial law, usually up to 10 years, if such periods apply.
After data is deleted, its copies may be temporarily retained in backups, caches, CDNs, system logs, or by external providers until their technical retention periods expire.
Technical and organizational measures are used to protect data: TLS encryption in transit, Supabase Auth, access control, Row Level Security, rate-limit, protection of administrative features, MFA for sensitive administrative actions, uploaded file checks, security headers, and logging of security events.
Despite the measures taken, no internet service can guarantee absolute security. The user is required to keep their password and access to email/external accounts secure.
The site may use automated mechanisms for search, ranking, activity counters, anti-spam, rate-limit, deduplication of views/downloads, and generation of notifications.
Such mechanisms are not used to make decisions that have legal or similarly significant effects on the user within the meaning of Art. 22 GDPR.
Under the GDPR, you have the right to:
The first way to obtain a copy of your data is the JSON export "My data" in the site's personal account area. It includes account data, profile data, settings, user activity, moderation records visible to the user, external app access records without secrets, upload lifecycle rows and public API resource IDs related to your authored materials without staging keys, provider upload IDs, or signed URL material, and redacted payment diagnostics without the full technical payload of the Stripe webhook event. Raw cookies/login tokens, passwords, MFA secrets, raw API tokens, client secrets, auth/security logs, API audit/security logs, rate-limit logs, internal moderation notes, backups, and processor logs are not included in this file.
If the account is temporarily or permanently suspended, these rights remain available. Where technically possible, the lock screen or available account areas allow you to download the available data export, request account deletion, or access payment documents. If the interface is unavailable because of a suspension or technical error, you may send the request by email; include account details for identification.
You may lodge a complaint with a data protection supervisory authority, in particular at the place of your habitual residence, place of work, or place of the alleged infringement, if you believe that the processing of your personal data violates the GDPR.
For the Moddingflow project, the following supervisory authority is indicated as the contact supervisory authority:
Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg (LfDI BW)
Heilbronner Straße 35, 70191 Stuttgart, Germany
Website: <https://www.baden-wuerttemberg.datenschutz.de/>
Email: <poststelle@lfdi.bwl.de>
For rectification, deletion, objections, restriction of processing, manual requests, and cases not covered by the built-in export, you can write to <moddingflow@gmail.com>. I respond to requests within one month from receipt, unless the GDPR permits extension of the period in a specific case.
For correct identification, specify which account you used: site email, login, Discord ID, Steam ID, or another relevant identifier.
For questions about personal data processing, account deletion, data export, rectification of information, or withdrawal of consent, write to:
<moddingflow@gmail.com>