Even though EU-wide GDPR legislation to ensure users' privacy and data protection was adopted, the centralisation of the communication in a small number of platforms makes resolving these problems quite difficult.
While it is not required to be supported in the v1 of the protocol, it is important to have clarity on how all these scenarios can be supported in the future.
- Each user can be connected to multiple servers to ensure message delivery, even if some of the servers are compromised.
- Uses standard asymmetric cryptographic protocols, so that system users can create independent server and client implementations complying with the protocols.
- Only client applications store user profiles, contacts of other user profiles, messages; servers do NOT have access to any of this information and (unless compromised) do NOT store encrypted messages or any logs.
- Multiple client applications and devices can be used by each user profile to communicate and to share connections and message history - the devices are not known to the servers.
- Initial key exchange and establishing connections between user profiles is done by sharing QR code via any independent communication channel (or directly via screen and camera), system servers are NOT used for key exchange - to reduce risk of key substitution in [MITM][2] attack. QR code contains the connection-specific public key and other information needed to establish connection.
- Connections between users can be established via shared trusted connections to simplify key exchange.
- Public keys used between connections are regularly rotated to prevent decryption of the full message history ([forward secrecy][4]) in case when some servers or middlemen preserve message history and the current key is compromised.
- No single server in the system has visibility of all connections or messages of any user, as user profiles are identified by multiple rotating public keys, using separate key for each profile connection.
- User profile (meta-data of the user including non-unique name / handle and optional additional data, e.g. avatar and status) is stored in the client apps and is shared only with accepted user profile connections.
Simplex messaging servers can be either available to all users or only to users who have a valid URI to create connections (see [simplex messaging protocol][6]).
- generate and show QR code with connection-specific public key and other information that can be shown on the screen and/or sent via alternative channel.
The chat system design is based on 2 protocols, each with the generic part, describing protocol flow and logic, and implementation part, describing protocol transports, data structures and algorithms.
1. [simplex messaging protocol][6] - a low level generic messaging protocol that defines establishing and using a simplex connection between chat participants on a single server. While this protocol is designed to support graph-chat client protocol (below), it can be used for other messaging scenarios, not limited to chats.
2. [simplex messaging protocol implementation][7] - requirements to clients and servers implementing simplex messaging protocol, including:
- other requirements for simplex messaging servers.
3. [graph-chat protocol][8] - a high level generic chat protocol for client applications (graph vertices) that communicate via simplex connections created using simplex messaging protocol. This protocol defines connection and message types and semantics for:
