@fnadde42 talked only about the first installation, and I’d rather have back all my chats instead of losing them all - and, again, it is only on first installation.
I would very much like this to be implemented someday, this, I think, is one of the main reasons why we are forced to live with a MUA.
For some time I have been thinking of some simple way to do it, but my limited knowledge makes it difficult for me.
This would only happen if deltachat does not properly remove deleted messages from the server. Is this the case?
@testbird if you delete a chat it is only deleted in your local database, messages stay in the server, so when you install if you load everything from DeltaChat folder, you load deleted chats,
even if this where not the case, it should ask the user if they want to load this old messages or not
Thanks, found that it’s still there… https://github.com/deltachat/deltachat-core/issues/210
All deleted messages clearly need to be deleted on the server as well (i.e. synced by default). Accordingly, for a synced client, also all messages need to be downloaded (synced) by default (i.e.if there is enough local storage space). Only this allows to keep multiple client devices in sync.
I think in Cuba you would not need to download any old stuff if a server storage limit is in effect to not keep much messages on the server (only archive them locally).
As I have always imagined, it is this way.
at the end of the chat, an option, “download more messages”.
And this would download 10, 20 or 25 more messages, as some MUA do. Little by little.
at the end of the chat list, an option, “download more chats”.
This would download 5 new chats, with at least 5 messages each.
I think this would be simple for the user.
For this, what we need is an option:
- “delete message from server when downloaded”
But that would necessarily not only prevent downloading old messages, but would break receiving a new message on any other device (multi-client sync). Even if the message was not read on the device that was first to download!
So I think a good and useful traffic minimization option would only have to include a “delete messages from server after they are read” feature (among other things).
I think your idea of incremental downloading of older messages might be a good (more conservative) default actually, but some button to sync up with (import / download) all messages from the server in a single step would still be in need to set up a new, fully syncing client.
You might want to keep track of a list of usefull traffic minimization features somewhere, yourself. The issues I did file all got closed without a fix.
the point is that some of us DON’T want synchronization at all, because re-downloading messages in other devices only means waste of money, in the case of Cuba, we want to download the message to one device and delete them from server instantaneously, so no other email client download, also avoid sending the self-bcc which is totally a waste for us, so there are a need to opt-out of synchronization and keeping the messages on server, and just use the email as the transport protocols
my point you quoted was to not delete after download but rather after the message was shown.
I guess no one wants to totally miss messages, only because another device, possibly at another location, happened to be online while the message arrived and downloaded it first.
Only deleting it from the server after it was shown should provide more reliability, while preventing re-downloading of already read messages.
most the time if you don’t want synchronization is because there are not such “another device” in the first place, if it was downloaded by one device it is enough and only one device should show it, what you suggest will keep the same issue of the same message showing on more than one client, the hole point is to download only once, if the message is in one device it is save to delete (in this scenario of opting out synchronization)
I still get the impression that the difference between delete-after-message-was-downloaded and delete-after-message-was-read might not be clear yet.
(Especially when considering that we are both talking about the case in which some traffic saving option is enabled, and among other possible things, its desired effect is to not keep any unneccesary, old messages on the server, to avoid archive syncing traffic.)
It’s a corner case to avoid a “failure to deliver”.
Ok, if there are no other devices as you say in the first place, how should the same message show up on more than one client? I think that may just have been thought or written to fast.
All that happens with “delete-after-message-was-read” is that only an unread message will (also) be downloaded and show up on any further device, if there is one. After the message is read, there will be no further downloads by newly re-connecting clients, because the message gets removed from the server after the first read. As desired, generally messages that are read while another client is turned off or disconnected won’t be re-downloaded (synced) by that other client later on.
The delete-after-message-was-downloaded is just going one step too quick, it does not save any traffic in the single client case, but breaks reliable reception with multiple clients, even if there is only one single client online at any given time.
Not quite, if the message has not been read on one device, then deleting it on the server will prevent users to ever be able to read it on another device.
Syncing up on already-read messages may be disabled for sure, but not allowing newly connected clients to download new, still-unread messages makes for flaky messaging.
easy question, because there are only one device with one delta chat… and one classic email client that was there before my geeky friend came to me with this Delta-thingie, so the soon you remove it from the inbox the better, tons of non-tech people seems not to understand how delta or email works and complains about Delta Chat “sending spam to their inboxes”, there are no real need for keeping them until unread, if you want synchronization just use Delta Chat as it is now and you will be happy, but please don’t try to mix sync stuff when what we want is to avoid sync quirks at all, we don’t care about “reliable reception with multiple clients”, just don’t, we are talking about opting out sync so “breaks reliable reception with multiple clients” is a feature
that is the whole point!!! what we want is “ever be able to read it on another device”, we will read it in only one device, you miss what is important here: to avoid re-downloading messages because it costs money, “reliable reception with multiple clients” is a luxury for people in developed countries
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.
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).
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:
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. ) 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: