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.
* draft a device message
* add others
* Update res/values/strings.xml
Co-authored-by: link2xt <link2xt@testrun.org>
* 'implovements in', remove double 'screen reader'
* move 'now' to the end; sounds as 'no' otherwise, and i also think, this is more fluent
* nicer group icon
* add an image showcasing the green checkmark
* more image like?
* split device message, delete old device messages
* add 'sync' to device message
---------
Co-authored-by: link2xt <link2xt@testrun.org>
* remove placeholder from
that way, it can be used instead of show_key_transfer_message_desktop,
which is showing the code more layouted
* mark duplicated autocrypt strings as deprecated
* remove "verified" from strings
* reword 'cannot introduce' to 'cannot establish guaranteed e2ee'
* removed old 'Verified' wording; this may be displayed only for legacy contacts until deltachat-desktop hides the row
* Verified 1:1 chats, Android UI (#2560)
Depends on https://github.com/deltachat/deltachat-core-rust/pull/4315/.
Follow-up for https://github.com/deltachat/deltachat-android/pull/2541.
- Show a "verified" icon on protection changed update messages
- Add C API
- Show a dialog over the input bar not only for contact requests, but also when the protection is broken (using the new method `isHalfBlocked()`)
- The positive button reads "OK" (as opposed to contact requests where it reads "Accept")
- Add SVG icons, remove PNG one
- Translations
- When tapping on the `DC_INFO_PROTECTION_{EN|DIS}ABLED` message, show more information (for now, it leads to the online preview of my FAQ PR)
- Block loading remote images in the "Full Msg View" not only for contact requests, also when the protection is broken (using the new method `isHalfBlocked()`)
- Show a big verified/crossed-out-verified symbol over the `DC_INFO_PROTECTION_{EN|DIS}ABLED` messages
- Fix a bug that was kind of present before (for contact requests) but only became really visible now:
- Set a draft with an image (or other attachment)
- Your chat partner breaks verification
- Expected: Both the input bar and the draft image are hidden by the input-bar-dialog.
- Bug behavior (before c31de5bcf): The input bar is hidden, but the draft image stays visible.
* change button order of verification-broken alert (#2621)
Having "OK" in the middle of the buttons is weird. The old order was:
```
End-to-end encryption cannot...
[More Info] [OK] [Scan QR code]
```
1. _If_ the main purpose of the dialog would be to "Scan QR code",
the text should point that out more, also the opening button.
Then, the button position would be correct, however,
it has to read "Cancel" then.
2. _However_, the main purpose of the dialog is to "Show Info",
"Scan QR code" is only an optional offering and the button a shortcut only.
And finishing "Show Info" is better done by a simple "OK".
Then, the "OK" should be rightmost.
This PR implements the second option, the buttons read as follows afterwards:
```
End-to-end encryption cannot...
[More Info] [Scan QR code] [OK]
```
* fix: load updated display name when chat protection breaks
* Implement feature flag for verified 1:1 chats
* Update res/values/strings.xml
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/connect/DcHelper.java
* Make another AlertDialog
* Revert "Implement feature flag for verified 1:1 chats"
This reverts commit 2efd17edfcf14e3cf89a6671df38647b552e5661.
* Fix typo
* email server->email provider
---------
Co-authored-by: bjoern <r10s@b44t.com>
Co-authored-by: adbenitez <asieldbenitez@gmail.com>
when talking about this function,
it is most times called 'Verified by me'.
this also makes translations easier to languages that
have diferent forms (as 'Du' vs. 'Sie' in german)
even though, we're most times using 'You' when the 'App talks to you',
we have some exceptions as 'Me' in the summary already,
where the 'You' does not work well.
(we leave the key as is, this is not really shown to translators anyways,
better key might be 'verified_by_self', however, it is not worth
opening this issue as the key is already in use -
and it is also not needed to force retranslation,
locales should use what fits and sounds best, may it be 'Me' or 'You')
* set targetSdkVersion to 33
* api33 requires permission NEARBY_WIFI_DEVICES to access wifi
not sure, if this affects getSystemService(Context.WIFI_SERVICE),
however, we anyway do not ask for permissions here but just try/catch -
if things do not work, we just cannot get the wifi name
(we're not asking for permission as this would require LOCATION in the past -
and that would scare users that just installed Delta Chat
and select "Add Second Devive".
this is the exact reason why NEARBY_WIFI_DEVICES was introduced, btw.
so in case getting the Wifi name does not work on api33,
we can consider asking for a permission - would still be on startup, however)
* update storage permissions in manifest
according to https://developer.android.com/training/data-storage/shared/media#storage-permission
* also update compileSdkVersion
* api33: adapt audio permission request
* api33: adapt gallery permission request
* request correct permissions for the 'photo rail'
* request correct permissions for avatar selection
* api33: storage and audio permission not needed
* add comment wrt 'camera roll'
* add POST_NOTIFICATIONS to the manifest, this already allows to enable notifications in the system settings
* ask for POST_NOTIFICATIONS permission on startup
* explain how to re-enable notifications if initially disabled
* prefer a device message over an alert
* show in settings if notifications are system-disabled
B. Petersen