agent: delivery receipts (#752)

* rfc: delivery receipts

* update doc

* update rfc

* implementation plan, types, schema

* migration, update types

* update types

* rename migration

* export MsgReceiptStatus, JSON encoding

* update rfc, schema

* correction

Co-authored-by: spaced4ndy <8711996+spaced4ndy@users.noreply.github.com>

* skeleton of the implementation

* more implementation (some tests fail)

* more code, 1 test fails

* fix encoding

* refactor

* refactor

* test, fix

* only send receipts in v3+, test

* flip condition

Co-authored-by: spaced4ndy <8711996+spaced4ndy@users.noreply.github.com>

* flip condition

Co-authored-by: spaced4ndy <8711996+spaced4ndy@users.noreply.github.com>

* agent version 4 required to send receipts

* fix test

---------

Co-authored-by: spaced4ndy <8711996+spaced4ndy@users.noreply.github.com>

rfcs/2023-05-03-delivery-receipts.md

@@ -0,0 +1,170 @@
+# Delivery receipts
+
+## Problems
+
+User experience - users need to know that the messages are delivered to the recipient, as this confirms that the system is functioning.
+
+The downside of communicating message delivery as it confirms that the recipient was online, and, unless there is a delay in confirming, can be used to track the location via the variation in network latency. So delivery receipts should be delayed with a randomized interval and should be opt in or opt out.
+
+Another problem of message receipts is that they increase network traffic and server load. This could be avoided if delivery receipts are communicated as part of normal message delivery flow.
+
+Some other existing and planned features implicitely confirm message delivery and, possibly, should depend on message delivery being enabled:
+- agent message to resume delivery when quota was exceeded (implemented, [rfc](./2022-12-27-queue-quota.md))
+- agent message to re-deliver skipped messages or to re-negotiate double ratchet.
+
+## Solution
+
+There are three layers where delivery receipts can be implemented:
+- chat protocol. Pro: logic of when to deliver it is decoupled from the message flow, Con: extra traffic, can only work in duplex connections.
+- agent client protocol. Pro: can be automated and combined with the protocol to re-deliver skipped messages. Con: extra traffic.
+- SMP protocol. Pro: minimal extra traffic, Con: complicates server design as it would require pushing receipts when there is no next message.
+
+The last approach seems the most promising for avoiding additional traffic:
+- modify client ACK command to include whether delivery receipt should be provided to sender, and, possibly, any e2e encrypted data that should be included in the receipt (e.g., that the receiving client already saw this message in case we use "feedback" variant of roumor-mongering protocol for groups).
+- server would manage delaying of the receipts, by randomizing the time after which the receipt will be available to the sender, and by combining the receipts when possible.
+- modify response to SEND command to include any available delivery receipts.
+- add a separate delivery receipt that will be pushed to the sender in the connection where the message was received by the server.
+
+## SMP protocol changes
+
+```haskell
+data Command (p :: Party) where
+  -- ...
+  ACK :: MsgId -> Maybe ByteString -> Command Recipient
+  -- the presense of ByteString in ACK indicates that the delivery needs to be confirmed.
+  -- the protocol does not define the format of this confirmation, it is application specific, and can be -- an empty string.
+  -- And open question is how to e2e encrypt information in this string - this probably can be handled on Agent client protocol level, and could be the same ratchet key that was used to encrypt and decrypt the message. The downside of this approach is that this key currently is not stored, and storing it requires additional logic to clear these keys if unused after some time.
+  -- TODO consider what could be a better approach.
+  SENT :: MsgId -> [(MsgId, UTCTime, ByteString)] -> Command Sender
+  -- or
+  -- SENT :: MsgId -> Command Sender
+  -- in case we just batch
+  -- this response will be sent to SEND command and will include a sender's message ID generated by the server (currently it does not exist), and posibly an empty list of delivery receipts with the same message IDs as in responses to SEND, timestamps when these receipts became available, and e2e encrypted ByteString passed in ACK command.
+  -- The ID in this response should be different from the ID used in MSG, to keep the promise of not having shared identifiers in sent/received traffic even inside TLS tunnel.
+  -- Keeping the quality of shared ciphertext also requires adding additional encryption layer between the server and the sender, this can be achieved in one of two ways:
+  -- 1) passing a separate DH key in each SEND command, and server including additional DH key in each SENT response, with computed DH secret per message later used to encrypt and decrypt the delivery receipt payloads. This is probably a bad idea as it would increase a cryptographic load on both the server and the client.
+  -- 2) agree a key per queue, in the same way it is done for the recipient. Possibly, it requires additional DH key in confirmation message that the recipient then uses to secure the queue, and passing this key in KEY (secure queue) command. The response to this secure command would the include server's DH key returned to the recipient that would be passed to the sender in HELLO message. Even though recipient could observe both public DH keys, they won't know the computed shared secret. Recipient that controls the server could perform MITM attack on this key exchange, but it doesn't give any benefit over what recipient can do when they have access to the server - the threat model remains the same. The downside of this approach is that it also requires additional changes in client protocol level (confirmation message format and HELLO message).
+  -- 3) also agree on a key per queue, but via separate commands between the sender and the server, once the sender was notified that the queue is secured. This approach is probably better, and the server would simply delay the delivery of delivery receipts until the shared secret is agreed.
+  SKEY :: C.PublicKeyX25519 -> Command Sender
+  SBKEY :: C.PublicKeyX25519 -> BrokerMsg
+  -- these are the command and response to agree secret to encrypt delivery receipt payloads for option 3
+  SSUB :: Command Sender
+  -- subscribe to receive delivery receipts for a given queue - will be sent when the conversation is opened (unless there is an active subscription already), not all queues at once, and won't be re-subscribed on losing the server connection (TBC).
+  RCVD :: MsgId -> UTCTime -> ByteString -> Command Recipient
+  -- delivery receipt. UTCTime is the time when it became available, not the time when ACK was sent by the recipient, to avoid leaking location via network latency.
+```
+
+Possibly, there is no need to include delivery receipts into SENT response and instead just use batching of responses that is already supported. As server responses are not signed, there is no per-response overhead that is substantial, and a lot of receipts that are available can be packed into one block (depending on the size of payload that has to be fixed not to leak metadata).
+
+This all seems rather complicated for SMP protocol, and the approach of doing it on a higher level seems more attractive than initially. Possibly we should reconsider, and reduce traffic by reducing block sizes... Reducing block sizes unfortunately requires supporting variable block sizes, and would leak some metadata during the transition period.
+
+## Another approach
+
+Above represents substantial complexity, and at least doubles server code complexity for the feature that is definitely not doubling the value of server software. Moving to variable block size is simpler, but also has a lot of complexity, reduces metadata privacy (at least for the duration of migration period), reduces image preview quality, and requires postponing this feature for multiple releases, until all clients migrate.
+
+Given that the main traffic is generated by the groups, and direct messages do not create a lot of traffic, a much simpler and better solution is to simply send delivery receipts as the message, in direct conversations only, either as chat protocol message or as agent client protocol message (either on the message or on the envelope layer).
+
+### Comparison of these two approaches:
+
+**Chat protocol message**
+
+Pros:
+- simpler, more contained change - SMP layer is not aware of this feature
+- easier to extend protocol with additional application specific payload, e.g. references to group DAG
+Cons:
+- ?
+
+```json
+  // ...
+  "x.msg.delivered": {
+    "properties": {
+      "msgId": {"ref": "base64url"},
+      "params": {
+        "properties": {
+          "msgId": {"ref": "base64url"},
+        },
+        "optionalProperties": {
+          "data": {} // possibly the initial protocol does not need it, with JSON can be added later
+        }
+      }
+    }
+  },
+  // ...
+```
+
+**Agent client protocol envelope**
+
+Pros:
+- possibility of using it in a wider range of the applications
+- possibility to include received message hash to increase communication integrity - the sending client would be then notified, and it can be exposed in the UI, that the received message is not the same as sent.
+
+Cons:
+- additional implementation complexity - requires additional events to communicate between chat and agent.
+
+```haskell
+data AMessage =
+  -- ...
+  | A_RCVD AgentMsgId MsgHash ByteString -- references to the received message
+  -- ...
+```
+
+The weirdness of the above design is that it refers to the data present in the header of another message, the alternative would be to have a separate envelope for delivery receipt:
+
+```haskell
+data AgentMessage =
+  -- ...
+  AgentMessageRcvd APrivHeader AgentMsgId MsgHash ByteString -- references to the received message
+  -- ...
+```
+
+But probably the first one is a bit better, TBC.
+
+In any case there should be an additional event to notify chat client:
+
+```haskell
+data ACommand (p :: AParty) (e :: AEntity) where
+  -- ...
+  RCVD AgentMsgId MsgMeta ByteString -> ACommand Agent AEConn
+  -- ...
+```
+
+On the balance of things, implementing on the level of Agent Client protocol seems better, as the additional complexity is marginal, but it allows for wider range of applications, and also allows for additional delivery integrity validation. The format for payload still requires chat protocol message encoding once we want to add it, but initially it could be just an empty string.
+
+## Implementation plan
+
+Currently, we delete sent messages once delivered to the server. It would be helpful if we could keep the records in snd_messages table, and then use them to process delivery receipts, although it may be insufficient (we could add fields). Probably it is not possible to keep them as there is a foreign key constraint with `on delete cascade`.
+
+The new table will be used to track sent message hashes to correlate their IDs with delivery receipts (that will also be stored in messages/rcv_messages). Receipts need to be processed in chat in the same way as normal messages, so they would be sent to chat with MsgMeta, and the chat will need to ack them once processed.
+
+Agent ackMessage function will be also used to automatically schedule sending delivery receipts if they are enabled for connection, only for normal messages - no sending receipts to receipts.
+
+There can be receipt re-delivery to the chat in the same cases as when normal message can be re-delivered (in case of AGENT A_DUPLICATE when it was not ack'd by the user).
+
+## Other considerations
+
+### How clients decide whether to send delivery receipts
+
+Two options are possible - local settings per conversation or chat preferences framework, that allows to have mutual on/off. The latter seems preferable as without knowing whether the other party is sending receipts, it is not possible to uderstand what the absense of the receipt means - network malfunction or receipts disabled.
+
+Groups are a special case, as while some groups may enable sending the delivery receipts, the group members should be able to disable it locally. This should probably be done via a separate conversation setting in the same way as enabling notifications or favourites. In this case the receipt would only be sent to the group if it is enabled in the group and not disabled by the member. The toggle may be located in the same page as chat preferences, but it should be a separate setting. We might want though to communicate somehow whether a given member sends delivery receipts so that other members know whether to expect them or not.
+
+### How this functionality is released
+
+5.2:
+- support for sending and receiving delivery receipts preference, both in direct messages and in groups (for forward compatibility).
+- support for sending and receiving delivery receipts in direct chats only, but disable sending them
+
+5.3:
+- show receipt preferences in the UI
+- enable sending receipts in direct chats where they are enabled
+
+A separate question is how to enable this functionality for the existing contacts. Possible options are:
+
+1. Enable (as per default) for all contacts, show notification to the user when they open the app for update that delivery notifications are now sent by default to all contacts. Pro: no extra logic to implement. Con: may be perceived as a privacy violation, as to some contacts the delivery receipts will be sent before the user had chance to disable them.
+2. Ask the user when the new version first runs whether they want to use delivery receipts and offer these options:
+  1) keep enabled for all profiles (and for all contacts)
+  2) enable for all profiles in ~12 or in ~24 hours giving users the chance to review all contacts / profiles and disable some of them. The problem here is also in possibility of the correlation in case they all start sending receipts at the same time. Possibly the option could be to set a random time in 12-15 or 24-30 hours range to avoid the possibility of such correlation.
+  3) disable for all profiles – it will require sending profile updates to all contacts, so the delivery receipts should be kept disabled and profile updates should be sent after random intervals, one by one (not scheduled all at once, as the time may pass while the app is off).
+3. Offer an option to enable globally later - we could keep it as a one-off option, available only to existing users, and visible on the top level of the Settings - once enabled, the option will disappear and it won't be possible to disable again. The downside here is that the new contacts would be receiving the profile with enabled notifications but they still won't be delivered...
+4. Another option is to have all new contacts decided based on a global user default (that can be set in the settings and in the dialog on first start), but for the existing contacts keep in unset state that is not interpreted as either on or off, but interpreted as unknown until the user makes a choice... That might be an optimal solution for the users but it would probably require changing the preferences framework or some ad-hoc hacks. That still keeps the question open how to avoid correlation between profiles.
+5. That might be the case for version agreement too - the availability of the option per contact will depend on the version. It doesn't answer the question what to do with global defaults though...

simplexmq.cabal

@@ -34,7 +34,6 @@ flag swift
 
 library
   exposed-modules:
-      Simplex.FileTransfer
       Simplex.FileTransfer.Agent
       Simplex.FileTransfer.Client
       Simplex.FileTransfer.Client.Agent
@@ -85,6 +84,7 @@ library
       Simplex.Messaging.Agent.Store.SQLite.Migrations.M20230516_encrypted_rcv_message_hashes
       Simplex.Messaging.Agent.Store.SQLite.Migrations.M20230531_switch_status
       Simplex.Messaging.Agent.Store.SQLite.Migrations.M20230615_ratchet_sync
+      Simplex.Messaging.Agent.Store.SQLite.Migrations.M20230701_delivery_receipts
       Simplex.Messaging.Agent.TAsyncs
       Simplex.Messaging.Agent.TRcvQueues
       Simplex.Messaging.Client