UI minor bugs for 1.8.1 release

[tenmalin]

We still have several minor things to be fixed on iOS production app:

1. badge number displaying on the tap is inaccurate after users have read those new messages (behavior: update number displaying on the tap).
2. thread should be sorted by reading order (the newest should be on the top).

[brnunes]

I noticed problem number 2 and have already fixed it, it's committed to branch v1.8.2.

[mwfarb]

:+1: Nice catch @brnunes!

[brnunes]

The main problem with the badge number is actually bigger. By reading the code, this is what I understand is happening now when a message is received. Correct me if I'm wrong:

• When a push notification is received, it contains the message id of the new message(s) that is(are) stored in our server.
• We save that message id as the msgid in the table ciphertable in the UniversalDB, together with the current time as cTime.
• We then request the cipher message from the server using the msgid.
• Upon receipt, we update the ciphertable with the proper keyid of the sender and the encrypted message itself as the cipher.

The messages received are not associated with any destination key. So if the user has created more than one pair of keys in the same device, those messages will appear to all of the key pairs created. They will also count as unread messages, increasing the badge number even if they were not destined to the key pair which is current logged in. This also causes a lot of "Signature verification failed" errors, when we try to decrypt a message that was sent using a public key that is not the one which is currently logged in. How is this managed in Android? I think the keyid of the destination should be sent together with the message, so that we know who the destination is and can show the message only when the user is logged in with that key pair.

[mwfarb]

On Android, there is a background thread that attempts to decrypt any messages (if the auto-decrypt boolean is true (default) and the user is logged in) for the current account (key id) only. If we have messages still in ciphertext that belong to other accounts, we just leave them in our ciphertext table (undecrypted inbox) until a user logs in with the passphrase for one of those other accounts.

You're right, we shouldn't bother the user on the UI with messages from other accounts we can't decrypt yet.

[mwfarb]

So, on the badge number question, on Android we still have our unread message count reflect those messages from other accounts that the current user cannot decrypt yet. We leave them in a "Unknown" thread on the UI view, which is not great, but we do want users to know that new messages exists, maybe we should start calling that thread "Other Account Messages". And when the user opens it to find a list of messages that just say "Tap to Decrypt" maybe we can add an instructional message at the top that says "Here are messages that belong to other accounts. If you remember the paraphrase, choose that account when logging to read, otherwise you will unable to read them, and can delete them if you wish."

[tenmalin]

We probably cannot tell the difference between signature failure case and the ciphertext does not belong to the recipient now since we do not append recipient key id now. The best scenarios is that users try to tap (decrypt) the messages or they could decrypt the encrypted messages by enabling auto-decryption feature.

However, the first issue I described is not exactly same as the issue proposed by @brnunes, the bug happens while users are already login and badge number on the tap is not synchronized well to reflect what he/she should see.