I use Delta Chat on multiple machines and am thus using the “send copy to self” feature. When I receive a message and read it on one client, it is not marked as read on the others unless I reply to it.
To solve this, read receipts should also be sent to myself if the option “send copy to self” is on and messages should be marked as read by such read receipts.
In fact, we should consider always sending a read receipt to self if “send copy to self” is on and to others only if “read receipts” is on.
1 Like
There was some work done by @r10s to mark messages that we replied to from other devices as “noticed”:
The idea of sending a synchronization message/chat read on another device special message was dismissed as introducing additional overhead. But given that it is actually a read receipt and all that is needed is to BCC it to self, I really like the idea.
There is a caveat though that it will not work if the other side did not request a read receipt. We can still send it to self if we have read receipts enabled, but it feels too hacky.
This one I’m not sure about, disabling read receipts may be needed if you don’t trust your provider and want to prevent it from being able to tell which messages you have seen and when.Well, the server will be able to tell anyway when you mark the message as seen on IMAP.
Agreed. That would be alleviated a little bit if read receipts were encrypted so they can’t be told apart from normal messages. Why are they not?
I think the logic would still be quite simple: If the “read receipts” option is on, build the list of recipients by
- adding the author of the message if a read receipt was requested and
- adding self if “send copy to self” is on.
Then send read receipts to those people (possibly nobody).
Actually, the messages are also marked as seen on the server using IMAP: deltachat-core-rust/job.rs at 475fa248769a49bf4dd44717aafcf5dfd3e98d67 · deltachat/deltachat-core-rust · GitHub
That could be picked up by other clients, which would be problematic though in case it is marked seen by an MUA that e.g. doesn’t even have the key to decrypt the message.
The problem is that if read receipt can’t be decrypted, for example if you have set up a new device and plan to copy the key via Autocrypt Setup Message but have not done it yet, you will receive such read receipts as normal messages that can’t be decrypted.
And it is still easy to tell that these message are read receipts by timing and sizes of the messages, because you usually read many messages at once and send a burst of read receipts with low delay between messages. And also by looking when you mark encrypted messages as Seen on IMAP.
Seen flags is already used in multi-device case. If you download the message in one app (e.g. Android), read it, then open another app (e.g. Desktop), the message should be marked as seen right after downloading. dc_receive_imf procedure takes seen flag into account. But if you download the message in both apps first, then read the message in one app, the other app will not notice that Seen flag has been set on the message because the message is already downloaded. It should, however, get unsolicited FETCH response if it is online, but Delta Chat currently ignores it. Processing unsolicited FETCH responses and refetching message flags in this case is a good idea and should be done, but will not work if the second device is online. AFAIK it’s only possible to get such updates after an offline period with QRESYNC IMAP extension or by refetching message flags each time after reconnecting: