I see there has been some contention related to the implications the switch to v2.x had for the user experience of people who, like myself, use Delta Chat in contexts where most of their peers use different email clients. The things that I myself find particularly annoying in this regard are the removal of autocrypt support and the duplication of contacts in the chat list. Especially the case where the switch to v2.x has resulted in a downgrade of encrypted (albeit unverified) chats to entirely unencrypted chats.
However, before addressing these issues in more detail, I would like to ask a somewhat more fundamental question: Is there any interest in addressing such issues? Or is the general sentiment that Delta Chat is meant to be used primarily with chatmail and that using it in non-chatmail contexts is a deprecated use case?
Non-chatmail is supported. Especially if you have your own domain or small email server managed by you or local admin, you may prefer using it over chatmail relays. The only function that depends on chatmail currently is push notifications over Google FCM and Apple Push Notification Service are not supported in this case. This may change with draft-gougeon-imap-webpush-03 and mox server implementation of it, but don’t rely on it happening soon.
Autocrypt support is not removed. Unencrypted messages still have Autocrypt header, so if you send a message to Thunderbird user, Thunderbird user can import your key and send you an encrypted and signed message back. Receiving such message should result in a creation of a new 1:1 encrypted chat. What is missing is the upgrade path for two Delta Chat clients who have only shared an email address:
Encrypted group chats, even non-protected/verified, are converted to encrypted chats. If the chat is converted to unencrypted during upgrade, it is either because it was not encrypted at the time of upgrade (one of the members did not have an usable key) or because the chat was originally created from a non-chat message. Other cases are likely bugs.
If you want to see better support for interoperability with other clients or unencrypted email support, the best is to create fine-grained topics with a particular use case that you think is not addressed and exact steps for reproducing the issue in case of bugs.
When bugs are reported with enough details, they result in fixes, e.g.:
For those on mobile Linux, UnifiedPush also offers Chatmail-independent push functionality. Alas, Apple and Google do not seem keen on supporting this open standard.
There are initial plans to add this to the DeltaTouch client:
Thanks for your reply. As I am using Delta Chat myself, I am aware of
the current state of affairs; so my question was more about the future
direction of the project. I have actually created a number of fine-grained
issues already. Those would be the issues number 3900 through 3906 below GitHub · Where software is built. However, they
have all been closed as “not intended” without being addressed. I also
understand that other community members have had a similar experience;
and I even seem to remember a reply suggesting that they fork the project
if they are dissatisfied with the UX (unfortunately, I don’t have a link
to that reply handy at this moment).
So my question would be if there is any interest in addressing usability
issues related to the UX of using Delta Chat in predominantly non-chatmail
settings. Or should I expect the UX in that setting to degrade further?
Do I understand you correctly that there is indeed an interest in
improving that UX again? And if so, which channel should I use to bring
up those issues?
If there is no interest in addressing these kinds of issues, that would
also be totally legitimate, of course. As has been mentioned in that
previous post I have seen, users are always free to create a fork if
they are dissatisfied with the direction of any Open Source project.
However, I would like to know where the project is heading in general
– because I do not want to fill your issue trackers with things you
might see as irrelevant.
Delta Chat Android issue tracker is a backlog of tasks that are already agreed to work on or bug reports. Bug reports are fine to file directly there. Feature requests however should be filed on the forum.
When you click on a “New issue” on GitHub, the first thing you should see is this:
If you click a “Bug report”, it is automatically tagged with a “bug” and there is this text at the top of the template again redirecting to the forum:
Please fill out as much of this form as you can (leaving out stuff that is not applicable is ok).
If you are sure something is a bug or regression, it is fine to file it directly into the issue tracker, but then at least the version should be specified, see the rest of the template.
Since I cannot seem to see the reply I sent about an hour ago, I will repost it below. Please excuse this if this should lead to duplication.
@Minim: Thanks for bringing up UnifiedPush. In my case, Delta Chat is
actually the only app on my phone that could possibly benefit from push
notifications; so using IMAP IDLE (as is the current state) works great
for me. But maybe this will be useful for others.
@Raiden: Thanks for posting that link. I was actually referring to a
different one, but that one is also interesting.
I myself am actually quite happy with Delta Chat pushing end-to-end
encryption. I am more concerned with the fact that I seem to get less
end-to-end encryption after the v2.x update instead of more. This
is partially related to the fact that Autocrypt does not seem to
work properly any more. And also because the strong split between
purely end-to-end encrypted chats and purely non-e2ee chats means that
conversations with certain peers are duplicated (and thus downgraded)
as soon as those peers send a single non-e2ee message. Previously, I
was – for a rather short time – able to reply to non-e2ee messages
using end-to-end encryption; and I rather liked that.
@link2xt: Thanks for explaining where to open which kind of issue. I
was indeed a little at a loss as to where I should open issues. I have
now reopened the issues I mentioned earlier either in the bug tracker
for Delta Chat core
I think both Raiden and Seifferth are right; the idea of UnifiedPush is that only one program, ntfy, has to run in the background to collect all your push notifications. If you have only one program with push notifications, leaving it up will work just as well, though I’d hope ntfy would be a bit lighter on my battery than a full Deltachat client.
@Minim: Thanks for bringing up UnifiedPush. In my case, Delta Chat is
actually the only app on my phone that could possibly benefit from push
notifications; so using IMAP IDLE (as is the current state) works great
for me. But maybe this will be useful for others.
@Raiden: Thanks for posting that link. I was actually referring to a
different one, but that one is also interesting.
I myself am actually quite happy with Delta Chat pushing end-to-end
encryption. I am more concerned with the fact that I seem to get less
end-to-end encryption after the v2.x update instead of more. This
is partially related to the fact that Autocrypt does not seem to
work properly any more. And also because the strong split between
purely end-to-end encrypted chats and purely non-e2ee chats means that
conversations with certain peers are duplicated (and thus downgraded)
as soon as those peers send a single non-e2ee message. Previously, I
was – for a rather short time – able to reply to non-e2ee messages
using end-to-end encryption; and I rather liked that.
@link2xt: Thanks for explaining where to open which kind of issue. I
was indeed a little at a loss as to where I should open issues. I have
now reopened the issues I mentioned earlier either in the bug tracker
for Delta Chat core
No. Funneling all push notifications thru UnifiedPush means fewer apps are waking the device up to poll, and thus the battery lasts longer. I don’t have Google Play Services on my phone and a couple weeks ago I went thru all my FOSS apps and set up UnifiedPush on the ones which support it, and got a noticeable bump in battery life from doing so.
