Private conversations without permanent accounts.

Session Chat is being built as a temporary, encrypted room for two people. One person creates the room, shares a private invitation, approves the other device, and ends the session when the conversation is over.

See the session flow Inspect current evidence

How one conversation moves through the system.

Creating an invitation, approving a device, adding it to the encrypted group, delivering messages, and ending the session are separate actions. A copied link or compromised service should not gain all of those powers at once.

1.0 · invite
Alice creates a short-lived invitation.
The signed invitation tells Bob how to ask for access, but it does not contain the conversation keys. Its capability is the secret value that grants the right to make that request, so Alice must share it privately.
BoundaryInvitationDescriptor
2.0 · request
Bob asks to join with one exact device key.
His request is tied to the invitation and to one exact MLS KeyPackage: the public cryptographic material for that device. Replaying the request or substituting another key must fail.
Current evidenceRFC 9180 PSK open
3.0 · approve
Alice reviews the request and chooses.
A valid proof shows that the request matches the invitation and device key. It does not prove Bob is trustworthy or add him to the group. The prototype simulates Alice’s decision because the approval screen is not built yet.
AuthorityApprovalContext ≠ membership
4.0 · join
The encrypted group adds only the approved device.
Messaging Layer Security (MLS) consumes the approved KeyPackage once, adds that device, and creates its encrypted Welcome message. The invitation protects first contact; MLS protects group membership and later messages.
Current evidenceAdd → Commit → Welcome
5.0 · talk
Transport carries opaque envelopes, not chat text.
A transport can move data but cannot approve a person or add a device. The memory adapter tests loss, duplication, delay, reordering, retry, expiry, and separate mailbox rights; the authenticated Iroh adapter adds experimental connected FastV1 delivery.
Current limitno offline or durable network profile
6.0 · end
Removing a device blocks it from future messages.
The in-memory MLS test proves that a removed device cannot derive later message keys. A future app may delete its own keys and stored copies, but it cannot erase plaintext that another participant saved.
Current evidenceremove → update → reject

What the design protects—and what it cannot.

Message encryption, identity evidence, network privacy, and local deletion solve different problems. The product must explain each guarantee on its own.

Target protections for the finished product

Keep message content hidden from mailbox, relay, and realm services.
Stop copied invitations or substituted device keys from silently changing membership.
Never let Private mode silently fall back to a more revealing transport.
Use a new cryptographic identity for each session instead of a permanent chat identity.
Limit how much parsing, storage, retry, and unauthenticated work hostile input can trigger.

Limits that remain

A participant can copy, export, photograph, or screenshot plaintext.
Malware controlling an unlocked device can read what the user can read.
Proof that someone controls an account does not prove they are trustworthy.
Different transport modes expose different amounts of IP, timing, and volume metadata.
A network or service operator can still refuse or disrupt service.

Check the evidence behind each claim.

The repository marks each property as implemented and tested, required but unimplemented, proposed, deferred, or out of scope. This site uses the same evidence states.

Read the security model →

Private conversations without permanent accounts.

How one conversation moves through the system.

Alice creates a short-lived invitation.

Bob asks to join with one exact device key.

Alice reviews the request and chooses.

The encrypted group adds only the approved device.

Transport carries opaque envelopes, not chat text.

Removing a device blocks it from future messages.

What the design protects—and what it cannot.

Target protections for the finished product

Limits that remain