Design and Functionality

Cryptocat's functionality aims to focus more on ephemeral properties and ease of use than other encrypted XMPP chat solutions.

Table of Contents

1. Table of Contents
2. High-level overview
3. Detailed overview
   1. Client-specific notes
   2. Server-specific notes

Needs more elaboration everywhere!
Contribute your thoughts!

---

High-level overview

From a user perspective, Cryptocat 2 will function in a very similar manner to previous Cryptocat iterations.

1. The user provides the Cryptocat client with a room name and a personal nickname.
2. The client joins the room, and lists the room's occupants to the user.
3. The user may then chat inside the room with all users, or have private, one-to-one conversations with single users at their choosing.
4. All conversations are end-to-end client-side encrypted with OTR or mpOTR (multi-party OTR).

Detailed overview

Connecting: Chronological Overview

1. User provides client with room name and personal nickname.
2. Client generates OTR key pair.
3. Client generates XMPP username and password (both 256 random alphanumeric bytes) and uses them to register a new user on the XMPP server using XEP-0077.
4. User's public OTR key is sent to the server. I made these steps up as an example of a way to not have a buddy list - they aren't actually a good idea as they stand; an OTR key and a jabber id shouldn't be tied together in a way the server sees
5. Server offers client OTR key challenge to prove that client owns the private key to the sent public key.
6. If challenge is answered successfully, server assigns XMPP identity based on user's public key to user.
7. User joins room. Rooms are XMPP MUC instances (XEP-0045).
8. mpOTR key exchange occurs. User communicate their nicknames to each other through this key exchange, so that nicknames remain invisible to the server.

Client-specific notes

1. It is not possible to disable OTR/mpOTR. Unencrypted messages are rejected.
2. UI elements may be used to account for certain OTR/mpOTR properties. For example, each mpOTR message may be accompanied with a progress bar that shows the authentication progress for the message.
3. Should expose OTR public keys for off-line verification

Server-specific notes

1. XMPP servers will need to be modified to support authenticating through OTR public/private key pair verification. Backwards compatibility with existing XMPP servers is worth investigating.