Use-cases, chat rules and configuration options

1

This publicly editable “wiki” post exists to document and track the basic use-cases (and corresponding presets) for delta chat, together with more detailed customization settings, as well as contact or message specific 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: [consolidated] support for recognized use-cases · Issue #229 · deltachat/deltachat-android · GitHub

The old 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. Also, by default, deltachat users are not directly reachable by email contacts.
    • 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 - #24 by testbird
  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 could ask which of three “Chat Approval Modes” (working title) the user wants to be used (also see GitHub - deltachat/deltachat-core: Delta.Chat C-Library with e2e chat-over-email functionality & Python bindings for more IMAP specific details.).

But more simply, deltachat could instead just use the most common-ground, universal, selection of the presets as default, and just 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.) Better name for "Contact requests" · Issue #5 · deltachat/interface · GitHub

(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!

  • 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 GitHub - deltachat/deltachat-core: Delta.Chat C-Library with e2e chat-over-email functionality & Python bindings), 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 Emails from other MUA are shown in the chat · Issue #49 · deltachat/deltachat-android · GitHub, spam incidents, and issues like Issues · deltachat/deltachat-android · GitHub) In the process ask the user to select if the message is

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

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

14

I think we could solve the confusion problem around chat aproval with a better help site that explains everything and maybe a small wizard at the first start of the app. But actually such a wizard is a risk, because most people want to use it simply as a messenger and have already an email app connected to that, and might be scared away by such a wizard.
Not to mention that WhatsApp is not only through the network effect as successful as it is, but also because the simple 2 step setup:

  1. Put in your phonenumber
  2. recieve the sms and put - in the code (they even do that step automaticaly if you give them access to your sms messages)
15

When we do a wizzard it needs to be carefully planed so it doesn’t scare users away.

16

Yes, that’s why I proposed just needing one configuration option "Who should be allowed to contact you directly in Delta Chat? (nobody, known contacts, everybody), and for new installations simply defaulting to “known contacts” (to receive new chat messages and qualifying short emails).

And also having a “new emails” counter enabled for new users, which can be easily disabled, but allows new users to see (manually browse) the recent messages in the INBOX, to notice, react to and contact email contacts.

Thus overall not having to need any wizard, or maybe even necessarily a reachability FAQ, because the setting pretty much explains it.

1 Like
17

I like the idea to get a peek on the normal emails.

1 Like
18

Steps like introducing the “show emails” option and it’s default “no”

Believe it or not that was actually a community request. “I don’t want to get emails in deltachat, I have my mail program/app for that.”

Sure I believe you. I even think I saw such requests for this use-case myself somewhere, but concluded that just doing away with the emails (and by default, nothing less) and then only optionally showing emails doesn’t cut it just right.

It unfortunately cuts off a large part of the deltachat users from being reachable for a chat by classic email contacts.

The problem can be solved elegantly though, I think,

  • with that metric for emails that qualify emails as chat attempts, together with
  • changing the “show emails” option into a broader reachability option (for both chat messages and chat qualifying emails), and
  • the option to hide that default “new emails” counter (which helps new users to get started with their empty chat list).
19

I agree with all of the above for all cases where it is used simultaneously with an MUA, but I will continue to defend a simple alternative for those who decide to use it as the only application to manage their mail.

That is, when the “ALL” option is selected, all messages must enter the chat list without so many obstacles.
If the new message is not in the contacts, then ask for confirmation as it is done in most messengers.

ACCEPT:
to start chatting.

BLOCK:
Remove messages as soon as they enter the server.

Maybe, a third option.

IGNORE:
It is not displayed in Delta.chat but it is not deleted from the server.

1 Like
20

The wiki post proposes having “tentative chats” as long as no reply was sent. It means the chats are immediately created and inspectable, but still show an “X” button, that allows to delete the entire chat right away if it isn’t wanted. And triggers selection checkboxes whether the message was an

email (moved back to INBOX), or just

junk/spam (moved to spam detection folder),

and action buttons to either welcome or block the contact (FROM address) for further messages.