[Wiki] Use-cases, chat rules and configuration options


This editable wiki page exists to document and track the basic general use-cases for delta chat, together with corresponding 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” (New incoming Emails) to 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).

Real-world use-cases and their corresponding settings

(See below for configurations option details.)

During the initial configuration deltachat may ask which of three “Chat Approval Modes” should be used, or at least allow to revise and modify the default mode. (Also see https://github.com/deltachat/deltachat-core/wiki/IMAP-strategy#setup-first-start-after-installation for more IMAP specific details.)

Use-cases to Handle only chats:

(The email account may be shared with parallel classic email clients (MUAs) WITHOUT disturbing each other.)

  • Chat Approval Mode: “Default – Your email usage automatically approves chat contacts.”

    • optionally disable 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.)
    • optionally enable 2.1) Prompt/open tentative chat for email-chat compliant messages, to not have to manually browse for new chat messages from unknown contacts in the New (incoming) Emails (feasible with low-spam email accounts).
  • Chat Approval Mode: “Whitelisting – Strictly manual addition of chat partners.”

    • Disable 2.1) Prompt/open tentative chat for email-chat compliant messages.
    • Disable the scanning of messages on IMAP server for newly approved email receivers (MsgSCAN).

Use-case 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.)

  • Chat Approval Mode: “Blacklisting – You may only block individual known contacts, and still see spam.”
    • Enable 2.0) “open chat for all messages”. Also allows creating sender specific blacklisting rules.
    • Disable 1) “browse-able New (incoming) Emails” (no need, chats open automatically)

Usage Variants

multi-device usage (The message status “seen” on one device should spread (get synced) to all other devices.)

  • disable 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 devices to get notified even if another email client already set the status to “seen”.

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 firs 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:” ?

Missing configuration options

independent configuration options

  • [ ] 1) Show number of Incoming (new) Emails in chat list (formerly contact requests) on in the chat list screen by default (instead of in the menu).

    (See mock-up: While shown in the chat list it could be removed from the menu. Placing it in the header could take less space.)

The (silent) indicator is required to notice emails from not yet email-approved senders. Default: show (for example, below the chat list scroll box (like a footer), or in the header. 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 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)

  • [x] 3) [consolidated into a general feature “tentative chat” (see below) that does not need any configuration option]

  • [ ] 4) Have a max. chat message length configuration option (not counting attachments, default to 1000 chars?). Use MR_MAX_GET_TEXT_LEN for this as well? Then:

    • Do not open new chats for longer messages.
    • In already existing chats, silently show only an envelope icon, clickable to display the received (longer) email.
    • On the server, leave the longer messages in INBOX with “unseen” status,
    • and auto-move all shorter email messages from chat contacts into the chats folder, to avoid leaving NON-In-reply-to chat messages (MUA initiated chat messages) in the INBOX.
    • (Changing this 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-device Account 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).

general features

  • [ ] “tentative chats” (formerly option 3): Instead of the serial prompting 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”. And they 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,

  • [ ] 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.)

  • [ ] 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”
    • “is email (not chat)”
      • Then:
        • move it back to the “(…) New incoming Emails”
        • on the server: move it into INBOX with not-seen status and Chat-Version: false to delegate it to classic MUA. Also remove “mr.thread” from References?
        • only show it as an icon in the chat that belongs to the message, or
    • “belongs to another chat”

[Discussion] Make DC a replacement for MUAs?
Notify contact requests (let's discuss about this)
Add setting to show all people in DeltaChat
More sensible “Do you want to start a chat” prompt

@Admins: Please turn above post into a wiki page.


done so :slight_smile:


Thanks! How can I see it is a wiki page now?