Know who is
in the circle.

01 / AROUND THE SAME TABLE

Try it with your friends

The lab demo plays all three people on one page. Start with friends gives each person their own device session. Both use real encryption. Neither changes the privacy of ordinary IRC channels.

1. Sign in on every phone.

   Open IRC in each person's browser. First-time users need the IRC owner's approval before they can participate. Sharing a room link does not skip that step. Keep this guide in a separate tab.

2. One person opens a room.

   Choose Start with friends, then Copy room link. Share the complete link privately with the people present. Everyone else opens that link, not a fresh room. Keep the part after the #; it carries the room's access token.

3. Create and check every device.

   Enter your name and choose Create this device. Open Show my QR & pairing code. Everyone scans every other person's screen with Use camera, checks the person, then taps Verify this device. Verification goes both ways. With three people, each person verifies two others.

   If the camera fails, copy and paste the full pairing code and compare it directly with the other person's screen. A familiar display name alone is not enough. Codes expire after ten minutes.

4. Agree on exactly the same circle.

   Once everyone has verified everyone, one person taps Propose this group. The others tap Join proposed group. Compare the names and the entire transcript fingerprint on every device. If they match your intended group, everyone taps Confirm this roster. Finish within five minutes.

5. Wait for confirmation, then send.

   Every device should say Circle confirmed. Send an invented message and check that everyone receives it. Keep the tabs open. Reloading, closing the tab, or the phone discarding the page loses that device's keys and history.

02 / MATCH THE DEVICE TO THE PERSON

A QR code is a check on the keys

Each session creates private keys in the browser and a public enrollment card. The card contains its device ID, name, public keys, an MLS joining package, room, and expiry. The QR carries a fingerprint of that entire card, plus the room and device ID. Your browser fetches the card and checks it against the fingerprint you received directly.

If a relay substitutes different keys, the fingerprint check fails. A copied name cannot pass that check on its own. But someone can forward a QR code from elsewhere: the software cannot measure physical presence. Looking at the person and their screen is your part of the process. There is no Bump gesture, Bluetooth discovery, or offline peer-to-peer transport in this version.

These are Together's application rules. MLS leaves decisions about identity and membership policy to the application. RFC 9750, access control

03 / FOUR DIFFERENT JOBS

The math, gently

1. Hashes make changes detectable.

A hash turns data into a fixed-length fingerprint. SHA-256 produces 256 bits, displayed here as 64 hexadecimal characters. The same input produces the same result; finding different data with the same result is intended to be computationally infeasible. A hash does not encrypt its input or tell you who wrote it. NIST, Secure Hash Standard

2. Key agreement creates a shared secret.

A device keeps a private number and publishes a related public value. Two devices can combine their own private value with the other's public value to reach the same secret, without sending that secret over the network. X25519 is the elliptic-curve method used in Together's MLS suite. RFC 7748, X25519 key agreement

3. Signatures record a device's approval.

A private signing key creates a signature for a particular record. The matching public key checks it. Changing the record invalidates the signature. Ed25519 is the signature scheme used here. A valid signature is evidence about a device key, not a person's legal identity or truthful intentions. RFC 8032, Ed25519

Together uses a separate signing key for its consent receipts. Each receipt covers the exact proposed change or the resulting group checkpoint, so a “yes” to one roster cannot be reused as a “yes” to another.

4. Encryption protects message contents.

AES-128-GCM turns message bytes into ciphertext with an authentication tag. The receiver uses the correct key to recover the message and check that it has not been altered. NIST, authenticated encryption with GCM

Key derivation makes separate keys for separate purposes from secret material and context. HKDF is the derivation method in this suite. Sharing a hash fingerprint does not reveal those secret keys. RFC 5869, HKDF

Messaging Layer Security, or MLS, coordinates these jobs for a group. It arranges member secrets in a tree and advances to a new epoch, a version of the group's cryptographic state, when a membership change is committed. Its key schedule derives encryption keys; it is more than one permanent password shared by everyone. RFC 9420, protocol overview

Together runs OpenMLS in WebAssembly inside each browser. OpenMLS implements the MLS protocol. Our browser wrapper and consent rules are additional code; using an established library does not independently validate that code.

04 / WHO AGREED TO WHAT?

A history of consent

Together keeps a linked record of membership decisions. Each new decision refers to the fingerprint of the previous checkpoint. Devices verify the signatures and links, then confirm the actual resulting MLS state. This is the circle's lineage. It is Together's experimental policy, not a requirement of MLS.

To add someone, every existing member verifies and approves the new device; everyone in the resulting group confirms. To remove someone, every remaining member approves and confirms, with at least two remaining. The person being removed has no veto. A two-person circle must start over instead of removing one person.

After the removal completes, Charlie's device cannot decrypt subsequent messages. It can still read messages it already received. A newly admitted device gets the signed membership history, but not earlier chat messages or their keys. These are behaviors exercised by this experiment's browser tests.

05 / THE BOUNDARY OF THE PROMISE

Private content isn't invisible activity

Your browser encrypts before sending. IRC's relay delivers ciphertext. Internet access is required, even around the same table; the phones do not connect directly to each other.

MLS distinguishes message confidentiality from metadata privacy. Its forward-secrecy and recovery guarantees depend on correct key updates, deletion, and secure endpoints. This experiment does not establish secure memory erasure or recovery after device compromise. RFC 9420, security considerations