with chatmail, providers exist that allow to send encrypted mails only.
pulling in the system address book unconditionally for chatmail will harm UX
as for most of these addresses,
no public key will be known until eg. a QR code is scanned.
we may think this over in the future.
note, that one usually also can create a Delta Chat chat from the address book,
so, this works also without having Delta Chat pulled in all addresses
(which has some issues, https://github.com/deltachat/deltachat-android/issues/2923 )
* add strings for 'Invalid Unencrypted'
* add a 'learn more' dialog for 'invalid unencrypted'; the dialog shows the known 'scan qr code' and the known help for it
* clarify wording, add 'for this chat'
* do not linkify domains
* draft a new welcome-message with focus about how to get in contact; the 'Invite Link' implies also contacts with delta chat not installed yet (we could also add a QR code to the invite page as well as adding a 'Manual contact' that fits for classic mail)
* add some dc background info
* rename 'Device Talk' to 'Info'
* Revert "rename 'Device Talk' to 'Info'"
This reverts commit 027e205718c2923bc774a2d069f3283fc9e0e7bd.
* improve english grammar, thanks @adzialocha
the hint already led to confusion on 37c3 testings of chatmail.
the hint that appears when a one-to-one-chat was just created manually
(by entering an email address manually) is a bit misleading when using chatmail,
as it says it 'does not matter if the other side uses Delta Chat'.
this is still true, however, with chatmail it is needed that messages
outside the chatmail-server are encrypted,
which is arguably not so easy without delta chat and QR code scanning.
this PR therefore just removes the hint;
it would still be great if the error message 'cannot encrypt' is improved,
however, this is another thing.
adbenitez