# Faction — we can’t read your messages. [Faction Privacy First](/) [Open Faction](https://app.faction.chat) Transparency # Transparency Last updated: 2026-05-18 The Faction server is treated as hostile, and the database schema reflects that. This page enumerates what the server actually stores, what gets logged, what analytics we run, and how we handle requests for user data. ## What the server stores ### Messages For E2EE channels — every server text channel and every direct message — the database row contains a `ciphertext` blob and the metadata required to route and order it. There is no plaintext column. The row carries: - channel_id, message id, sender_id. - ciphertext — the encrypted body. Opaque to the server. - server_id (or null for a DM). - created_at, edited_at. - mentions — recipient IDs needed for notification routing. - Disappearing-message flags (expires_at, burn_on_read, burned). - Coarse content flags (has_image, has_link, etc.) used for filtering — metadata only. ### Identity - Per-device Ed25519 signing key — public half only. - Per-device X25519 identity key, signed prekey, and one-time prekeys — public halves only. Private halves live in the OS keychain on desktop or as non-extractable WebCrypto keys in the browser. - OPAQUE record — the server-side artefact of the OPAQUE handshake. It cannot be inverted to recover the password, and it cannot be used to impersonate the user without their password. ### Membership and presence - Which users belong to which servers and channels. - MLS group state (epoch number, member list of public credentials). - Presence (online / idle / offline) for the lifetime of a session. ### Audit log Staff actions on the platform (admin operations, moderation decisions, infrastructure changes) are written to an append-only audit log. The log stores actor, action type, target id, target type, and a metadata JSON blob — **metadata only, never message content**. ## What the server cannot see - Plaintext of E2EE messages. Group channels use MLS, DMs use the Signal Protocol. The server never holds the keys. - Voice and video media. SFrame keys derive from the MLS group exporter on the client; the SFU forwards opaque encrypted frames it cannot decrypt. - Your password. OPAQUE never transmits the password. A database dump tomorrow does not contain a hash that can be cracked into your password — there is no hash, because the password was never sent. - Your private keys. Generated on your device, stored on your device, used on your device. The server stores public halves only. - Decrypted content in logs. The server logger redacts secret fields on emit, and every cryptographic decrypt path carries an explicit no-log invariant. ## Logging Server-side logging is structured JSON, one record per request or background job. Records carry a timestamp, level, service identifier, request id, and the originating user id when one is present. The logger applies field-level redaction so anything named `password`, `token`, or `secret` is stripped before emit. Cryptographic operations on the client are not logged at all. Rust commands that decrypt MLS or Signal payloads carry explicit `// SECURITY: never log this` markers next to the decrypted buffer, and the code review process treats any log statement near a decrypt path as a blocker. ## Analytics and third-party tracking 0 third-party analytics 0 tracking pixels 0 fingerprinting scripts 0 ad networks Faction does not embed Google Analytics, Mixpanel, Segment, Amplitude, Heap, Hotjar, FullStory, Datadog RUM, or any other third-party analytics or session-replay product. The client and the web surface ship without them, the server processes ship without them, and adding one requires a change to the codebase that would be visible in source. Operational monitoring (uptime, error rate, request latency) is handled by self-hosted infrastructure that does not see user content. When that monitoring stack lands publicly, the list of components and what they collect will be added to this page. ## Government and law-enforcement requests Faction is in v0.3 alpha. **We have not received any government or law-enforcement request for user data to date.** When the first one arrives, we will publish a transparency report describing the request, our response, and what was handed over (which, cryptographically, is what is in the table above — ciphertext, public identifiers, timestamps, and the fact that an account exists). We hand over what we have. We cannot hand over what we do not have. For E2EE channels and DMs, that means we have no plaintext to give. ## Warrant canary A warrant canary will be published from this page once Faction reaches general availability. Until then, the operative statement is simpler: > As of 2026-05-18, Faction has received no national-security letters, no FISA orders, no gag orders, and no other legal demands that we are prohibited from disclosing. This statement will be re-affirmed at every release. If it disappears from this page, or stops being updated, draw the obvious conclusion. ## Data retention - Messages are stored until the sender or channel owner deletes them, or until the disappearing-message timer expires. - MLS key packages uploaded by clients expire after 30 days if not consumed. - Pending MLS Welcomes (the encrypted blobs that add a new member to a group) are dropped after 7 days if the recipient does not pick them up. - One-time Signal prekeys are consumed atomically on use and never reused. - Account deletion removes account-scoped rows and revokes the OPAQUE record. Messages in shared channels are retained per the channel owner's settings; that is documented in the in-product flow. ## License and source availability Faction is source-available under [PolyForm Noncommercial 1.0.0](https://polyformproject.org/licenses/noncommercial/1.0.0/). The point of publishing the source is that the claims on this page are checkable. If a claim here disagrees with the code, the code wins and the page is wrong. Tell us. See also The [whitepaper](/whitepaper) describes the cryptographic stack and the trust boundaries. The [security page](/security) describes how to report a vulnerability, the severity classifications, and the disclosure timeline.