Privacy Policy

Last updated: 2026-04-18

1. Who we are

Murmur ("the Service") is operated by the project maintainer. For privacy inquiries, see Section 9 below.

2. What we collect

When the Service is added to a Discord server, we may process the following data:

• Discord identifiers. Server (guild), channel, user, and message IDs required to route, authorize, and store requests.
• Message content. Text from channels the bot has been granted access to, fetched on demand to produce summaries. Message content is stored in a per-server cache with a bounded retention window so repeat requests do not re-hit the Discord API.
• Display names. The last-seen display name for authors whose messages have been cached, so summaries remain readable when a user leaves the server.
• Usage metrics. Aggregate counts of requests, tokens, and credits per server and per user, used to enforce quotas and render the /usage dashboard.
• BYOK API keys. If an Operator provides their own LLM provider key, the key is encrypted at rest using Fernet and decrypted only in memory to satisfy a request from the server that configured it.
• Billing data. For paid tiers, the Service stores a Stripe customer ID and subscription status. Payment card data is handled by Stripe and never transits or is stored by the Service.
• Safety events. When a request is flagged by the content-safety layer, the Service logs a structured audit record (IDs, surface, verdict, hashes) to enforce the kill switch and detect abuse. Raw flagged content is never persisted — only SHA-256 hashes.

3. How we use it

We use the data above to:

• Respond to your requests (generate summaries, run commands).
• Enforce per-server and per-user quotas and subscription entitlements.
• Protect the Service from abuse (rate limits, safety blocks, content moderation).
• Diagnose errors and improve reliability via aggregated, non-content logs.

We do not sell personal data. We do not use your content to train LLMs. LLM inference is performed by third-party providers (see Section 5) under their own terms.

4. Retention

• Cached messages. Retained in a bounded per-server cache (currently up to 100,000 messages per Discord server, FIFO). Older messages are evicted automatically. The exact cap is a deployment setting that governs how far back a summary request can reach.
• Usage records. Retained for the current billing period plus a rolling window for historical analytics; older rows are purged.
• Safety events. Retained according to the ABUSE_EVENTS_RETENTION_DAYS operator setting (default 90 days) and then purged.
• Per-server data. When the Service is removed from a server, the stored rows for that server are purged.
• BYOK keys. Removed on request (/setup byok remove) or when the Service is removed from the server.

5. Third-party processors

The Service relies on the following third parties to function:

• Discord. The platform the bot runs on.
• LLM providers (for example Google Gemini, OpenAI, Anthropic, OpenRouter). Prompt text is transmitted to the selected provider to generate a summary.
• OpenAI Moderation API. A pre-check is run on the prompt text you submit before it reaches the LLM provider.
• Stripe. For paid-tier billing and the customer portal.

Each processor has its own privacy policy; please review them if you subscribe.

6. Your rights

Depending on your jurisdiction (including the EU/UK under GDPR and California under CCPA), you may have the right to access, export, correct, or delete personal data we hold about you. The Service exposes the following self-service commands:

• /export-my-data — exports the data the Service holds about you.
• /delete-my-data — deletes that data.
• /privacy — shows a summary of what is stored and how to request deletion.

Server administrators can purge all data for a server by removing the bot from it. For any request that cannot be fulfilled via a slash command, use the contact channel in Section 9.

6.2 What /export-my-data returns

The export is a single JSON file covering every category of personal data the Service stores about you:

• Cached messages you authored, with channel and server identifiers, timestamp, content, and any reply linkage.
• Usage records — per-request token counts, model, provider, request type, and timestamp — for any server where you are registered as an administrator of the Service.
• Safety records about you. Any kill-switch block keyed to your account, including platform-wide blocks that survive a server kick, plus the audit events behind them. These records identify your account by an HMAC-SHA256 hash of your user id, never the raw id.
• Subscriptions for servers you administer — tier, status, current period, and the linked Stripe customer / subscription identifiers (no payment-card data).
• BYOK key descriptors for servers you administer — provider, a short fingerprint computed from the encrypted blob, and the time the key was first stored. The key bytes themselves — encrypted or decrypted — are never returned in the export, by design.
• Allowlist memberships — every server that has explicitly allowlisted your account.

Replies and messages from other users in conversations you participated in are not exported — those are the other users' data, not yours.

When the bot has been removed from a server, that server's data is purged by the on_guild_remove handler and cannot be recovered by an export request, with one exception: pseudonymized safety audit events that justify a surviving platform-wide ban are preserved (Section 6.1) and remain visible in your export so you can see what we kept.

The export is delivered as a JSON file attached to the response. Discord's file-size limit applies; if the cached-message volume exceeds the cap, the message list is trimmed oldest-first and the file marks itself as truncated. Every other category is emitted in full.

6.1 Data we retain after an erasure request

When you run /delete-my-data, the Service erases all stored message content and cached display names associated with your account. If a platform-wide safety decision had previously been issued against your account (for example, a cross-server ban for abuse), the Service retains a pseudonymized record of that decision after erasure:

• The retained record contains only an HMAC-SHA256 hash of your user identifier, peppered with an operator secret. The raw identifier is not stored, and the Service cannot reverse the hash to recover it.
• The accompanying audit events behind the safety decision are similarly retained in pseudonymized form: hashed subject identifier, surface, verdict, category metadata, and SHA-256 hashes of the flagged content (never the content itself).
• The retained record is used solely to enforce the safety decision against future requests from the same account and to defend the decision if challenged.

The legal basis for this retention is GDPR Article 17(3)(e) (retention necessary for the establishment, exercise, or defence of legal claims) and Article 6(1)(f) (legitimate interest in preventing re-evasion of a safety decision and in defending the operator against a claim that the decision was unfounded). When the underlying safety decision is lifted, the pseudonymized record is deleted with it.

When the bot is removed from a server, the per-server data for that server is purged with the same carve-out: pseudonymized audit events that justify a surviving platform-wide safety decision are preserved; everything else for the server is deleted.

7. Security

BYOK keys are encrypted at rest using Fernet (AES-128-CBC + HMAC-SHA256). Transport between the Service and third-party APIs uses TLS. Access to production infrastructure is limited to the maintainer. No security scheme is perfect; we follow reasonable industry practice and disclose material incidents in the project's CHANGELOG and release notes.

8. International transfers

The Service's third-party processors may store and process data in jurisdictions outside your own, including the United States and the European Union. By using the Service, you consent to such transfers insofar as they are necessary to provide the Service.

9. Contact

Privacy questions and data-subject requests that cannot be fulfilled via a slash command can be raised in the Murmur support Discord server. Please mark GDPR/CCPA requests clearly so they can be routed appropriately.

10. Changes to this policy

We may update this Privacy Policy. Material changes will be reflected in the "Last updated" date above. Continued use after a change constitutes acceptance of the revised Policy.