feat: Add device message about outgoing undecryptable messages (#5164)

[iequidoo]

See commit messages.

Close #5164

[iequidoo]

Currently undecryptable outgoing messages don't go to Trash, i.e. i don't change this logic. Just not sure we can do that safely. Also i'm not sure that adding a notification once per day is sufficient, e.g. if the user tried to fix their multi-device setup, but did smth wrong, they will know about that only on the next day.

[iequidoo]

Maybe add a device message for each received outgoing undecryptable message, but remove also the previous if it's of the same kind? Then we don't need to store the last notification time in the db and don't need this magic 1-day period.

[link2xt]

e.g. if the user tried to fix their multi-device setup, but did smth wrong, they will know about that only on the next day

Fixing multi-device setup generally means transferring a backup from the other device, so the counter associated to incorrectly set up account will be removed.

[link2xt]

Maybe add a device message for each received outgoing undecryptable message, but remove also the previous if it's of the same kind? Then we don't need to store the last notification time in the db and don't need this magic 1-day period.

Intention of 1-day period is to notify/annoy user at most once a day if they keep sending messages outside interchangeably from two devices. If a new message is added and previous one removed each time like this, user will be notified every time, or never notified if the message is actually replaced.

[link2xt]

Currently undecryptable outgoing messages don't go to Trash, i.e. i don't change this logic. Just not sure we can do that safely.

What may go wrong if we do this? I can only see that chat assignment may get broken, but this outgoing message would not be assigned to the correct chat as well. If this is a new from-scratch setup (user simply logged in), user likely does not see any existing groups anyway. Old setup may assign messages from new setup, but these messages from new setup are likely not group messages, but simply messages to self or to some manually typed in contacts.

[iequidoo]

What may go wrong if we do this? I can only see that chat assignment may get broken, but this outgoing message would not be assigned to the correct chat as well. If this is a new from-scratch setup (user simply logged in), user likely does not see any existing groups anyway. Old setup may assign messages from new setup, but these messages from new setup are likely not group messages, but simply messages to self or to some manually typed in contacts.

I agree, it's unlikely that subsequent messages chat assignment may get broken, now i send outgoing undecryptables to the Trash. But as for incoming, i left the current logic.

[link2xt]

But as for incoming, i left the current logic.

Yes, the plan is only for outgoing because it is a clear sign that two setups with different keys are present right now (assuming all devices are online) and this should definitely be fixed.

For incoming messages some improvement is needed because current state is that an encrypted group turns into a lot of contact request 1:1 chats as you get messages from all participants, but this is not designed yet.

[iequidoo]

There is a question what to do if an undecryptable outgoing message has unencrypted Message-ID or In-Reply-To that allow assigning it to the proper chat. Would it be useful? F.e. for assigning subsequent messages to the chat. Now test_verified_group_member_added_recovery fails because such messages still go to the group chat. @link2xt

[link2xt]

How test_verified_group_member_added_recovery is affected by this? ac2 resetups the device at one point, but then old device is gone so new device should not be able to receive undecryptable outgoing message I guess.

Are you sure the test is broken by this change? It looks like this test somehow got flaky on main already.

[iequidoo]

Indeed, it's not broken by this change, i just saw that [This message was encrypted for another setup.] messages go to the group chat, but they are incoming, not outgoing. Anyway, if we see an outgoing message that can be assigned to the proper chat by its references in the unencrypted part, maybe keep the current behaviour?

EDIT: At least the user would see that there was some message from their another device, this looks good to me

[link2xt]

Anyway, if we see an outgoing message that can be assigned to the proper chat by its references in the unencrypted part, maybe keep the current behaviour?

The goal is to quickly push user to remove this newely set up account and resetup using backup transfer, so assigning square bracket messages to chats does not help and it is anyway unlikely that user will even see these group chats on a newely set up account.

EDIT: At least the user would see that there was some message from their another device, this looks good to me

If there is a new outgoing message it means the user just used this device. Also this would be one more message to decide on and translate in addition to device chat message, because current square bracket message does not fit for outgoing messages.

[iequidoo]

If there is a new outgoing message it means the user just used this device. Also this would be one more message to decide on and translate in addition to device chat message, because current square bracket message does not fit for outgoing messages.

Then a device message should be added, but the original one just may be made hidden. This would be closer to what other users have, because the message doesn't go to Trash for them.

[iequidoo]

@link2xt do you have an idea why this check hung?

WIP Expected — Waiting for status to be reported

Btw, in #5158 too

[link2xt]

@link2xt do you have an idea why this check hung?

WIP Expected — Waiting for status to be reported

Btw, in #5158 too

No idea, but I removed it from required checks now. Maybe someone has added it while in fact it should not be part of required checks because it is not reported when there is no WIP in title.