Frequently Asked Questions
Short answers. Flip to dev mode if you want the technical version.
A desktop messaging app with group channels and direct messages, like Slack, but your messages are encrypted on your device before they leave it. The people running Pollis can't read them.
Tauri desktop client with a React UI and a Rust core for cryptography, MLS group state, and real-time media. The Rust core connects directly to a Turso/libSQL backend. Messages are end-to-end encrypted with MLS (RFC 9420) via openmls; the server only stores ciphertext envelopes plus routing metadata. No intermediate app server.
Slack and Discord can read your messages. Signal can't read yours either, but it's phone-number based and built for personal chats. Pollis is built for group workspaces like Slack, but with Signal-style privacy.
Slack/Discord: plaintext server storage. Signal: Double Ratchet, phone-number identity, optimized for 1:1 + small groups. Pollis: MLS-based group ratchet, username + email identity, Slack-style multi-channel workspaces, native desktop only.
Yes. Messages, files, and voice are all encrypted on your device using the same kind of cryptography banks and secure messengers use. Your private keys never leave your computer.
The server can see who is messaging when, but not what.
Client-side MLS encryption (RFC 9420) via openmls. Private keys live in the OS keystore (macOS Keychain / Windows Credential Manager / Linux Secret Service) through the keyring crate, never on disk, never sent anywhere.
Voice is end-to-end encrypted too: audio frames are AES-128-GCM encrypted by libwebrtc's FrameCryptor post-Opus / pre-SRTP, keyed by a 32-byte secret derived from the channel's MLS group via MlsGroup::export_secret("pollis/voice/v1", epoch, 32). The LiveKit SFU forwards ciphertext only; the key rotates on every MLS epoch advance.
Server sees: user IDs, group/channel membership, message timestamps, sizes, public keys, voice presence and RTP routing metadata. Server does not see: message plaintext, file contents, voice audio, private keys.
Not from what it stores. The saved record of a message no longer says who sent it, only the people in the conversation can tell, from the sealed contents. So a database breach, or a legal demand for stored data, can't reveal who said what.
One honest caveat, stated plainly: at the instant you hit send, the delivery server still checks that you're allowed to post in that conversation, so in that moment it does see it's you. Removing even that is future work.
Sealed sender (shipped). MLS already authenticates the sender inside the ciphertext via the message's BasicCredential ({user_id}:{device_id}), so the plaintext sender_id the server used to store was cryptographically redundant. The stored envelope is now sealed (migration 000008_message_envelope_sealed_sender.sql) and the recipient attributes the message from the MLS credential on decrypt, not from a server column.
Scope is at-rest only: the Delivery Service still authenticates the send with an X-Pollis-User header, so it sees the sender at the live moment. Anonymous membership proofs (which would remove even that) are future work, not shipped.
No. Every text message is padded out to a standard size before it's sealed, so its length reveals nothing, the server can't tell a one-word reply from a long paragraph by measuring it. (Attachments are handled separately and aren't padded.)
Text plaintext is padded to fixed size buckets before MLS encryption (pollis-core/src/commands/messages/framing.rs), so ciphertext size no longer correlates with message length. Attachments are the exception, they're shared via convergent encryption keyed on real file size, so they aren't bucketed.
No. The real-time "new message" ping that tells your app to go fetch something no longer carries who sent it. It's just a nudge, your device learns the real sender only after it opens the sealed message.
The realtime signalling payload for new_message is stripped of sender_id, it's a wake-up ping only, and the recipient re-derives the sender from the decrypted MLS envelope. Same metadata-minimization work as sealed sender.
Pollis detects it automatically and warns you. A red shield appears next to that person's name in every conversation you share (direct messages, group member lists, channels) and an inline notice shows up in the chat so you can re-verify them out-of-band (in person, by phone, however you trust).
You only need to verify a person once. After that, the green shield follows them everywhere they appear in your account. If their key ever changes, all those shields turn red at the same moment.
Signal-style 60-digit safety numbers derived from both parties' account_id_pub (SHA-512^5200, see pollis-core/src/commands/safety.rs). First-seen keys are pinned silently (TOFU) and surfaced on mismatch via a KeyChanged realtime event. Pinning runs on every DM ingest and on every group-reconcile commit (batch_check_and_pin_account_keys), so a Turso-side key swap is caught regardless of conversation type. Verification state lives in contact_verification keyed by peer_user_id (not per-conversation), which is what gives the per-user "shield follows the contact" behavior.
You will likely lose your old messages. This is on purpose.
A new device only sees messages sent after it's added. Resetting your account wipes prior messages. We don't back up your history to the cloud, because doing so would be a target for attackers and subpoenas.
If you need a permanent archive of everything you've ever said, Pollis isn't the right tool.
Message history is not a product guarantee. A new device joining an existing MLS group receives keys for the current epoch only, no historical backfill. Identity reset wipes local message storage. No encrypted cloud backup (no Megolm-style key-backup), and none is planned. This is explicit in CLAUDE.md as a design principle: simpler model, smaller attack surface, no key escrow.
macOS, Windows, and Linux.
macOS (universal binary, Apple Silicon + Intel), Windows x64, Linux (.deb, .rpm, .AppImage, AUR). Binaries are code-signed: Apple Developer ID on macOS, Azure Trusted Signing on Windows.
No.
No. Voice/media is implemented directly in Rust (not in the webview), so mobile isn't a UI-only port, it would require native clients.
The source is public on GitHub. You can read it, build it, and check our work.
Source lives at github.com/actuallydan/pollis. Check the repo for the current license.
Pollis publishes a fingerprint of every version it releases into a public, tamper-evident log. A small tool, pollis-verify, lets anyone confirm that the app they're running is one Pollis has publicly published, so nobody can quietly slip a single person a tampered build without it either showing up in that public log forever or being conspicuously missing from it.
Honest caveat: this proves the app matches what Pollis published, not yet that those bytes were built from the public source. Letting outsiders rebuild it byte-for-byte and confirm the match is still being worked on.
Binary transparency (shipped). Each released artifact's hashes plus its build recipe are appended to an append-only log at verify.pollis.com/v1/binaries, anchored to a pinned Ed25519 key (175ebfef…7148). pollis-verify release <tag> checks a build against the log, trusting only that key rather than Pollis's word.
Not yet shipped: byte-for-byte reproducible builds, a second Pollis-independent signature anchor, and an in-app "verify this build" button.
Yes.
Yes.
Pollis is built around group chats. MLS is a newer standard designed for groups; Signal's protocol is great for 1:1 but gets slow and expensive at group scale.
MLS (RFC 9420) provides a single group key ratchet with O(log n) membership changes. Signal's Double Ratchet pairwise-ratchets between every member, so a group of N costs O(N) per sender per message. For a Slack-style product with large channels, MLS is the right primitive.
Yes, we need it to send you sign-in codes. No phone number required.
Yes. Email OTP is the auth primitive, so the email is stored server-side to deliver the OTP and bind it to the account. Session tokens are held in the OS keystore.
Anyone can create a group inside the app. To add someone, invite them by their Pollis username, they need an account already.
Groups are created via the create_group backend command; members are added by username via invite_to_group. Adding someone generates an MLS Welcome that seeds their device into the group ratchet at the current epoch. DMs are implemented as 2-person MLS groups.
You won't be able to send or receive new messages until it's back, but you can still open the app and read what you already have. A server outage is never a privacy problem, only a reachability one.
The server is required for message delivery, MLS commit routing, and R2 uploads. Read-only operation against the local encrypted SQLite store still works during an outage. Because the server can't decrypt, downtime has no confidentiality impact.
Files are encrypted on your device before upload. The storage provider only ever sees scrambled bytes; only people in the group can decrypt them.
Attachments are encrypted client-side and uploaded to Cloudflare R2. The decryption key travels inside the MLS-encrypted message, so R2 only ever holds ciphertext. Recipients fetch by key and decrypt locally.
Pollis is in open preview and has not been independently audited. If your physical safety depends on unbreakable communication, use a mature, audited tool built for that threat model.
Open preview status, no third-party cryptographic audit yet. Protocol choices (MLS, keystore-backed identity, client-side encryption) target a Slack-style workspace threat model, not a nation-state adversary. For high-risk use, pick a tool with a documented audit history.