How Firefly Keeps Your Team Group Chats Completely Private and Secure

When communication happens online, privacy cannot depend on corporate promises or privacy policy updates. It requires mathematical boundaries enforced before any byte leaves your device. Firefly is Lupyd's zero-knowledge messaging engine, written from scratch in Rust and engineered around the IETF Messaging Layer Security (MLS) standard.

What Is Firefly?

Firefly is the cryptographic engine for direct conversations, group workspaces, real-time message relays, and identity management across Lupyd. Built atop the high-performance Hyper asynchronous runtime and serialized using Protocol Buffers, Firefly handles high throughput while maintaining strict architectural blindness to payload content.

Traditional chat servers inspect message payloads to index search terms, run sentiment analysis, inject advertising, and moderate conversations server-side. Firefly inverts this model: its data pipeline cannot parse the plaintext payloads passing through it. Every message routed by Firefly is an authenticated ciphertext envelope readable solely by authorized endpoint devices.

Why Group Messaging Needed the MLS Protocol

Pairwise protocols like the Signal protocol excel at one-to-one communication. However, scaling pairwise encryption to multi-member groups creates exponential inefficiencies: a group of 50 people requires dozens of individual cipher encryptions per send, and adding or removing a member demands heavy key-resharing sessions.

MLS solves this bottleneck through a tree-based key agreement (TreeKEM) structure. Each group member occupies a specific leaf node in a balanced binary tree, deriving shared session secrets along their copath up to the tree root:

• Efficient Member Additions: Inviting a new member requires only a single Welcome package and an epoch commit rather than individual renegotiations with every participant.
• Instant Cryptographic Eviction: Removing a member immediately updates the tree path. The former member loses the mathematical capability to decrypt any subsequent epoch messages.
• Automated Epoch Ratcheting: Every proposal and commit cycles the cryptographic epoch, delivering forward secrecy and post-compromise security continuously.

Firefly integrates MLS via mls-rs using the RustCrypto provider, running production ciphersuites for key derivation, signature verification, and credential lifecycle management entirely independent of server knowledge.

Zero-Knowledge Architecture: The Blind Relay

When you publish a message in a Lupyd workspace, your endpoint client encrypts the payload using the current group epoch secret. What travels over the transport layer is an opaque GroupMessage binary blob.

Firefly's role is strictly that of a blind courier:

• Commit Buffering: Stores encrypted epoch commits so offline devices can synchronize historical state transitions upon reconnecting.
• Welcome Delivery: Delivers signed Welcome bundles to invited devices so they can initialize their local tree state.
• Key Package Directory: Stores public key packages to allow initial session handshakes without possessing private keys.
• Epoch Sequencing: Verifies monotonic epoch sequence numbers to prevent packet replay, operating strictly on numerical counters rather than payload inspection.

Because private keys are generated on physical endpoints and never leave hardware boundaries, even a complete host breach of the relay database yields only encrypted noise.

Credentials and Cryptographic Identity

Every participant in Firefly operates with a distinct FireflyIdentity containing a signature key pair and a time-bound signed credential. During initialization, the client generates its signing keys locally, submits only the public key component to the signing endpoint, and receives a scoped authentication token containing its device ID, address ID, and expiration.

This credential sits within the user's leaf node in the MLS tree. Whenever a message is received, recipient devices verify the credential signature directly against Firefly's public JWK set (/jwks.json). Tampered or expired credentials cause immediate rejection at the client layer, removing server judgment from the trust chain.

Cryptographic Group Governance

Firefly groups are not basic chat rooms governed by database flags. They are self-governing cryptographic structures with role matrices and channel access controls embedded directly into the MLS group context via FireflyGroupExtension:

• Role Definitions: Granular permissions covering membership modification, channel creation, and administrative rights.
• Permission Matrices: Default capability assignments for incoming members and customized channel rules.
• Proposal Verification: Structural changes (such as member additions or role modifications) are executed as custom MLS proposals.

Firefly's rule engine (FireflyMlsRules) mandates that each proposal be mathematically verified by every client device prior to committing the epoch. If an unauthorized participant attempts an administrative action, member clients reject the commit independently. Security is maintained by collective consensus rather than server compliance.

Systems Engineering in Rust

Firefly is written in Rust to guarantee memory safety at compile time, eliminating critical vulnerabilities like buffer overflows, dangling pointers, and data races. Operating on Hyper and Tokio, it combines HTTP/2 and WebSocket connections on a unified listener, using Protobuf serialization to avoid the parsing overhead and ambiguities common in text-based APIs.