This publicly editable “wiki” post exists to document and track the basic use-cases (presets) for delta chat, together with corresponding customization settings, and contact or message specific customization rules.
The (missing and implemented) rules and configuration options needed to configure deltachat properly for these use-cases are listed and explained in more detail further down.
Corresponding (old) issue: https://github.com/deltachat/deltachat-android/issues/229
The current default usage mode is:
The user needs to manually follow and read through the “contact requests” (maybe better called “Incoming E-Mail” or just “E-Mails”?) to see and catch chat attempts by unknown contacts… For known contacts, incoming new chats are not opened before confirming an “Open Chat?” prompt, but afterwards all following messages from that contact are considered chat messages (bad).
Major Usage-Problems to target:
All INBOX messages (incl. non-chat messages) are downloaded to the mobile device, causing unnecessary traffic. (Are unaccepted chats downloaded anyway?)
- It should be enough to only download the message list without body and attachments.
- It should be enough to only download the message list without body and attachments.
- Messages fill up the device and the server: https://github.com/deltachat/deltachat-core/issues/244
Stepwise full solution description at: Reduce space on internal storage, disk full
- After starting a chat with a known contact, all email messages from that contact, even classic ones, only open in deltachat.
- Introduce email message metrics, to detect which classic emails that are not chat-resposes should start or prompt to start a chat, and to improve the differentiation when displaying emails in chats. See config option 4) below.
- Make classification errors absolutely non-critical, see “tentative chats” and “Function to re-assign selected messages” under general features below.
- Incoming chat messages are signaled twice, not only by deltachat but also by classic email clients like K9 etc.
- See “limitations” and workaround in [Wiki] IMAP strategy to chat within the email ecosystem https://github.com/deltachat/deltachat-core/issues/495#issuecomment-480486313
- Mark all chat messages as “seen” immediately (lowers display priority in classic MUA), but not only classic email messages, which should also only be moved into the chat folder after they have been answered in delta chat. (Keeps them available for answering in classic email clients until answering in chat.)
A minimal set of configuration options, the broadest default, customizable to every real-world use-case
During the initial configuration deltachat MAY ask which of three “Chat Approval Modes” (working title) should be used (also see https://github.com/deltachat/deltachat-core/wiki/IMAP-strategy#setup-first-start-after-installation for more IMAP specific details.). But we could just use the most common-ground preset as default, and allow to revise and modify the chat approval mode in the advanced options.
The easy “top-level” preset selection of the “Chat Approval Mode” should use very simple wording, and allows to configure its (4) more detailed and advanced sub-options in a single step (toggle the preset’s specific combinations):
Example wording for selecting a basic preset:
Who should be allowed to contact you directly in Delta Chat? :
(Or: Listen for chat-starting messages from?)
- Nobody (only manually started chats)
- Known contacts (address book and email-approved)
- Any contact (beware of spam)
(This design replaces (and solves) the non-uniform reachability problem (fragmentation of the installations) caused by the current “Show email?” configuration. The email-to-chat interaction can be better solved by the start-chat metrics for email messages. Only selecting a preset for more detailed options does also allow for further advanced customization.)
The best default preset for new installations is to “only listen for known contacts” (it provides spam protection, least hassle to set up contacts, and backwardds compatible short email message chatting works seemlessly out-of-the-box with known contacts). It enables to automatically start a chat for all received chat-messages, and to prompt when receiving email messages that are in between a short chat and a classic longer email message.
(See further down for more details about the individual custom-configuration option numbers.)
First, the two presets to Handle only chats:
(The email account may be shared with parallel classic email clients (MUAs) WITHOUT disturbing each other.)
Listen for “Nobody”:
- Chat Approval Mode: “Whitelisting – Strictly manual addition of chat partners.”
- Disables option 2.1) Prompt/open tentative chat for all email-chat compliant messages.
- Disables the scanning of messages on IMAP server for newly approved email receivers (MsgSCAN).
Listen for “Known contacts”:
- Chat Approval Mode: “Default – Your email usage automatically approves chat contacts.”
- Users may find it useful to optionally disable option 1) “browse-able New (incoming) Emails” (once the user understands it, has its complete, limited list of chats partners, and has no need to look for new chat requests anymore. (All emails are handled in the MUA.)
- Users may also find some of the following useful
- setting option 4) max. chat message length to zero, to disable prompting for any classic email message.
- enabling option 2) Prompt/open tentative chat for all email messages
- or enable option 2.1) Prompt/open tentative chat for all email-chat compliant messages, to not have to manually browse for new chat compliant messages from unknown contacts in the New (incoming) Emails (feasible with low-spam email accounts).
Plus one preset to Handle all messages, chat and email:
(Deltachat is resposible for all messages of the email account, i.e. used as full email client, aka MUA.)
Listen for “Any contact”:
- Chat Approval Mode: “Blacklisting – You may only block individual known contacts, and still see spam.”
- Enables option 2.0) “open chat for all messages”. Also allows creating sender specific blacklisting rules.
- Disables option 1) “browse-able New (incoming) Emails” (no need, chats open automatically)
When switching to another listening preset, all optional and not mentioned options above may be left as they are.
(The message status “seen” on one device should spread (get synced) to all other devices.)
disables option 5) “Account read by multiple users” Notify and show message as new, even if message was already seen elsewhere.
Keep this enabled (default) when account is shared with other users, or a POP client (MUA), that may change the status to “seen”. This allows a devices to notify the user about new messages, even if another email client already set the status to “seen”.
Missing advanced configuration options
(Easily toggled by the simplifying preset selection in the previous section.)
independent configuration options (numbering used above)
[ ] 1) Show number of Incoming (new) Emails in chat list (formerly contact requests) on in the chat list screen by default (instead of only in the menu).
See mock-up. (While the icon is sown on the chat list view, the “Email / contact requests” menu entry could be removed from the menu:)
With deltachat listening for start-chat email messages according to the configured preset, this (silent) indicator is only required to also notice new classic emails in deltachat. Default: hidden (Notification sound disabled by default.) https://github.com/deltachat/deltachat-core/issues/48#issuecomment-372341852
(2) Chat options for New (incoming) Emails:
[ ] 2.0) Prompt/open tentative chat for all email messages. Default: off
[ ] 2.1) Prompt/open tentative chat for all email-chat compliant messages. A convenience vs. noise option, allows to have chats without having to always look through the New incoming Emails for new contact requests. Default: currently on, change to off? (if on, one can again only rely on a spam filtering to prevent annoyances, once the email chat standard is commonly used by spammers)
3)[consolidated into a general feature “tentative chat” (see below) that does not need any configuration option]
[ ] 4) Have a max. chat message metrics configuration option (not counting attachments, default to 240 chars, 3 linefeeds?), see here and Classic email listening: "start-chat" metrics for classic email client messages (max. length & newlines). Use MR_MAX_GET_TEXT_LEN for this as well?
- Do not open new chats for longer messages.
- In already existing chats, show longer emails only silently as an envelope icon, clickable to display the received (longer) email.
- On the server, leave the longer messages in INBOX with “unseen” status,
- and only auto-move shorter email messages into the chats folder, after they were accepted for a chat, to allow answering all regular short emails with classic MUAs and avoid leaving NON-
In-reply-tochat messages (MUA initiated chat messages) in the INBOX.
- (The changes here may also require adjusting any SIEVE filters accordingly.)
=> In conjuction with the general “re-assign” feature below, this allows separated handling of slower paced, elaborated E-Mail exchanges in MUAs, without prompting or disturbing chats – while allowing chats to be aware of, and able to refer to, parallel emails.
[ ] 5)
Single-user multi-deviceAccount read by multiple users: Notify and show message as new, even if message was already seen elsewhere (not just new AND unread messages). Default: true (Avoids unreliable notifications for users that still have some parallel POP client configured.) With AltMarkMove (“seen” only if moved/disappeared from INBOX https://github.com/deltachat/deltachat-core/wiki/IMAP-strategy), a disabled setting must not be effective (greyed out then).
[ ] “tentative chats” (formerly option 3): Instead of the serial prompting of the user to open a chat (without providing any overview about the pending chat attempts), open “tentative chats” in the browse-able chat list. These tentative chats, defined by their not-yet-answered state, have an “X” button to easily dismiss the chat from the chat list again and move the contained message(s) back into the “New incoming Emails” (INBOX). And they should also have an “X” button somewhere within the not-yet-answered chat, for quick dismissing of the chat after reading the full message. On dis-mission, ask about an always-deny rule/this-is-spam (re-assign actions, see below). Correspondingly,
[ ] (Only needed for a case-by-case chat acceptance mode.) on first answering a tentative chat, as well as on answering a message from the “New Emails” (former contact requests), ask the user about adding an allow-rule for the contact (and possibly adjust any SIEVE filter automatically.)
[ ] (May be avoidable, if sorting works well and long emails are only shown as icons in the chats.) Function to re-assign selected messages which erroneously appeared within a chat (existing or ad-hoc), instead of only allowing to delete them. (This is a conclusions from https://github.com/deltachat/deltachat-android/issues/49, spam incidents, and issues like https://github.com/deltachat/deltachat-android/issues/324.) In the process ask the user to select if the message is
- “is spam”
- move it into the spam folder on server
- fix the origin status in deltachat. (https://github.com/deltachat/deltachat-android/issues/240)
- “is email (not chat)”
- move it back to the “(…) New incoming Emails”
- on the server: move it into INBOX with not-seen status and
Chat-Version: falseto delegate it to classic MUA. Also remove “mr.thread” from
- only show it as an icon in the chat that belongs to the message, or
- “belongs to another chat”
- let user select the chat to re-assign the message to https://github.com/deltachat/deltachat-android/issues/324).
- “is spam”
Missing customization rules
(The following checkboxes are there to track the implementation status.)
The user should be asked to select the rules upon answering or moving/deleting the first message from a new contact (selection depends on type of reaction, see general features below), and the rules are saved to determine further thread handling.
Complete the set of contact and message specific handling rules:
sender specific chat/email rules
- [x] sender specific rules to never open a chat (black-outs, overrides general settings),
- [ ] sender specific rules to always open a chat (white-ins, overrides general settings)
message specific rules
- [ ] always prompt/open chat if a known sender wrote a email chat standard compliant message (overriding sender specific “never assume a chat for new emails” when sender is known to use a chat messenger)
- [ ] prompt/open chat if a known sender used a subject beginning with "Chat: " (case insensitive) (override for sender specific “never assume a chat”)
- [ ] Allow known contacts to send a message beginning with an “ALERT” or “ALARM” subject (case insensitive) to override general muting (but not the per contact and whole system muting?). To allow paging for really important messages but being able to block.
- [ ] Allow the sender to suppress paging the receiver for sending low priority, silent (status) messages. Any idea for an intuitive method here, anyone? Maybe using braces “(Chat:)” or a subject not beginning with “Chat:” from a known chat contact sent with a chat program? “Silent Chat:”, “Whisper:”, “Silent E-Note:” ?