Hello all,
I have started this discussion in the forum[1], but apparently this mailing list is more appropriate. So, below is my original post, followed by Holger's reply with my answers to that inline.
> > As a pre-requisite for "Make DC a replacement for MUAs?"[2] and hybrid
> > chat/mail clients in general, the DeltaChat Core library should support
> > sending and receiving arbitrary MIME mails.
> >
> > I see several ways to add the API to DCC, in order from least to most
> > abstraction:
> >
> > 1. Send/receive raw bytes. Not stored in DCC database.
> > Folders are simply strings representing the full path, i.e. starting
> > with “INBOX/”.
> > - pro: least effort for DCC
> > - con: most effort for DCC clients, duplicate DCC functionality
> > - con: need to expose more internals to access e2ee keys, etc.
> > 2. New class allowing direct access to libetpan. Optionally stored in DCC
> > database.
> > Folders have their own class.
> > - pro: reduced effort to implement now
> > - con: more effort for clients on migration away from libetpan
> > 3. New class with all necessary methods, abstracting libetpan. Optionally
> > stored in DCC database.
> > Folders have their own class.
> > - pro: reduced efforts for clients
> > - con: more effort to implement now
> > - con: more effort for DCC to migrate away from libetpan
> > 4. Extend the existing message class (dc_msg_t). Stored in DCC database.
> > Folders can use either their own class or extend the existing chat
> > class (dc_chat_t).
> > - con: big change to existing APIs, code and DB
> > - con: gets in the way / increases the learning curve for pure chat
> > clients
> >
> > Just counting the pros and cons, options 2 seems the best so far. But
> > before we start thinking about implementation detail, what are your
> > thoughts and ideas about it? Maybe some completely different
> > implementation ideas?
>
> Not sure this is a good forum for discussing what are rather implementation APIs and architecture questions. I’d rather suggest the mailing list. Let me still say a few things :)
>
> I suggest to think more about the needed API and not too much about how it’s implemented. There is a lot of tentative/incremental flux that could happen in the next months, regarding moving code from C to Rust etc. And let’s maybe first talk about sending/receiving semi-arbitrary mime-mails, not about new/added IMAP handling. Which C-API would be needed and how would it work/be specified?
There might be a misunderstanding. My list does not contain any implementation details. Quite the opposite: before taking the first incremental step, we should first decide on the direction in which we want to go. And that's where the 4 approaches come in. Except for maybe approaches 3 and 4, the different approaches are not incremental extensions of each other. So we will probably need to decide which way to go, and discuss enough details to make the decision.
For example, the sending half of approach 1 is a single trivial function, because most of the work for that was part of the "early MIME generation" issue. It already technically accomplishes the goal of sending arbitrary MIME mails, except that accomplishing the goal this way is almost useless because it forces clients to do everything on their own, from MIME generation to crypto (see also the cons in the list).
"Semi-arbitrary mime-mails" sounds to me like approach 4: adding functionality to the Message class to send more and more types of mails until it's flexible enough to send any MIME mail. So yes, that's one approach which would make sense. But before we start discussing the implementation, I would like to discuss the pros and cons relative to the other approaches. And maybe somebody can come up with yet another completely different approach.
> How does Autocrypt-handling happen including encryption and decryption? If mime-mails are not tied to a chat at sending time, but to a caller-specified list of recipients, then how are they accessed on the receiving side?
I'm not sure I understand the question. Mails are accessed using a mail client, aka MUA (mail user agent). Why should anything be different if the sender's MUA is using DCC instead of e.g. MailCore 2?
Regarding Autocrypt, that should not be any different than people accessing their Autocrypt-encrypted mails on multiple devices/clients. The beauty of chatting over email is that for the purpose of most standards (here: Autocrypt), DeltaChat is just another MUA.
Regards,
Viktor Pracht
[1] https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients…
[2] https://support.delta.chat/t/discussion-make-dc-a-replacement-for-muas/253
--
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe
AG Siegen, HRB 8718
Geschäftsführer: Frank Hoberg
