30 Mar
2019
30 Mar
'19
3:59 p.m.
Hi Victor,
returning to your top-level post, in light of our discussion.
I suggest to focus first on the issue of sending/receiving "non-dc"
emails. I am putting it in quotes because DC also sometimes
groks/processes non-DC mails that are put to chats, persisted and some
of them are also moved to the DeltaChat folder etc. You can not
conclusively determine from just seeing a single mime-message
that it is a non-dc mail.
Had some discussions with Bjoern about what's involved from DCC's side
for growing send/receive arbitrary mime-messages. We arrived
at this suggestion for possible next steps:
- implement a C-API in deltachat.h
that sends a mime-message (cleartext) to a list
of recipients. DCC only persists it until the message
is sent out and then forgets about it.
DCC performs Autocrypt-encryption for the outgoing mail
(adding headers, encrypting ...).
- implement a C-api in deltachat.h that allows to register
a callback which receives incoming decrypted e-mails
that DCC does not consider to be a chat message.
(note: this relates to the "show_emails" option, see
https://delta.chat/en/2019-03-14-oauth2release#streamlined-contact-requests)
The Message ID and some sync-metadata is persisted with DCC
but not the message body itself.
- note: we are to move towards not fetching imap messages that
Delta Chat is not interested in. So likely we'll also
need a callback that answers the question
"Do you want this message downloaded? yes/no".
This callback would receive some early headers (Message-ID,
In-Reply-To, ...) to make its boolean determination.
- Note also that in this API design, all Autocrypt processing and
state for all contacts would be managed by DCC -- the UX would
need to get indications (a header) if a mail was encrypted.
As you know, the devil is in the details but we are willing
to help along issues that you encounter :)
holger
On Thu, Mar 28, 2019 at 13:19 +0100, Viktor Pracht wrote:
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.
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? 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
_______________________________________________
delta mailing list -- delta(a)codespeak.net
To unsubscribe send an email to delta-leave(a)codespeak.net