Your data, your server
Privacy Policy
Last reviewed: 2026-09-30
Last reviewed: 2026-09-30.
DjinnChat is self-hosted software. By default, conversation data, files, accounts, audit logs, and server telemetry stay on the DjinnChat server chosen by the organization running the deployment. This policy describes the first-party web, desktop, and mobile clients in this repository. A hosted operator may add separate subprocessors, telemetry, backups, or support workflows; that operator is responsible for documenting those additions.
Data Stored on This Device
The clients store the minimum local state needed to reconnect and keep the chat usable across refreshes, app restarts, and mobile OS lifecycle events.
| Data | Where | Purpose | Cleared by |
|---|---|---|---|
| Session snapshot | Native secure storage on mobile; memory plus httpOnly cookie on web; desktop secure session bridge on desktop | Keep the user signed in to a selected server | Logout; server-side session revocation |
| Server list, active server, active organization | Browser localStorage, Capacitor Preferences, or desktop storage |
Multi-server switching and first-run restore | Removing the server from the app |
| Participant display cache | Browser localStorage |
Avoid a blank shell while cookie restore runs | Logout |
| Offline message, draft, and sync-state cache | Browser/WebView localStorage |
Read recent channels while reconnecting and recover drafts | Clear local cache; logout |
| Queued text sends | Browser/WebView localStorage and sessionStorage |
Retry local sends after weak network or app restart | Clear local cache; logout |
| UI preferences | Browser/WebView localStorage |
Theme, panel layout, onboarding dismissal, and similar non-secret preferences | Browser/app data reset |
| Delivered push notifications | OS notification center | Let the user open routed notifications | Opening relevant notifications or OS notification controls |
The Clear local cache action removes offline message caches, drafts, and queued local sends from the current device. It does not delete server-side messages, files, account records, audit logs, or organization data.
Data Sent to the DjinnChat Server
Normal use can send the following data to the selected self-hosted DjinnChat server:
- Account credentials for login, registration, 2FA challenges, trusted-device enrollment, password changes, and WebAuthn/passkey ceremonies.
- Profile data such as display name, email address, avatar, status, and organization membership.
- Messages, reactions, channel briefs, pins, files, app/action payloads, and search queries.
- Encryption metadata such as public keys, wrapped private-key blobs, encrypted message bodies, signatures, channel session-key envelopes, and key recovery artifacts. Creating or restoring a key backup sends the supplied unlocking password or recovery code to the selected server. Displayed recovery codes are not persisted by the client; saving or copying them is an explicit action.
- Mobile push device registrations, including provider, platform, installation id, token hash, locale, timezone, app version, and the raw APNs/FCM token needed to deliver notifications.
- Call-room join requests and call metadata when LiveKit calls are used.
- Error reports only when the deployment enables the remote error-reporting endpoint.
Message privacy depends on the channel mode documented in SECURITY.md. Clients encrypt message bodies in encrypted DMs. Groups can use server-assisted session keys or peer-distributed keys without an operator-wrapped session key copy. The server generates participant private keys and receives sign-in and key-management secrets, so it must be trusted even for client-encrypted bodies. These modes do not protect against an actively malicious account server that captures those secrets or changes client code.
Unencrypted channels and file attachments are server-readable. Attachments do
not inherit message-body encryption. DB_ENCRYPTION_KEY protects the SQLite
database, including attachment metadata, but does not encrypt uploaded file bytes.
Filesystem or object-store encryption must be configured separately.
Data Sent to Third Parties
DjinnChat does not use advertising SDKs and does not sell personal data. Third-party disclosure depends on which deployment features are enabled.
| Third party | When used | Data involved |
|---|---|---|
| Apple Push Notification service (APNs) | iOS push notifications enabled | Device token, notification payload, routed channel/message metadata, and optional preview text according to user notification privacy settings |
| Firebase Cloud Messaging (FCM) | Android push notifications enabled | Device token, notification payload, routed channel/message metadata, and optional preview text according to user notification privacy settings |
| Djinn Relay push relay (Djinn Foundry) | The server operator routes mobile push through the hosted relay | Device token, notification payload and, unless IDs-only mode is enabled, notification title and body, forwarded to APNs/FCM and never stored or logged. For metering and billing the relay keeps keyed HMAC-SHA256 hashes of the recipient id and device token for at most about two months, a per-day push counter, and the operator's Stripe billing records |
| LiveKit server | Calls enabled and user joins a call | Audio/video media packets, room identity, participant identity, and call metadata; server location depends on the deployment |
| Sentry or another error sink | Explicitly configured by the operator | Error message, stack trace, app version, runtime metadata, and diagnostic context; should not include session tokens or message content |
| SMTP or email webhook provider | Email delivery configured | Email address, invitation/password-reset/security email content, and provider delivery metadata |
| Object storage provider | External file storage configured | Uploaded file bytes and metadata for the configured storage bucket |
Push notification preview content is controlled by notification preferences. Strict privacy mode and disabled previews produce generic notification content where the server-side notification pipeline supports it.
Deletion and Retention
- Logout revokes the active session when the server can be reached and clears local offline caches plus queued sends on the device.
- Clear local cache removes cached messages, drafts, sync-state, and queued sends without touching server-side records.
- Organization owners can configure message and file retention windows on the server. Those retention policies govern server-side message/file deletion.
- Self-hosted operators are responsible for account deletion requests, backup retention, and legal holds. The participant deletion API is restricted by organization membership and historical references, so operators should document their account-removal workflow before public store release.
Store Privacy Draft
These answers are a release draft for the first-party mobile apps. Re-check them whenever native plugins, SDKs, telemetry, or notification payloads change.
Apple App Privacy
Tracking: No.
Data linked to the user:
- Contact info: email address, if accounts use email login.
- User content: messages, files, reactions, channel briefs, call-related notes, and app payloads sent to the selected server.
- Identifiers: participant id, organization id, device push token, installation id, session identifiers, and trusted-device identifiers.
- Diagnostics: crash/error diagnostics only if telemetry is enabled by the operator.
Data not linked to the user:
- Aggregate app/version/runtime diagnostics only if configured to be detached from account identity by the operator.
Purposes:
- App functionality for chat, files, notifications, calls, authentication, multi-server restore, and security/audit controls.
- Analytics or diagnostics only when explicitly configured by the operator.
Google Play Data Safety
Data collected:
- Personal info: email address and profile display data.
- Messages: chat content, files, reactions, channel briefs, and app payloads.
- Photos and videos: only when selected or captured for upload.
- Audio/video: only during configured LiveKit calls.
- Files and docs: only when selected for upload.
- App activity: channel/message interaction metadata, search activity, and notification routing metadata.
- App info and performance: crash logs and diagnostics only if telemetry is enabled.
- Device or other IDs: push token, installation id, session id, participant id, trusted-device id.
Data shared:
- Push payloads with APNs/FCM when push is enabled.
- Call media and room metadata with the configured LiveKit server when calls are enabled.
- Diagnostics with the configured error sink when telemetry is enabled.
- Files with the configured object storage provider when external storage is enabled.
Security practices:
- Data is encrypted in transit when the deployment is served over HTTPS.
- Database encryption at rest is available for SQLite via
DB_ENCRYPTION_KEY; PostgreSQL deployments rely on infrastructure-level encryption. - Users can request data deletion from the self-hosted operator; local device caches can be cleared in app.