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

#1

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 targeted:

  1. After manually accepting or starting a new chat with a known contact, all email messages from that contact (even classic ones) only open in deltachat. Users are also not directly reachable by email by default.
    • Use a proper “reachable by” chat interaction setting
    • 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 long emails as icons in chats. See config option 4) below.
    • Make classification errors absolutely non-critical, see “tentative chats” and possibly “Function to re-assign selected messages” under general features below.
  2. All INBOX messages (incl. non-chat messages) are downloaded to the mobile device imediatey, causing unnecessary (mobile) traffic. (Are unaccepted chats downloaded anyway?)
  3. 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
  4. Incoming chat messages are signaled twice, not only by deltachat but also by classic email clients like K9 etc.

[…]

A minimal set of configuration options, customizable to every real-world use-case

During the initial configuration deltachat MAY simply 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 also just use the most common-ground selection of the presets 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 is there to easily configure (4) much more detailed and advanced sub-options in a single step (toggles the preset’s specific characteristic 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?)
(Or: Be reachable in Delta Chat by? )

  1. Nobody (only manually started chats)
  2. Known contacts (address book and email-approved)
  3. Everybody (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.

Explanations

(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”:

  1. 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”:

  1. 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”:

  1. 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.

Usage Variants

multi-device usage
(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. Enabling this allows to have chats without having to always look through the new incoming emails for new contact requests. But if on, there is again only spam filtering to reduce annoyances. It allows unknown spammers to abuse the email chat standard. Default: currently on, change to off!

  • [x] 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?

    Then:

    • 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-to chat 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-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 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”
    • “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”

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:” ?
3 Likes
[Discussion] Make DC a replacement for MUAs?
Subject of emails
Let's switch to a new messenger?
Send location only one time Android V.0.301
No contact request is poping up
No contact request is poping up
No contact request is poping up
Chat- and Document-style e-mail addresses and interactions
No contact request is poping up
No contact request is poping up
Make Contact Requests more visible
Classic email listening: "start-chat" metrics for classic email client messages (max. length & newlines)
Add setting to show all people in DeltaChat
Show classic emails for ALL (Advanced Settings) does not work
More useful "reachable by" chat interaction setting
[Discussion] Make DC a replacement for MUAs?
Make Contact Requests more visible
Notify contact requests (let's discuss about this)
Need some basic explanations about Delta.Chat
Are unaccepted chats downloaded anyway?
More sensible “Do you want to start a chat” prompt
No contact request is poping up
Make Contact Requests more visible
#2

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

1 Like
#3

done so :slight_smile:

#4

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

#5

I can’t add the feature proposal category to the existing [wiki] threads (get’s lost after editing the top post).
Can maybe someone give it a try to fix this please.

#6

testbird, I really like the idea of a wiki, but this interface doesn’t really look like a wiki I fill a bit disoriented when reading it :dizzy_face:

#7

is this a post you just want to treat as a wiki, or this is supposed to be a real wiki???

#8

well, can we add a “lite mode” request to this wiki???, that is a common request from users on slow/paid networks

#9

Yes, this “wiki mode” is strange here. When the admins enable the wiki mode, the top post should become editable not only by the original author. At least I see an “edit” button instead of a pencil.

#10

The devs closed the old wiki saying this forum feature that allows to make some posts publicly editable is the new wiki.

#11

Editing seems also to be available through the changelog view (button at the top right of the post).

1 Like
#12

The “Chat Approval Modes” provide simplified switching between these basic preset modes (with their corresponding default settings),so users don’t need to go into the advanced settings. (Allowing to change the basic mode without having to fiddle with every customization option.)

(related: post)

#13

Any other ideas for a simplified wording for the basic “Chat Approval Mode” selection?

Listen for chat-starting messages from?:

  • Nobody (only manually started chats)
  • Known contacts (address book and email-approved)
  • Any contact

The default for new installations could be the second option, together with opening received chat messages automatically and to prompt when receiving short email messages.

If desired or needed, the 4 missing configuration options + 3 general features (from above, and used by these three presets) should still allow to further customize deltachat to (almost?) any use-case (advanced options).