That commit never worked because there were other checks in place later down the stream.
Allowing other clients (resources) to correct messages introduces the potential for nasty race conditions.
Furthermore we also have a check in place that would check that the OMEMO fingerprint is the same for security reasons. Removing that check is currently undesirable. Therefor correcting a message from another client would only work for plain text messages (and maybe PGP); this only adds confusion for users for very little benefit.
Ever since Android 9+ switched to Conscrypt we can no longer efficiently
encrypt (and decrypt) large files with AES-GCM. We did’t notice this before
because when using 16 byte IVs even modern Androids will fall back to bouncy
castle. However the 'bug'/'feature' in Conscrypt surfaced when we switched over
to 12 byte IVs (which uses Conscrypt on Android 9+)
Switching back entirely to 16 byte IVs is undesirable as this would break
compatibility with Monal. So we end up with a weird compromise where we use
12 byte for normale plain text OMEMO messages and 'small' files where the
inefficiencies aren’t a problem.
The result of this commit is that Monal won’t be able to receive our files
larger than 768KiB. However the alternative is that Conversations would always
OOM when attempting to send larger files (where large depends on the available
RAM.)
fixes#3653
XML and by inheritence XMPP has the feature of transmitting multiple language
variants for the same content. This can be really useful if, for example, you
are talking to an automated system. A chat bot could greet you in your own
language.
On the wire this will usually look like this:
```xml
<message to="you">
<body>Good morning</body>
<body xml:lang="de">Guten Morgen</body>
</message>
```
However receiving such a message in a group chat can be very confusing and
potentially dangerous if the sender puts conflicting information in there and
different people get shown different strings.
Disabeling support for localization entirely isn’t an ideal solution as on
principle it is still a good feature; and other clients might still show a
localization even if Conversations would always show the default language.
So instead Conversations now shows the displayed language in a corner of the
message bubble if more than one translation has been received.
If multiple languages are received Conversations will attempt to find one in
the language the operating system is set to. If no such translation can be
found it will attempt to display the English string.
If English can not be found either (for example a message that only has ru and
fr on a phone that is set to de) it will display what ever language came first.
Furthermore Conversations will discard (not show at all) messages with with
multiple bodies of the same language. (This is considered an invalid message)
The lanuage tag will not be shown if Conversations received a single body in
a language not understood by the user. (For example operating system set to
'de' and message received with one body in 'ru' will just display that body as
usual.)
As a guide line to the user: If you are reading a message where it is important
that this message is not interpreted differently by different people (like a
vote (+1 / -1) in a chat room) make sure it has *no* language tag.
