Support using existing email accounts (not requiring dedicated accounts)

(After the discussion (or notice) that support will be dropped, e.g. here and here)

IMHO it is crucial for the success that deltachat continues to and operates well using one’s (existing!) account for both, chat and email. This is the key feature for deltachat adoption, network effects, and provider support (e.g. organizational recomendations). Who would want to break that?

Instead of dropping support for automatically sorting chat messages into a separate folder, any bug related to the IMAP and message handling should be fixed with some priority, because it affects all users and impairs the overall usage.

The drafting that aims to reach the “done right” status some day was only started at:
https://github.com/deltachat/deltachat-core/wiki/Use-Cases (user options and defaults)
GitHub - deltachat/deltachat-core: Delta.Chat C-Library with e2e chat-over-email functionality & Python bindings (background message handling)
It was done to arrive at solutions with your feedback.

For example, ways to solve this problem:

“Hey, my friend send a mail but it’s not in my INBOX, damn it …
oh it’s in DeltaChat – why the hell is it there?”

I don’t expect [that], unless it is a reply to the chat.

It’s a bug! :slight_smile:

The current use-cases draft (above) envisions to solve this situation by:

(1) Having deltachat provide an overview for two things:

  • a chat view that lists chats (read and answerd messages in chat folder, unanswerd still in INBOX), and easily undoable “tentative chats” for new messages from known contacts (message still in INBOX, allows user to choose the default email/chat preference for further messages from this contact)
  • and a new emails counter, linking to a view that lists the classic emails in the INBOX folder (without recognized chat messages).

(2) Use a message size limit to automatically identify emails considered as chat messages

(3) And to cover possible selection errors, as the user notices wrongly selected messages in deltachat quickly (due to the instant notification), provide an easy way to re-assign wrongly selected message back to the classic email INBOX again.

Optionally, it might also be a good option for some users to leave all current chat messages (but flagged seen) in INBOX until they are actually replied to in deltachat, thus to only move them into the chat folder after a reply got sent, allowing to also read and answer chat messages with classic email clients. (While chat messages always appear as alreday “seen” in classic clients to reduce the distrubances by high frequency chat traffic.)

1 Like

Cutting down to only support dedicated email accounts (instead of just recommending them where there are still problems) would really not be a solution, because all the same problems of longer emails sent to an account will just reappear over time (communicating with classic email accounts).

It’s a half thought.
And the (usual) result would be: Not solving (missing) the problem AND adding a lot of confusion (users having multiple new, old and incorrect email addresses)!

Thinking about problem solutions instead:

Syncing read receipts: They are probably ignored anyway by classic MUAs, if made compatible. But, if they should be moved out of the INBOX as soon as possible (instead of kept marked as “seen” for a while for all clients to pick them up), this might be a case for keeping an artificial deltachat status email message (with a date in the past?) in the INBOX, containing message status lists to facilitate syncing (allowing to move all the messages into the chat folder without clients having to maintain an additional “watch” on the subfolder).

Concerning the SENT folder, it seems more efficient to instead rely on the “allways sent to self” scheme anyway.

with a DeltaChat folder, things would be more complicated as it
this would require to watch several folders for changes -
up to three - DeltaChat, Inbox, Sent

Please post any problem that you may see, to take time to see if it is a real, understanding or motivational problem.

For example, why should syncing multiple clients be a practical problem with the AltMarkMove scheme (i.e. only INBOX watched, Messages IMAP-flagged as “seen” to hide in other MUAs, but considered new in chats until moved into the chat folder https://github.com/deltachat/deltachat-core/wiki/IMAP-strategy#principles), if newly connecting deltachat clients fetch the chat folder status once after startup?

Also remember that deltachat is also likely a good place for users to check for and write regular emails. (Using the “new (incoming) emails” and “new chat” options, as soon as subject handling is there https://github.com/deltachat/deltachat-core/issues/128).

1 Like

Here is a full solution for mobile-only notifications (without requiring a server filter rule that immediately marks chat messages as “seen” for AltMarkMove https://github.com/deltachat/deltachat-core/wiki/IMAP-strategy#principles):

If notifications for the general INBOX could be enabled in deltachat, they could be disabled in the mobile MUAs like K-9 and also on desktops. (Only one email tone played by the phone, no double notifications, user may then read the email on any device and MUA.)

(Previous topics have also been edited.)

It is also very important to consider how billions of email users see things. They are actually much more likely to additionally install deltachat, and multiply any success, than messenger users switching to some separate email account and messenger.

As past bug reports tell, deltachat is a no go if it creates a mess on the server (just think about the bug that prevented creating the chat folder at some providers). Deltachat got dismissed and only re-installed after creating the chat folder worked. Cutting down to only support separate accounts doesn’t really seem to be a fruitful option.

I agree with you that Delta Chat should be a “MUA done better”, I just wanted to put it in my own words:

There are already two chat networks/protocols (XMPP/Jabber and Matrix) which is already too much IMHO. Adding a third one (e-chat) probably won’t help. But there is no usable open source “Mail client that shows the mails as a chat” yet.

1 Like

Another idea to further improve the interaction with classic MUAs, instead of requiring separate email accounts, could be:

Detachat could automatically create subfolders in the chat folder corresponding to the chats. That could allow to browse the high frequency chat messages perfectly even with classic MUAs, if deltachat is also used.

(Edit: While, in the absense of a deltachat client, keeping the messages of a chat linked to the first message of the chat still allows to read chats in the INBOX with classic MUAs to some degree.)

1 Like

One of the most severe impacts of cutting down to require separate email accounts is breaking network effects:

One may still use deltachat to contact an arbitrary email address, but would actually not be able to recommend to the receiver to just install deltachat anymore, to get the chat interface and get the received chat messages automatically sorted into proper separate subfolders.

1 Like