however, for now, the start “from scratch” is by design to keep things simple. might be that this will change some day
btw: to setup a different device or to reinstall the app, you can do export a backup at “Settings / Advanced” and import it on install. the backup will include your old messages and setting then (similar eg. to whatsapp)
What happened was my phone died so I couldn’t back it up and hence were interested in just scanning the directory for existing messages. I do think that people would want that feature since it shouldn’t matter which device you are on. I get that you want to keep it simple and I agree with that. The question though is where to draw the simplicity line between common functionality and feature creep.
I think importing this old messages should be done with care, since it is worse that users get old chats they removed from Delta Chat back again, this can mess up their chats list, and give a buggy experience to users
@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
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).
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.
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
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.
There is something you need to explain, if you want “traffic-minimization” to breakmessage 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)