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.
Notifications from strangers are disabled by default in order to cope
with spam. On the other hand, this complicates contacting other users
for the first time, which leads to a bad user experience.
This further reduces the minimum API level to 16, which should encompass
most users stuck on older versions of Android (mainly BlackBerry OS and
Jolla users).
Several issues reported by code analysis were fixed, mainly around issues
with layouts.
this commit is just to make policies equal and independent on various android
versions. support for http might be removed in the future across all versions.
after receiving a SignalMessage that can’t be decrypted because of broken sessions
Conversations will attempt to grab a new pre key bundle and send a new PreKeySignalMessage
wrapped in a key transport message.
XMPP uris in the style of `xmpp:test@domain.tld?body=Something` can be used to
directly share a message with a specific contact. Previously the text was
always appended to the message currently in draft. The message was never send
automatically. Essentially those links where treated like normal text share
intents (for example when sharing a URL from the browser) but without the
contact selection.
There is a concern (CVE-2018-18467) that when this URI is invoked automatically
and the user is currently drafting a long message to that particular contact
the text could be inserted in the draft field (input box) without the user
noticing.
To circumvent that the text shared over XMPP uris that contain a particular
contact is now appended only if the draft box is currently empty.
Sharing text normally (**with** manual contact selection) is still treated the
same; meaning the shared text will be appended to the current draft. This is
intended behaviour to make the
'Hey I have this cool link here;' *open browser*, *share link* - secenario
work.
