[WORKAROUND] Make new Delta Chat installation import old messages from IMAP directory

Ok, so you are actually mixing in email compatibility.

This aspect of message handling is to be dealt by the first chat client that notices the message. It moves the chat message out of the way of classic clients as soon as possible and reliable. It’s about moving chat messages into the chat folder, to avoid further email clients to download it from the INBOX.

EDIT: What is missing is still a solution to the usage-problem 4 (double notifications) at [Wiki] Use-cases, chat rules and configuration options, but this needs to work more generally, i.e. even before deleting messages after reception (before downloading or reading).

There is something you need to explain, if you want “traffic-minimization” to break message delivery to additional chat clients. (Note that multi-client syncing of the past chat histories is something different, that could be made gradually configurable, but would also be disabled completely by a “traffic-minimization” option that deletes messages from the server after they are read.)

Please explain: How many times do you think an unread message would get re-downloaded in your use-case unnecessarily, before it’s removed from the chat folder after it was read? (i.e. re-downloaded without the user actually wanting it, in order to be able to read the new message)

BTW: Concerning the context for “traffic minimization”, it’s not only for Cuba. You’re in good company. It’s certainliy useful for everyone with a non-fixed price (volume) data plan, even if only enabled temporarily during travel.

EDIT:

Actually, considering both aspects involved here, they can better be made independent, and not to disturb each other:

  • The discussed download minimizing part of “traffic-minimization” only needs an “only download new messages (not already read messages)” feature.
  • And a separate “server storage space usage limit” (auto-delete-server) option may independently limit the amount of messages on the server if needed (and can ideally be in effect completely automatically according to the available space quota on the server).
1 Like

Sorry to ask you here, but since the topic came up:
DC is able to know what is the storage capacity of the server. Or this is something ignored by him.

If you mean deltachat, this made me think it should be able to get the quota info:

And this, that it is possible to implement a first, minimal auto-delete-server feature even without quota info support:
https://github.com/deltachat/deltachat-core/pull/595#issuecomment-487703522

moving is also a waste of time and data traffic, and currently due to our bad network stability, some emails are not moved to the DeltaChat folder (probably due to network errors in the process) and stay in the INBOX after receiving them in delta, just delete it right away.

I only care it is downloaded exactly ONE and only ONE time, anything else is a waste to us.

I see that is a problem. IMAP clients (deltachat) need to be able to recover from network failures, though. The issue here is that deltachat is not detecting that the move failed and needs to retry.

In any case it is important to notice that not only you and me wants to minimize mobile traffic. There is no need to make this option detrimental to use-cases that include another client.

Messages ARE only downloaded one time

  • if you only have one client,

but also with more clients,

  • if devices are used sequentially, one at a time (the natural and intuitive way to minimize traffic)
    (message is read on whichever client that is currently active and downloads it)

To further enhance this to multiple-clients that are used in parallel, there is still no need to ever delete unread messages! The messages just don’t need to get downloaded.

The equivalent to the idea of deleting unread messages would be to immediately mark messages as seen/read on the server after downloading them (and thus prevent other “traffic-saving” clients from downloading it). EDIT: But a problem would remain. Which of multiple clients gets to download the message first, is random. (As always, it’s likely not the right one. :wink: ) It is therefore better to download unread messages to all devices that are connected at a given moment.

But still, downloading unnecessary stuff can be reduced, and in a much more general way in traffic-saving mode, by defaulting to downloading only the message list with the headers and subject text (which is often sufficient), and only download the full message or attachments on request: