finishing (sending a key transport message in response to pre key message) as
well as reparing sessions will leak resource and availability and might in
certain situations in group chat leak the Jabber ID.
Therefor we disable that. Leaking resource might not be considered harmful by
a lot of people however we have always doing similar things with receipts.
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.
This will reduce traffic by limiting the variety of different caps version hashes.
It might also improve privacy by not leaking fdroid vs playstore vs self build information
* we still include DNS servers from VPNs because of edge cases where the XMPP server is hosted in the VPN
* on older Android versions we don’t know if a network is active or not (activeNetwork == null)
fixes#3465
when receiving a FCM push message for a channel the user is no longer in (this can happen when the disable command failed) an attempt will be made to explicitly unregister from the app server (which in turn will then send item-not-found on next push)
Staying connected to a MUC room hosted on a remote server can be challenging.
If a server reboots it will usually send a shut down notification to all
participants. However even if a client knows that a server was shut down it
doesn’t know when it comes up again. In some corner cases that shut down
notification might not even be delivered successfully leaving the client in a
state where it thinks it is connected but it really isn’t.
The possible work around implemented in this commit is to register the clients
full JID (user@domain.tld/Conversations.r4nd) as an App Server according to
XEP-0357 with the room. (Conversations checks for the push:0 namespace on the
room.)
After cycling through a reboot the first message send to a room will trigger
pubsub notifications to each registered full JID. This event will be used to
trigger a XEP-0410 ping and if necessary a subsequent rejoin of the MUC.
If the resource has become unavailable during down time of the MUC server the
user’s server will respond with an IQ error which in turn leads to the MUC
server disabling that push target.
Leaving a MUC will send a `disable` command. If sending that disable command
failed for some reason (network outage) and the client receives a pubsub
notification for a room it is no longer joined in it will respond with an
item-not-found IQ error which also disables subsequent pushes from the server.
Note: We 0410-ping before a join to avoid unnecessary full joins which can be
quite costly. Further client side optimazations will also surpress pings when
a ping is already in flight to further save traffic.
We have seen some weird CursorIndexNotFoundException that we were unable to reproduce.
We assume that going forward (moveToNext()) through the cursor instead of (moveToPrevious() fixes that issue
if your Conversations installation is older than December 2016 (version 1.15.0) the backup would
include historic data that a current installation is not able to read on restore.
This commits excludes that data from the backup.
If you had problems importing the backup you need to create a new backup after this patch
There are countless arguments on both sides of the Jabber ID vs XMPP address
debate which makes deciding between them a really tough decision.
Pro Jabber ID
* Jabber is easier pronounce
* We have always called it Jabber
* Jabber is more recognizable (This claim can not be backed up by Google Trends)
* Jabber ID has a nicer typography
Pro XMPP address
* People like the term address. People also liked 'Chat address' or
'Conversations address'. Address is also used in Email address or other
protocols. Even if people don’t understand the 'XMPP' part of the term they
might understand the 'address' part and know what is going on.
* While people might have heard of Jabber rather than XMPP; people have heard
of it in the 00s and associate it with something old. Depending on the
target audience this is a good thing. And people who value sustainability
know what XMPP is anyway.
* Jabber is a Cisco product. If we were to succeed in making 'Jabber' cool
again we don’t want to share that success with Cisco. What has Cisco ever
done for us? Aside from providing us with a venue for the XSF summit. And
building nice aqueducts.
* The Cisco owned trademark is a damocles sword. While the XSF technically
has the right to hand out sublicenses to use the term this can be a lengthy
process. And automated filter system that for example monitor Google Play
store descriptions don’t care that the XSF has the rights or that the terms
of use are more nuanced. They just see a trademark and reject the
publication. And we all know how impossible it is to speak to an actual
human at Google.
