testbird: did you remember that you said " But why should it be necessary for syncing chats and groups, if chats get deleted together with deleting its last message."??? you say deleting 1 message (the last one) would delete the chat!!! that is what I’m talking about.
That referred to your
I think it is not necessary that deltachat creates subfolders, even though I would like them because it would make browsing of the chats with a classic MUA nicer.
That was my question to you. Maybe you have found a reason I don’t see yet, but you will have to answer the question. You would have to elaborate a little more, though.
testbird:
you say eliminating the last message delete the complete chat from DC
then if I delete the last message manually using a MUA, and open DC the complete chat is gone, while in the server the rest of the message in the chat remains, this is what do you mean???
you say eliminating the last message delete the complete chat from DC
Yeah, if the database query returns no messages with a particular To: field then there shouldn’t be a chat for that To:. Messages are synced with the server or kept as local “archived messages” as referred to above.
then if I delete the last message manually using a MUA, and open DC the complete chat is gone,
Yes, the changes made to messages on the server should be synced with all clients, and if a client has no further locally archived messages, the chat should disappear.
while in the server the rest of the message in the chat remains, this is what do you mean???
No, how should they remain on the server if you just said you deleted them all (the last of all) manually with another MUA?
(Maybe that was our confusion? I wasn’t talking about deleting the latest message, but the last remaining, so that there are no messages left in a chat after deleting it.)
In the name of… can you please read above and check that it says the “latest message” not “latest messages”, 1, one, singular! I am having headache 
that explains all the confusion, now I can agree with you that showing an empty chat isn’t necessary
but what happens if users start a chat (it is empty of curse) and then need to close the app and keep going later without sending any message but with a potential draft???
Ah, ok good that we found it. 
A local draft shouldn’t pose a problem, the chat just stays as long as the draft is kept in the local database or added to the (empty) database query result (depending on the draft implementation).
I think the design of the message states and the auto-delete and -archive features based on them can be considered to be stable, if you don’t find some yet undiscovered flaw, and should be able to cover common and with configuration options even special use-cases.
One simplification for the implementation I just noticed may be that only the (Edit: “synced-new”) “starred” and “archived” states may need to be saved in the database, the synced (Edit: and synced-new see next post) could work based on a filter query (Edit: no specific state).
(https://github.com/deltachat/deltachat-core/issues/164#issuecomment-417868402)
NB @admins: Mabe sort the message handling related messages from this thread into a separate thread, and only leave the answer about currently incompatible versions here, I could not find a way to this.)
Correction to last post: The synced-new state is needed because it’s to be used to exclude messages in global queries (accross all chats) for auto-deleting / -archiving.
The advantage of doing the (auto-)delete and (auto-)archive based on expanding the existing “starred” message state and encountered space limits, is that excluding some states allows deltachat to control the local and server space with good behavior. Archiving if possible, only removing overall oldest, keeping latest in all chats if possible, and all this without requiring any configuration to avoid mailbox full errors. (https://github.com/deltachat/deltachat-core/issues/164#issuecomment-417858627)