(traffic saving) minimize requirement to up/download a message body

[testbird]

As long as the entire text of a short chat message fits into the subject, there is no need to upload the text a second time in the message body, and no need for the receiver to download the entire message body.

To skip downloading the body, "subject only" messeges would need to be marked in a distinguishable way.
Possibly, by ending the subject with a special character and using a subject-only optimized format like
-[] Hi, short text. |, or -[groupname] some text. | for group messages, so that classic MUA users can also see the character and know that there is no text to look for in the body.

(The example used subject formatting ideas from #136 (comment) and #128 (comment))

Not having to download the message body for regular text messages, will allow to only make (delayed) downloads of the message body, if it contains attachments. -> #436

[r10s]

how can this work together with encryption?

[testbird]

Hm, right only Autocrypt: is a header. And I guess the encrypted subject feature uses information in the body to let compatible clients override the subject, right?

But traffic could still be reduced a lot for encrypted messages by breaking PGP compatibility?:

Maybe a Sparse Email-chat protocol variant, that is only used among contacts known to use an Email-chat compliant messenger:

• skipping to re-send the same key to the same known contacts (only re-send after changes or explicit request)
• moving the encrypted part into a header (subject plus possibly some longer but still rather short remaining text message?)
• moving all optional and meta-data parts (e.g. new group member keys), if they have to be sent, from the headers (e.g. Autocrypt:) into the body (as attachments that may only need to be downloaded later on wifi, or for sending a reply, if a key is unknown or not working)

[r10s]

traffic saving is important, in fact, we've saved 33% sending-traffic by bcc-self #370 and the message-id-check in #408 will save another 33% on sending.
also the single-folder-approach saves lots of IMAP commands as copy/move is now longer needed.

of course other approaches are also useful, but they come at much higher costs of maintainability and also compatibility ("moving the encrypted part into a header").

in general, we should start such discussions and feature requests not in the issue tracker but eg. in the forum, therefore, this is closed for now.