adding privacy-aware return receipts for messages

[mwfarb]

This is a tough problem that @tenmalin and I have spent the morning debating. I'll attempt to document our current discussion and outcome here in this thread, but here are some recent comments from users:

1. It would be useful to get confirmation that a message has been delivered and then read - you know, a little tick in the message list after you sent the message.

[mwfarb]

Desired features:

• Receipts are not sent/received in the background (in fact iOS cannot).
• Receipts do not reveal the time of delivery, only time sent.
• Receipts are encrypted.
• Receipts are included in other intentional messages only, never as a receipt-only.
• No state is recorded on the server for read/delivered or any status.
• Receipts are not delivered by non-public key crypto methods.

[mwfarb]

One of the models we are left with is one where each message sent includes an encrypted transcript of the last 10 sent and last 10 received (10 is arbitrary at the moment) message ids for the receiver to reconcile. For this to work:

• iOS and Android client databases and message formats must change.
• Parsing message meta data should properly ignore this feature for older message meta data versions.
• Deleting messages will be divided into Permanent and Pseudo: Permanent deletes occur for messages older than the last 10 removing the entire row of data, Pseudo deletes occur for the 10 most recent removing all row data except message id and time sent (sender only).
• Message list UI should update the sent time of "expired" notifications received to improve accuracy.
• Message list UI should update/insert "unnotified" messages in the proper sequence.
• Finding missing messages within the 24 hour window should attempt to download them.

[mwfarb]

• Pseudo deleted messages should not be normally visible or counted in tallys, but it would be good to provide a mechanism to "see" them somehow for users.
• Pseudo deleted messages should convert to Permanent deleted messages once they exceed the last 10.

[mwfarb]

Another way to do this, is a user-requested receipt that can only be executed by querying the state of the messages on the server for a given recipient. We could get good accuracy up to the pending message deletion deadline timeout, currently set at 2 weeks.

Requires implementation of SafeSlingerProject/SafeSlinger-AppEngine#27 first.

[mwfarb]

This also solves the iOS issues for foreground operations. We include a button or pull-down, user-driven action. We can mark which messages in the pending window have been delivered or not. Status of successful decryption is not possible.