Hey @Tao thanks for asking these questions!
It would be cool to have a Delta Chat security whitepaper … hum … Here are some drafts for parts of chapters from my side, please bear with me if it’s not a full discussion …
Security perspectives in messaging
“security” is a large and emotionally charged topic with many perspectives and approaches. Already with at-risk users we remind ourselves that security is about social user outcomes – do people land in jail, can authorities identify a whole social graph if getting access to a single phone, etc.? This real-world social security can not be obtained magically from a clever algorithm alone. Always, there are threat models and trust choices involved. In many realities, answers to “is using this app secure for you” are highly dependent on your particular situations.
Protection against active attacks
Delta Chat implements “verified groups” protecting against active network attacks, say a compromised messaging provider. In 2017/2018 some of us researched in collaboration with George Danezis (UCL) and Carmela Troncoso and Wouter Lueks (both EPFL) about this topic. Delta Chat implements two of the three protocols as defined from this research setting:
https://countermitm.readthedocs.io/en/latest/new.html
This chapter (of a larger paper) also contains more rationale and security perspective/measurement perspectives.
Implementation security
The core engine of Delta Chat is coded fully in the Rust language, widely hailed for its robustness, efficiency and safety. Delta Chat’s e2e-crypto engine is rPGP which was independently security-reviewed. A new security review, sponsered by the OpenTechFund, is currently starting covering smtp/imap/tls/key handling. The involved codes are liberally open-source licensed and are used in non-Delta Chat projects.
Metadata security
It is hard to protect metadata of “who messages whom” against messaging servers (e-mail, signal, whatsapp, threema, …) and nobody has really solved that, practically. E-mail headers like “To, CC” are TLS-encrypted for most common providers. So the e-mail server operator sees these headers and is instructed by the client to relay a message to recipients. As long as the connection is TLS-encrypted there is no real metadata leakage here. Note that Signal’s sealed sender and recent “encrypted group storage” schemes do not solve the metadata problem: Simple traffic analysis (all messages are passing through a central server!) recovers all the information no matter how much some core-server code tries to hide information from itself. To cut this discussion short: the choice of your messaging providers matters. It is part of your trust and protection model. Luckily, in the e-mail space there is a wider variety of providers to choose from, some principle-based, some money-based or just maintained for the fun of it and your friends. With Delta Chat you have a lot of choices for your trust model, today.
Weakening metadata through “burner accounts”
With May 2020 Delta Chat releases, “Burner Account” support is enabled by default. It enables users to use temporary e-mail accounts which are server-side deleted after a day, week or month. If you form a group of burner-accounts and safely communicate with each other, you can be sure that all traces are gone after a while (except the ones where you take action to share them with another app). Also if a device is taken it reveals a number of random addresses. This is very weak identification because even the messaging provider has no identifying, let alone passport-information about its accounts. The UX flow is that you can share “burner account” QR codes and let friends/folks create accounts based on scanning it. So the provider might know who got the “creation” token but it does not know who got introduced through it.
Weakening metadata through auto-deletion modes
With May 2020 DC releases there are advanced options to “auto-delete” messages on your device or on the e-mail server. This is something you can enable for yourself, it does not affect other chat participants You can be sure that messages are gone after a time without having to hit “emergency buttons” in an already physically threatening situation. The design of these features stems from conversations and analysis of real-world needs and situations. There are rounds of user-testing behind the scenes which we don’t publish in detail to protect participants. DC’s auto-deletion modes operate on the whole account data and are particularly interesting for “mission” phones.
Support for traditional burner-messages, a special form of auto-deletion, will probably land in DC by july 2020 … they protect parts of a chat-group conversation and allow to have “temporary-chats” within a chat without affecting any other chat.
Some notes on perfect forward security (PFS)
Many crypto enthusiasts see “perfect forward security” as the gold standard for end-to-end encryption. Some call it “deletable encryption” as it is about a device forgetting how to decrypt previous network traffic. If someone takes your phone and has previously recorded all your messaging-traffic they can now decrypt the recorded network traffic. “Forward secrecy” prevents that. The “perfect” is just marketing, anyway, and can not be true for any sufficiently complex IT effort 
But even with deletable encryption what if someone takes your phone, what else can they glean? With many PFS-supporting messengers the device-taker gains your social graph through the phone numbers which are tied to passports identification. And they potentially gain all the chat communication that is still on the device – because despite the hero movies … real-life mission co-ordinators in most places recommend to unlock devices if threatened. So “encrypting on disc”, for example, only goes so far here.
Also, often another real-life issue is neglected with PFS: unstable multi-device experiences. If you have multiple devices and mixed offline/online behaviour then PFS-messengers often struggle to provide a stable user experience – note that whatsapp desktop avoids the problem by proxying through the phone always.
Rest assured, there are repeating discussions about PFS and Delta Chat but compared to many other interesting real-life features it’s not top of the prio list with most active DC coders currently.