Rename edge-messaging to simplex messaging (#15)

* rename edge-messaging protocol related files

* rename edge-messaging protocol to simplex messaging protocol

* adjust wordings for simplex connections

graph-chat.md

@@ -1,6 +1,6 @@
 # Graph-chat protocol
 
-A generic chat protocol for client applications that communicate via edge-messaging protocol
+A generic chat protocol for client applications that communicate via simplex messaging protocol
 
 
 ## Problems of the existing chat platforms and protocols
@@ -8,8 +8,8 @@ A generic chat protocol for client applications that communicate via edge-messag
 - Dependency on a single company/server to access and use chat. That creates implications for chat privacy, user profile resilience and data ownership.
 - Visiblity of user profile information to chat system and other chat users. Chat users have limited control as to who can see and find their profile.
 - Visibility of user contacts graph to chat server.
-- [E2EE][1] can be compromised by [MITM][2] attack (see [edge-messaging protocol][3]).
-- Identity related problems (also see [edge-messaging protocol][3]).
+- [E2EE][1] can be compromised by [MITM][2] attack (see [simplex messaging protocol][3]).
+- Identity related problems (also see [simplex messaging protocol][3]).
 
 
 ## Graph-chat protocol abstract
@@ -19,16 +19,16 @@ TODO
 
 ## Duplex connection
 
-Majority of chat scenarios requires duplex (bi-directional) connections between participants. Graph-chat protocol uses multiple unidirectional connections (graph edges) created on multiple edge-messaging servers to implement duplex connections.
+Majority of chat scenarios requires duplex (bi-directional) connections between participants. Graph-chat protocol uses multiple simplex (unidirectional) connections created on multiple simplex messaging servers to implement duplex connections.
 
-Each duplex connection consists of one or multiple, for redundancy, pairs of unidirectional connections to connect chat participants or devices of the same participant - it is used for "contacts", "devices", "group participants", etc. For practical purposes of redundancy, chat clients can use 2-4 pairs of unidirectional connections.
+Each duplex connection consists of one or multiple, for redundancy, pairs of simplex connections to connect chat participants or devices of the same participant - it is used for "contacts", "devices", "group participants", etc. For practical purposes of redundancy, chat clients can use 2-4 pairs of simplex connections.
 
-The process described below establishes a duplex connection between Alice and Bob that has `n` unidirectional connections `CAi` (where `1 <= i <= n`) from Bob to Alice (created by Alice on her servers) and `n` unidirectional connections `CBi` (where `1 <= i <= n`) from Alice to Bob (created by Bob on his servers).
+The process described below establishes a duplex connection between Alice and Bob that has `n` simplex connections `CAi` (where `1 <= i <= n`) from Bob to Alice (created by Alice on her servers) and `n` simplex connections `CBi` (where `1 <= i <= n`) from Alice to Bob (created by Bob on his servers).
 
 The following symbols are used below:
-- unidirectional edge-messaging connections:
-  - `CAi` - Alice's edge-messaging connection number `i` (out of `n`) allowing Bob to send messages to Alice.
-  - `CBi` - Bob's edge-messaging connection number `i` (out of `n`) allowing Alice to send messages to Bob.
+- simplex connections:
+  - `CAi` - Alice's simplex connection number `i` (out of `n`) allowing Bob to send messages to Alice.
+  - `CBi` - Bob's simplex connection number `i` (out of `n`) allowing Alice to send messages to Bob.
 - keys created for Alice's connections:
   - `EKAi` - Alice's assymetric key pair used:
     - by Bob to encrypt and by Alice to decrypt messages from Bob sent via `CAi`.
@@ -54,7 +54,7 @@ The following symbols are used below:
 To create a duplex connection initiated by Alice, Alice's and Bob's apps follow these steps:
 
 1. Alice's app initiates duplex connection:
-   1. it creates `n` unidirectional connections ("edges") `CAi` (step 1 in [edge-messaging][3]) that are defined by:
+   1. it creates `n` simplex connections `CAi` (step 1 in [simplex messaging][3]) that are defined by:
       - client-generated:
          - Alice's asymmetric key pairs `EKAi` to encrypt messages.
          - connection IDs `IDAi`.
@@ -62,19 +62,19 @@ To create a duplex connection initiated by Alice, Alice's and Bob's apps follow
       - server-generated:
          - recipient URIs `RUAi`.
          - sender URIs `SUAi`.
-   2. optionally, Alice's app subsribes to receive messages from these new connections `CAi` ([edge-messaging protocol implementation][4] defines protocol to be used for subscriptions).
-2. Alice's app sends a secure message to Bob's app (step 2 in [edge-messaging][3]):
+   2. optionally, Alice's app subsribes to receive messages from these new connections `CAi` ([simplex messaging protocol implementation][4] defines protocol to be used for subscriptions).
+2. Alice's app sends a secure message to Bob's app (step 2 in [simplex messaging][3]):
    1. it prepares the message with the information needed to establish all connections `CAi`, including all encryption keys `EKAi` and sender connection URIs (`SUAi`).
    2. depending on the communication scenario, Alice's app sends this message to Bob's app in one of available secure ways (either out-of-band or via available secure duplex connection(s) - see [Duplex connection security level](#TODO)), depending on communication scenario:
-      - if Bob is a new contact, the information is presented as a visual code (e.g. QR code(s)) to Bob's app - as out-of-band message needed to establish connections `CAi` (see [edge-messaging protocol][3] and [Adding direct contact](#adding-direct-contact)).
+      - if Bob is a new contact, the information is presented as a visual code (e.g. QR code(s)) to Bob's app - as out-of-band message needed to establish connections `CAi` (see [simplex messaging protocol][3] and [Adding direct contact](#adding-direct-contact)).
       - if Bob is added to group chat with Alice by some contact of Alice or Bob, this information can be passed through all possible chains of contacts between Alice and Bob in the group (to minimise the risk of MITM attack) (see [Group chat](#TODO)).
       - if Alice adds Bob as a contact via Bob's trusted contact John, who also has Alice as a trusted contact, this information will be passed via John (who has secure duplex connections with both Alice and Bob), in the same way as with Group chat (see [Trusted contacts](#TODO)).
       - if Alice already has Bob as a contact, and she wants to create a separate off-the-record chat with him, this information will be passed via their existing connection (see [Off-the-record chat](#TODO)).
-      - etc. In all cases, the protocol defines the most secure possible way to pass the out-of-band (from the point of view of the new connections) message required by [edge-messaging protocol][3] to create unidirectional connections.
+      - etc. In all cases, the protocol defines the most secure possible way to pass the out-of-band (from the point of view of the new connections) message required by [simplex messaging protocol][3] to create simplex connections.
 3. Bob's app accepts duplex connection with Alice:
    1. it receives the message from Alice's app, in a way defined by a specific chat scenario.
-   2. it interprets the received information as edge-messaging protocol out-of-band messages to accept all unidirectional connections `CAi`.
-   3. it creates `n` new unidirectional connections `CBi` on Bob's servers defined by:
+   2. it interprets the received information as simplex messaging protocol out-of-band messages to accept all simplex connections `CAi`.
+   3. it creates `n` new simplex connections `CBi` on Bob's servers defined by:
       - client-generated:
          - Bob's asymmetric key pairs `EKBi` to encrypt messages.
          - connection IDs `IDBi`.
@@ -82,26 +82,26 @@ To create a duplex connection initiated by Alice, Alice's and Bob's apps follow
       - server-generated:
          - recipient URIs `RUBi`.
          - sender URIs `SUBi`.
-   4. optionally, Bob's app subsribes to receive messages from these new connection `CBi` (see [edge-messaging protocol implementation][4]).
-   5. it proceeds with accepting Alice's app connections `CAi` (step 3 in [edge-messaging protocol][3]).
+   4. optionally, Bob's app subsribes to receive messages from these new connection `CBi` (see [simplex messaging protocol implementation][4]).
+   5. it proceeds with accepting Alice's app connections `CAi` (step 3 in [simplex messaging protocol][3]).
    6. in response to each connection `CAi`, as optional information, Bob's app includes:
       - Bob's user profile (that is only stored in graph-chat client and not visible to any server)
       - information to establish connection `CBi`:
          - encryption key `EKBi`.
          - sender connection URIs (`SUBi`).
-   7. his app now sends the unsigned requests to Alice's connections `CAi` (step 3.4 in [edge-messaging protocol][3]), to both confirm the connections `CAi` and to propose the new connections `CBi`. As each message is encrypted by the key `EKAi` of the connection `CAi` that only Alice can decrypt, it is safe to send it - from edge-messaging server point of view it is an out-of-band message.
+   7. his app now sends the unsigned requests to Alice's connections `CAi` (step 3.4 in [simplex messaging protocol][3]), to both confirm the connections `CAi` and to propose the new connections `CBi`. As each message is encrypted by the key `EKAi` of the connection `CAi` that only Alice can decrypt, it is safe to send it - from simplex messaging server point of view it is an out-of-band message.
 4. Alice's app adds Bob's duplex connection:
-   1. it receives the messages from Bob via connections `CAi` (step 4 in [edge-messaging protocol][3]).
+   1. it receives the messages from Bob via connections `CAi` (step 4 in [simplex messaging protocol][3]).
    2. depending on chat scenario, Bob is identified and confirmed:
       - for new contact, Alice may visually identify Bob's user profile and accepts Bob as a contact.
       - for group participant, Alice's app will match known Bob's user profile ID with received user profile ID (that is only visible to the clients apps that have this profile).
-   3. it secures the connections `CAi` with keys `SKAi` received from Bob - the connections are now established (step 5 in [edge-messaging protocol][3]).
-   4. it accepts the connections `CBi`, including in the response to Bob's server Alice's user profile and (as the additional information) the confirmation that the connections `CAi` are secured and can be used (step 3 in [edge-messaging protocol][3]).
+   3. it secures the connections `CAi` with keys `SKAi` received from Bob - the connections are now established (step 5 in [simplex messaging protocol][3]).
+   4. it accepts the connections `CBi`, including in the response to Bob's server Alice's user profile and (as the additional information) the confirmation that the connections `CAi` are secured and can be used (step 3 in [simplex messaging protocol][3]).
    5. it sends the unsigned messages via connections `CBi`.
    6. it adds Bob's duplex connection to the list of available duplex connections as "pending" (Alice cannot yet send messages to Bob, but Bob already can send messages to Alice). Possibly, the status of duplex connection can indicate that Bob already can send messages to Alice.
 5. Bob's app adds duplex connection with Alice:
    1. it receives the initial messages via connections `CBi`.
-   2. it secures the connections `CBi` - they are now established as well (step 5 in [edge-messaging protocol][3]).
+   2. it secures the connections `CBi` - they are now established as well (step 5 in [simplex messaging protocol][3]).
    3. it adds duplex connection with Alice in the list of available duplex connections as "pending" (to indicate that Alice cannot yet send messages). Possibly, the status of duplex connection can indicate that Bob already can send messages to Alice.
    4. it sends a special message (message type "welcome") to Alice's app via duplex connection (i.e., via all connections `CAi`) to confirm that adding Alice's contact is completed (see [Sending messages via duplex connection](#TODO)).
 6. Alice's app finalises adding duplex connection with Bob:
@@ -159,7 +159,7 @@ When Alice sends the message to Bob via the duplex connection, they follow these
 
 "Direct contact" is a term used for a duplex connection with another chat user established directly, not via another user. Establishing contact requires sending an out-of-band message - "visual code" (e.g. QR code(s)) is used for this purpose. 
 
-For example, Alice and Bob want to have a conversation in chat app, exchanging messages with each other. They both have graph-chat client and access to several edge-messaging servers (see [edge-messaging protocol][3]) that they can use to receive messages, and their graph-chat clients are configured to use these servers.
+For example, Alice and Bob want to have a conversation in chat app, exchanging messages with each other. They both have graph-chat client and access to several simplex messaging servers (see [simplex messaging protocol][3]) that they can use to receive messages, and their graph-chat clients are configured to use these servers.
 
 To chat in the app Alice needs to add Bob as "direct contact" to her contacts in the app.
 
@@ -167,7 +167,7 @@ To chat in the app Alice needs to add Bob as "direct contact" to her contacts in
 2. Alice shares "visual code" (e.g. QR code(s)) with Bob:
    1. her app prepares secure message to establish duplex connection with Bob's app (step 1 in [Creating duplex connection](#creating-duplex-connection)).
    2. her app prepares and displays a visual code with this message (step 2 in [Creating duplex connection](#creating-duplex-connection)).
-   3. Alice now can share this visual code with Bob, either in person or via a video call (see [edge-messaging protocol][3]).
+   3. Alice now can share this visual code with Bob, either in person or via a video call (see [simplex messaging protocol][3]).
 3. Bob reads "visual code" that Alice prepared via his app:
    1. he initiates adding "direct contact" via visual code in his graph-chat client app.
    2. his app interprets this visual code as secure message required to accept duplex connection with Alice and proceeds with creating duplex connection (step 3 in [Creating duplex connection](#creating-duplex-connection)).
@@ -205,8 +205,8 @@ Control messages:
 - "receipt" - acknowledging message receipt.
 - "contact: update" - changing "contact" profile .
 - "profile" - changing "contact 
-- "gm: add" - sent to add unidirectional edge-messaging connection to graph-chat duplex connection.
-- "gm: remove" - sent to remove unidirectional edge-messaging connection from graph-chat duplex connection.
+- "gm: add" - sent to add simplex connection to graph-chat duplex connection.
+- "gm: remove" - sent to remove simplex connection from graph-chat duplex connection.
 
 Content messages:
 
@@ -216,5 +216,5 @@ Content messages:
 
 [1]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
 [2]: https://en.wikipedia.org/wiki/End-to-end_encryption
-[3]: edge-messaging.md
-[4]: edge-messaging-implementation.md
+[3]: simplex-messaging.md
+[4]: simplex-messaging-implementation.md

readme.md

@@ -10,8 +10,8 @@ Existing chat platforms and protocols have some or all of the following problems
 - complexity of usage for all non-centralised protocols to all non-technical users
 
 Some of these problems are covered in more details in the proposed protocols on which this chat system will be based on:
-- [edge-messaging][6] - low level client-server protocol for asynchronous distributed unidirectional messaging
-- [graph-chat][8] - high level chat protocol for client applications that communicate via edge-messaging protocol
+- [simplex messaging][6] - low level client-server protocol for asynchronous distributed unidirectional messaging
+- [graph-chat][8] - high level chat protocol for client applications that communicate via simplex messaging protocol
 
 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.
 
@@ -68,13 +68,13 @@ While it is not required to be supported in the v1 of the protocol, it is import
 
 ## System components
 
-- edge-messaging servers
-- graph-chat client applications (using edge-messaging protocol to communicate with the servers)
+- simplex messaging servers
+- graph-chat client applications (using simplex messaging protocol to communicate with the servers)
 
 
 ### Chat servers
 
-Edge-messaging servers can be either available to all users or only to users who have a valid URI to create connections (see [edge-messaging protocol][6]).
+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]).
 
 
 ### Chat client application
@@ -101,19 +101,19 @@ Client apps should provide the following features:
 
 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. [edge-messaging protocol][6] - a low level generic messaging protocol that defines establishing and using a unidirectional connection ("graph edge") 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. [edge-messaging protocol implementation][7] - requirements to clients and servers implementing edge-messaging protocol, including:
+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:
    - cryptographic algorithms to sign/verify requests and to encrypt/decrypt messages.
    - privacy requirements to the servers.
    - REST API for connections and messages.
    - WebSocket API to subscribe to connections and receive new messages.
-   - other requirements for edge-messaging servers.
-3. [graph-chat protocol][8] - a high level generic chat protocol for client applications (graph vertices) that communicate via connections (graph edges) created using edge-messaging protocol. This protocol defines connection and message types and semantics for:
+   - 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:
    - various chat elements (user profiles, direct chats, chat groups, broadcasts, etc.).
    - other communication scenarios - e.g. introduction, off-the-record chat, etc.
    - using multiple servers to ensure message delivery.
    - sharing user profiles, contacts and chats across multiple client devices.
-   - changing cryptographic keys and servers used to send and receive messages using edge-messaging server protocol.
+   - changing cryptographic keys and servers used to send and receive messages using simplex messaging server protocol.
    - sending and receiving out-of-band messages between client applications using "visual code".
 4. graph-chat client application protocol (TODO) - a high level specific chat protocol for client applications. This protocol specifies:
    - data structures for sending and receiving messages of all types.
@@ -127,6 +127,6 @@ The chat system design is based on 2 protocols, each with the generic part, desc
 [3]: https://en.wikipedia.org/wiki/Off-the-Record_Messaging
 [4]: https://en.wikipedia.org/wiki/Forward_secrecy
 [5]: https://mermaid-js.github.io/mermaid-live-editor
-[6]: edge-messaging.md
-[7]: edge-messaging-implementation.md
+[6]: simplex-messaging.md
+[7]: simplex-messaging-implementation.md
 [8]: graph-chat.md

simplex-messaging-implementation.md

@@ -1,6 +1,6 @@
-# Edge-messagng protocol implementation
+# Simplex messaging protocol implementation
 
-This document defines specific elements to be used by client and server implementations of edge-messaging protocol. This protocol relies on the connection creation and messaging flows defined in generic [edge-messaging protocol][1].
+This document defines specific elements to be used by client and server implementations of simplex messaging protocol. This protocol relies on the connection creation and messaging flows defined in generic [simplex messaging protocol][1].
 
 This document defines:
 - [cryptographic algorithms](#cryptographic-algorithms) to sign/verify requests and to encrypt/decrypt messages.
@@ -14,12 +14,12 @@ This document defines:
 - [WebSockets API](#websockets-api) to subscribe to connections:
    - to receive the new messages.
    - to update connection attributes.
-- any other requirements for edge-messaging servers
+- any other requirements for simplex messaging servers
 
 
 ## Cryptographic algorithms
 
-Edge-messaging clients need to cryptographically sign requests:
+Simplex messaging clients need to cryptographically sign requests:
 - with the recipient's key `RK` (server to verify):
    - to create connections.
    - to subscribe to connection.
@@ -46,7 +46,7 @@ Future versions of the protocol may allow different algorithms.
 
 ## Connection ID
 
-Edge-messaging clients MUST generate random unique ID for each new unidirectional connection.
+Simplex messaging clients MUST generate random unique ID for each new simplex connection.
 
 It is not required that this ID is globally unique across all clients and servers, and this ID is known only to the server on which connection is created and to the connection recipient.
 
@@ -59,7 +59,7 @@ If connection IDs do not match, the server MUST reject the request with HTTP sta
 
 ## Connection URIs
 
-Edge-messaging servers MUST generate 2 different URIs for each new connection - for recipient (that created the connection) and for sender. It is REQUIRED that:
+Simplex messaging servers MUST generate 2 different URIs for each new connection - for recipient (that created the connection) and for sender. It is REQUIRED that:
 - these URIs are different.
 - they do not contain client-generated connection ID, any keys, or key hashes.
 - based on 64(?)-bit number generated with cryptographically strong pseudo-random number generator.
@@ -71,19 +71,19 @@ Coonection URIs can be:
 
 ## Privacy requirements
 
-Edge-messaging server implementations MUST NOT:
+Simplex messaging server implementations MUST NOT:
 - create any logs of the client requests in the production environment.
 - create any history of deleted connections or retrieved (and removed) messages.
 - create any history of connection updates and store old keys or URIs.
-- create any snapshots of the database they use to store connections and messages (instead edge-messaging clients must manage redundancy by using more than one edge-messaging server, e.g., as described in [graph-chat protocol][3]).
-- create/store any other information that may undermine privacy or [forward secrecy][4] of communication between clients using edge-messaging server.
+- create any snapshots of the database they use to store connections and messages (instead simplex messaging clients must manage redundancy by using more than one simplex messaging server, e.g., as described in [graph-chat protocol][3]).
+- create/store any other information that may undermine privacy or [forward secrecy][4] of communication between clients using simplex messaging server.
 
 
 ## REST API
 
 ### General API considerations
 
-Edge-messaging server MUST provide REST API via HTTPS protocol. It MAY operate on the same domain as any other web application. It is RECOMMENDED that the endpoint to create connections and all connection URIs start from the same path, to avoid namespace conflicts with other applications.
+Simplex messaging server MUST provide REST API via HTTPS protocol. It MAY operate on the same domain as any other web application. It is RECOMMENDED that the endpoint to create connections and all connection URIs start from the same path, to avoid namespace conflicts with other applications.
 
 In case of any requests sent to unknown URIs, server MUST reject the request with HTTP status code 404 (Not Found).
 
@@ -123,9 +123,9 @@ TODO
 
 ### REST API endpoints
 
-Edge-messaging server MUST provide the API endpoints for the recipient and for the sender. The list of endpoints below has URI examples, the actual API URI schemes can differ between implementations, and even from deployment to deployment, based on server configuration.
+Simplex messaging server MUST provide the API endpoints for the recipient and for the sender. The list of endpoints below has URI examples, the actual API URI schemes can differ between implementations, and even from deployment to deployment, based on server configuration.
 
-URI scheme provides an additional layer of security to access the connection for both the sender and the recipient, and allows, if required, to implement and deploy private and commercial edge-messaging servers.
+URI scheme provides an additional layer of security to access the connection for both the sender and the recipient, and allows, if required, to implement and deploy private and commercial simplex messaging servers.
 
 `messages` path segment in all endpoints to retrieve, delete and send messages is REQUIRED and MUST NOT be changed by any implementation or deployment.
 
@@ -157,12 +157,12 @@ Server MUST define a single endpoint to create connections. This endpoint can be
 - server domain, path and secure token(s) (possibly user-specific), if the server owner wants to restrict access to creating connections (for private or commercial servers).
 - any other, potentially undiscoverable, URI that server recognises.
 
-To create a connection, edge-messaging client MUST send POST request to this endpoint, signed with the key `RK`.
+To create a connection, simplex messaging client MUST send POST request to this endpoint, signed with the key `RK`.
 
 Request body should be sent as JSON object with the following properties:
 - `connectionID` (string): new client-generated connection ID.
 - `recipient` (string): public key `RK` to verify digital signature of the recipient.
-- `sender` (string, optional): public key `SK` to verify digital signature of the sender (it can be used in the alternative flow of establishing the connection when recipient and sender exchanged two secure out-of-band messages with each other, to reduce the number of connection steps - see [edge-messaging protocol][1]).
+- `sender` (string, optional): public key `SK` to verify digital signature of the sender (it can be used in the alternative flow of establishing the connection when recipient and sender exchanged two secure out-of-band messages with each other, to reduce the number of connection steps - see [simplex messaging protocol][1]).
 - `disabled` (boolean, optional): if `true`, the connection will be created but it will not be possible for the sender to use it to send messages. It will still be possible to retrieve the available messages and to modify the connection. 
 
 Servers MUST require that connection ID is unique, and in the unlikely case of ID collision reject the connection creation request with HTTP status code 409 (Conflict).
@@ -178,7 +178,7 @@ URI: recipient connection URI `<RU>`
 
 Example: PUT `https://example.com/connection/aZ9f`
 
-To update the connection, edge-messaging client MUST send PUT request to the recipient connection URI `RU` (returned by the server when creating the connection), signed with the key `RK`.
+To update the connection, simplex messaging client MUST send PUT request to the recipient connection URI `RU` (returned by the server when creating the connection), signed with the key `RK`.
 
 Request body should be sent as JSON object with the following properties:
 - `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
@@ -200,7 +200,7 @@ URI: recipient connection URI `<RU>`
 
 Example: DELETE `https://example.com/connection/aZ9f`
 
-To delete the connection, edge-messaging client MUST send DELETE request to the recipient connection URI `RU` (returned by the server when creating the connection), signed with the key `RK`.
+To delete the connection, simplex messaging client MUST send DELETE request to the recipient connection URI `RU` (returned by the server when creating the connection), signed with the key `RK`.
 
 Request body should be sent as JSON object with the following properties:
 - `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
@@ -218,7 +218,7 @@ URI: `<RU>/messages`
 
 Example: POST `https://example.com/connection/aZ9f/messages`
 
-To retrieve messages from the connection, edge-messaging client MUST send POST request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `RK`.
+To retrieve messages from the connection, simplex messaging client MUST send POST request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `RK`.
 
 Request body should be sent as JSON object with the following properties:
 - `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
@@ -226,7 +226,7 @@ Request body should be sent as JSON object with the following properties:
 - `fromMessageID` (string, optional): if set, the server will retrieve the messages received starting from the message with server message ID (unique per server) passed in this parameter. This ID of the next available message is passed in the response to this request (if more messages are available).
 - `keepMessages` (boolean, optional):  if `true`, the server will keep the retrieved messages available in the connection to be retrieved again (or deleted via a separate request). By default the retrieved messages will be removed from the server. Clients may need to process messages in some way, and until the processing succeded clients may choose to keep messages on the server to ensure they are not lost if processing fails for any reason.
 
-Edge-messaging server MUST permanently remove the retrieved messages, unless specifically instructed by the clients to keep them.
+Simplex messaging server MUST permanently remove the retrieved messages, unless specifically instructed by the clients to keep them.
 
 __Please note__: server implementations MUST NOT track in any form how many times or whether the messages were retrieved.
 
@@ -246,16 +246,16 @@ URI: `<RU>/messages`
 
 Example: DELETE `https://example.com/connection/aZ9f/messages`
 
-To delete messages from the connection, edge-messaging client MUST send DELETE request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `RK`.
+To delete messages from the connection, simplex messaging client MUST send DELETE request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `RK`.
 
-This request SHOULD be used by edge-messaging clients to delete the previously retrived messages when `"keepMessages": true` parameter was used or in case they no longer require to retrive the messages.
+This request SHOULD be used by simplex messaging clients to delete the previously retrived messages when `"keepMessages": true` parameter was used or in case they no longer require to retrive the messages.
 
 Request body should be sent as JSON object with the following properties:
 - `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
 - `pageSize` (number, optional): if set, the server will delete up to the requested number of messages, otherwise all messages, in both cases from the message ID in `fromMessageID` parameter (or from the earliest available).
 - `fromMessageID` (string, optional): the server will delete the messages received, starting from the message with the server message ID passed in this parameter. If not specified, it defaults to the server message ID of the earliest received message.
 
-Edge-messaging server MUST permanently remove the messages as requested.
+Simplex messaging server MUST permanently remove the messages as requested.
 
 If the request is successful, the server MUST respond with HTTP status code (200) with the body that has the count of deleted messages in `deleted` property.
 
@@ -270,7 +270,7 @@ URI: sender connection URI `<SU>`
 
 Example: PUT `https://example.com/connection/bY1h`
 
-To update the connection, edge-messaging client of the sender MUST send PUT request to the sender connection URI `SU` (returned by the server to the connection recipient when creating the connection), signed with the key `SK`.
+To update the connection, simplex messaging client of the sender MUST send PUT request to the sender connection URI `SU` (returned by the server to the connection recipient when creating the connection), signed with the key `SK`.
 
 Request body should be sent as JSON object with the following properties:
 - `sender` (string, optional): the new public key `SK` to verify digital signature of the sender. This parameter is only allowed if the sender key `SK` is already available on the connection, otherwise the server MUST reject the request with HTTP status code 401 (Unauthorised).
@@ -289,7 +289,7 @@ URI: `<SU>/messages`
 
 Example: POST `https://example.com/connection/bY1h/messages`
 
-To send messages to the connection, edge-messaging client MUST send POST request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `SK`.
+To send messages to the connection, simplex messaging client MUST send POST request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `SK`.
 
 Request body should be sent as JSON object with the following properties:
 - `messages` (array): retrieved messages. Each sent message is an object with the following properties:
@@ -304,12 +304,12 @@ TODO
 
 **Simplex connection operation:**
 
-![Simplex connection operations](/diagrams/simplex2.svg)
+![Simplex connection operations](/diagrams/simplex-messaging-impl/simplex-op.svg)
 
 Sequence diagram does not show E2EE - connection itself knows nothing about encryption between sender and receiver.
 
 
-[1]: edge-messaging.md
+[1]: simplex-messaging.md
 [2]: https://tools.ietf.org/html/rfc3447
 [3]: graph-chat.md
 [4]: https://en.wikipedia.org/wiki/Forward_secrecy

simplex-messaging.md

@@ -1,4 +1,4 @@
-# Edge-messaging protocol
+# Simplex messaging protocol
 
 A generic client-server protocol for asynchronous distributed unidirectional messaging
 
@@ -15,20 +15,20 @@ A generic client-server protocol for asynchronous distributed unidirectional mes
 - [MITM attack][1]. Any mechanism of the key exchange via the same network is prone to this type of attack when the public keys of the participants are substituted with the public keys of the attacker intercepting communication. While some solutions have been proposed that complicate MITM attack (social millionaire, OTR), if the attacker understands the protocol and has intercepted and can substitute all information exchanged between the participants, it is still possible to substitute encryption keys. It means that the existing [E2EE][2] implementations in messaging protocols and platforms can be compromised by the attacked who either compromised the server or communication channel.
 
 
-## Edge-messaging protocol abstract
+## Simplex messaging protocol abstract
 
-The proposed "edge-messaging protocol" removes the need for participants' identities and provides [E2EE][2] without the possibility of [MITM attack][1] attack under one assumption: participants have an existing alternative communication channel that they trust and can use to pass one small binary message to initiate the connection (out-of-band message).
+The proposed "simplex messaging protocol" removes the need for participants' identities and provides [E2EE][2] without the possibility of [MITM attack][1] attack under one assumption: participants have an existing alternative communication channel that they trust and can use to pass one small binary message to initiate the connection (out-of-band message).
 
-The out-of band message is sent via some trusted alternative channel by the connection recipient to the connection sender. This message is used to share the encryption (a.k.a. "public") key and connection URI requried to establish a unidirectional connection:
+The out-of band message is sent via some trusted alternative channel by the connection recipient to the connection sender. This message is used to share the encryption (a.k.a. "public") key and connection URI requried to establish a unidirectional (simplex) connection:
 - the sender of the connection (who received out-of-band message) will use it to send messages to the server using connection URI, signing the message by sender key.
 - the recepient of the connection (who created the connection and who sent out-of-band message) will use it to retrieve messages from the server, signing the requests by the recepient key.
 - participant identities are not shared with the server, as completely new keys and connection URI are used for each connection.
 
-This unidirectional connection ("graph edge") is the main building block of the network that is used to build application level primitives (in graph-chat protocol) that are only known to system participants in their client applications (graph vertices) - user profiles, contacts, conversations, groups and broadcasts. At the same time, system servers are only aware of the low-level unidirectional connections (graph edges). In this way a high level of privacy and security of the conversations is provided. Application level chat primitives defined in graph-chat protocol are not in scope of this edge-messaging protocol.
+This simplex connection is the main building block of the network that is used to build application level primitives (in graph-chat protocol) that are only known to system participants in their client applications (graph vertices) - user profiles, contacts, conversations, groups and broadcasts. At the same time, system servers are only aware of the low-level simplex connections. In this way a high level of privacy and security of the conversations is provided. Application level chat primitives defined in graph-chat protocol are not in scope of this simplex messaging protocol.
 
 This approach is based on the concepts of [unidirectional networks][4] that are used for applications with high level of information security.
 
-Defining the approach to out-of-band message passing is out of scope of this edge-messaging protocol. For practical purposes, and from the graph-chat client application point of view, various solutions can be used, e.g. one of the versions or the analogues of [QR code][3] (or their sequence) that is read via the camera, either directly from the chat participant's device or via the video call. Although a video call still allows for a highly sophisticated MITM attack, it requires that in addition to compromising edge-messaging connection to intercept messages, the attacker also identifies and compromises the video connection in another channel and substitutes the video in real time - it seems extremely unlikely.
+Defining the approach to out-of-band message passing is out of scope of this simplex messaging protocol. For practical purposes, and from the graph-chat client application point of view, various solutions can be used, e.g. one of the versions or the analogues of [QR code][3] (or their sequence) that is read via the camera, either directly from the chat participant's device or via the video call. Although a video call still allows for a highly sophisticated MITM attack, it requires that in addition to compromising simplex connection to intercept messages, the attacker also identifies and compromises the video connection in another channel and substitutes the video in real time - it seems extremely unlikely.
 
 
 ## Simplex connection - the main unit of protocol design
@@ -37,35 +37,35 @@ The network consists of multiple "simplex connections" (i.e. unidirectional, non
 
 The messages sent into the connection are encrypted and decrypted using another key pair - the recepient has the private key and the sender has the associated public key.
 
-**Unidirectional connection diagram:**
+**Simplex connection diagram:**
 
-![Unidirectional connection](/diagrams/edge-messaging/edge.svg)
+![Simplex connection](/diagrams/simplex-messaging/simplex.svg)
 
 Connection is defined by ID (`ID`) unique to the server, sender URI `SU` and receiver URI `RU`. Sender key (`SK`) is used by the server to verify sender's requests (made via `SU`) to send messages. Recipient key (`RK`) is used by the server to verify recipient's requests (made via `RU`) to retrieve messages.
 
 The protocol uses different URIs for sender and recipient in order to provide an additional connection privacy by complicating correlation of senders and recipients.
 
 
-## How Alice and Bob use edge-messaging protocol
+## How Alice and Bob use simplex messaging protocol
 
 Alice (recipient) wants to receive the messages from Bob (sender).
 
 To do it Alice and Bob follow these steps:
 
-1. Alice creates the unidirectional connection on the server:
-   1. she decides which edge-messaging server to use (can be the same or different server that Alice uses for other connections).
+1. Alice creates a simplex connection on the server:
+   1. she decides which simplex messaging server to use (can be the same or different server that Alice uses for other connections).
    2. she generates a new random public/private key pair (encryption key - `EK`) that she did not use before for Bob to encrypt the messages.
    3. she generates another new random public/private key pair (recepient key - `RK`) that she did not use before for her to sign requests to retrieve the messages from the server.
-   4. she generates a unique connection `ID` - generic edge-messaging protocol only requires that:
+   4. she generates a unique connection `ID` - generic simplex messaging protocol only requires that:
       - it is generated by the client.
       - it is unique on the server.
-   5. she requests from the server to create a unidirectional connection. The request to create the connection is un-authenticated and anonymous. This connection definition contains previouisly generated connection `ID` and a uniqie "public" key `RK` that will be used to:
+   5. she requests from the server to create a simplex connection. The request to create the connection is un-authenticated and anonymous. This connection definition contains previouisly generated connection `ID` and a uniqie "public" key `RK` that will be used to:
       - verify the requests to retrieve the messages as signed by the same person who created the connection.
       - update the connection, e.g. by setting the key required to send the messages (initially Alice creates the connection that accepts unsigned requests to send messages, so anybody could send the message via this connection if they knew the connection URI).
    6. The server responds with connection URIs:
       - recipient URI `RU` for Alice to retrieve messages from the connection.
       - sender URI `SU` for Bob to send messages to the connection.
-2. Alice sends an out-of-band message to Bob via the alternative channel that both Alice and Bob trust (see [Edge-messaging protocol abstract](#edge-messaging-protocol-abstract) above). The message includes:
+2. Alice sends an out-of-band message to Bob via the alternative channel that both Alice and Bob trust (see [Simplex messaging protocol abstract](#simplex-messaging-protocol-abstract) above). The message includes:
    - the unique "public" key (`EK`) that Bob should use to encrypt messages.
    - the sender connection URI `SU` for Bob to use.
 3. Bob, having received the out-of-band message from Alice, accepts the connection:
@@ -82,17 +82,17 @@ To do it Alice and Bob follow these steps:
 5. Alice secures the connection `ID` so only Bob can send messages to it:
    1. she sends the request to `RU` signed with "private" key `RK` to update the connection to only accept requests signed by "private" key `SK` provided by Bob.
    2. From this moment the server will accept only signed requests, and only Bob will be able to send messages to the `SU` corresponding to connection `ID`.
-6. The unidirectional connection `ID` is now established on the server.
+6. The simplex connection `ID` is now established on the server.
 
-**Creating unidirectional connection from Bob to Alice:**
+**Creating simplex connection from Bob to Alice:**
 
-![Creating connection](/diagrams/edge-messaging/edge-creating.svg)
+![Creating connection](/diagrams/simplex-messaging/simplex-creating.svg)
 
 
 Bob now can securely send messages to Alice.
 
 1. Bob sends the message:
-   1. he encrypts the message to Alice with "public" key `EK` (provided by Alice, only known to Alice and Bob, used only for one unidirectional connection).
+   1. he encrypts the message to Alice with "public" key `EK` (provided by Alice, only known to Alice and Bob, used only for one simplex connection).
    2. he signs the request to the server (via `SU`) using the "private" key `SK` (that only he knows, used only for this connection).
    3. he sends the request to the server, that the server will verify using the "public" key SK (that Alice provided to the server).
 2. Alice retrieves the message(s):
@@ -100,49 +100,49 @@ Bob now can securely send messages to Alice.
    2. the server, having verified Alice's request with the "public" key `RK` that she provided, responds with Bob's message(s).
    3. she decrypts Bob's message(s) with the "private" key `EK` (that only she has).
 
-**Sending messages from Bob to Alice via unidirectional connection:**
+**Sending messages from Bob to Alice via simplex connection:**
 
-![Using connection](/diagrams/edge-messaging/edge-using.svg)
+![Using connection](/diagrams/simplex-messaging/simplex-using.svg)
 
 
-A higher level protocol (e.g., [graph-chat][7]) defines the semantics that allow to use two unidirectional connections (or two sets of connections for redundancy) for the bi-directional messaging chat and for any other communication scenarios.
+A higher level protocol (e.g., [graph-chat][7]) defines the semantics that allow to use two simplex connections (or two sets of connections for redundancy) for the bi-directional messaging chat and for any other communication scenarios.
 
-The edge-messaging protocol is intentionally unidirectional - it provides no answer to how Bob will know that the process succeeded, and whether Alice received any messages. There may be a situation when Alice wants to securely receive the messages from Bob, but she does not want Bob to have any proof that she received any messages - this low-level edge-messaging protocol can be used in this scenario, as all Bob knows as a fact is that he was able to send one unsigned message to the server that Alice provided, and now can only send messages signed with the key `SK` that he sent to the server - it does not prove that any message was received by Alice.
+The simplex messaging protocol is intentionally sipmlex - it provides no answer to how Bob will know that the process succeeded, and whether Alice received any messages. There may be a situation when Alice wants to securely receive the messages from Bob, but she does not want Bob to have any proof that she received any messages - this low-level simplex messaging protocol can be used in this scenario, as all Bob knows as a fact is that he was able to send one unsigned message to the server that Alice provided, and now can only send messages signed with the key `SK` that he sent to the server - it does not prove that any message was received by Alice.
 
-For practical purposes of bi-directional conversation, now that Bob can securely send encrypted messages to Alice, Bob can establish the second unidirectional connection that will allow Alice to send messages to Bob in the same way. If both Alice and Bob have their respective uniqie "public" keys (Alice's and Bob's `EK`s of two separate connections), the conversation can be both encrypted and signed.
+For practical purposes of bi-directional conversation, now that Bob can securely send encrypted messages to Alice, Bob can establish the second simplex connection that will allow Alice to send messages to Bob in the same way. If both Alice and Bob have their respective uniqie "public" keys (Alice's and Bob's `EK`s of two separate connections), the conversation can be both encrypted and signed.
 
 The established connection can also be used to change the encryption keys providing [forward secrecy][5].
 
 This protocol also can be used for off-the-record messaging, as Alice and Bob can have multiple connections established between them and only information they pass to each other allows proving their identity, so if they want to share anything off-the-record they can initiate a new connection without linking it to any other information they exchanged. As a result, this protocol provides better anonymity and better protection from [MITM][1] than [OTR][6] protocol.
 
-How unidirectional connections (graph edges) are used by the participants (graph vertices) is defined by graph-chat protocol and is not in scope of this low level edge-messaging protocol.
+How simplex connections are used by the participants (graph vertices) is defined by graph-chat protocol and is not in scope of this low level simplex messaging protocol.
 
 
-## Alternative flow to establish unidirectional connection
+## Alternative flow to establish a simplex connection
 
 When Alice and Bob already have a secure duplex (bi-directional) communication channel that allows to conveniently send two out-of-band messages, a flow with smaller number of steps to establish the connection can be used.
 
 TODO
 
-**Alternative flow of creating unidirectional connection from Bob to Alice:**
+**Alternative flow of creating a simplex connection from Bob to Alice:**
 
-![Alternative flow of creating connection](/diagrams/edge-messaging/edge-creating-alt.svg)
+![Alternative flow of creating connection](/diagrams/simplex-messaging/simplex-creating-alt.svg)
 
 
-## Elements of the generic edge-messaging protocol
+## Elements of the generic simplex messaging protocol
 
 - defines only message-passing protocol:
-  - transport agnostic - the  protocol does not define how clients connect to the servers and does not require persistent connections. While a generic term "request" is used, it can be implemented in various ways - HTTP requests, messages over (web)sockets, etc. This is defined by edge-messaging server protocol.
-  - not semantic - the protocol does not assign any meaning to connections and messages. While on the application level the connections and messages can have different meaning (e.g., for messages: text or image chat message, message acknowledgement, participant profile information, status updates, changing "public" key to encrypt messages, changing servers, etc.), on the edge-messaging protocol level all the messages are binary and their meaning can only be interpreted by client applications and not by the servers - this interpretation is in scope of graph-chat protocol and out of scope of this edge-messaging protocol.
+  - transport agnostic - the  protocol does not define how clients connect to the servers and does not require persistent connections. While a generic term "request" is used, it can be implemented in various ways - HTTP requests, messages over (web)sockets, etc. This is defined by simplex messaging server protocol.
+  - not semantic - the protocol does not assign any meaning to connections and messages. While on the application level the connections and messages can have different meaning (e.g., for messages: text or image chat message, message acknowledgement, participant profile information, status updates, changing "public" key to encrypt messages, changing servers, etc.), on the simplex messaging protocol level all the messages are binary and their meaning can only be interpreted by client applications and not by the servers - this interpretation is in scope of graph-chat protocol and out of scope of this simplex messaging protocol.
 - client-server architecture:
   - multiple servers, that can be deployed by the system users, can be used to send and retrieve messages.
   - servers do not communicate with each other and do not even "know" about other servers.
   - clients only communicate with servers (excluding the initial out-of-band message), so the message passing is asynchronous.
   - for each connection, the message recipient defines the server through which the sender should send messages.
-  - while multiple servers and multiple connections can be used to pass each chat message, it is in scope of graph-chat protocol, and out of scope of this edge-messaging protocol.
+  - while multiple servers and multiple connections can be used to pass each chat message, it is in scope of graph-chat protocol, and out of scope of this simplex messaging protocol.
   - servers store messages only until they are retrieved by the recipients
   - servers are not supposed to store any message history or delivery log, but even if the server is compromised, it does not allow to decrypt the messages or to determine the list of connections established by any participant - this information is only stored on client devices.
-- the only element provided by edge-messaging servers is unidirectional connections (graph edges):
+- the only element provided by simplex messaging servers is simplex connections:
   - each connection is created and managed by the connection recipient.
   - assymetric encryption is used to sign and verify the requests to send and receive the messages.
   - one unique "public" key is used for the servers to authenticate requests to send the messages into the connection, and another unique "public" key - to retrieve the messages from the connection. "Unique" here means that each "public" key is used only for one connection and is not used for any other context - effectively this key is not public and does not represent any participant identity.