By default all messages are moves all chat messages to DeltaChat folder, so it will not clutter your Inbox. It does not happen immediately because Delta Chat has to detect incoming message first and your Thunderbird has a chance to notify you about incoming message before Delta Chat moves the message. I haven’t tried it, but looks like Thunderbird allows to setup a filter matching all messages with a header Chat-Version: 1.0 (that is a header Delta Chat sets on all messages) and action “Ignore thread”, you may try to do it to avoid notifications.
Problems sometimes happen with large groups, when you send each message to 20+ people. I have several chats with ~15 members and some Gmail users, they don’t seem to have much problems with Delta Chat.
Haven’t ever heard about something like this happening with Delta Chat. Delta Chat uses the same OAuth 2.0 procedure as Thunderbird for Gmail authentication, is detected as Delta Chat app etc.
There is a list at https://providers.delta.chat/ but it is not a recommendation list. Delta Chat does not have any official list of recommended email providers or comparison of them. Riseup seems to work good but requires an invitation. Disroot support is aware of Delta Chat and can raise some limits if needed but may block messages by default. There are some users with Posteo, Mailo accounts. The best provider is usually something hosted by you, your friends, maybe your workplace, where you can ask the provider directly to remove the limits if they get in the way. Try your local community-run providers first.
The most common problem so far is messages getting into the Spam folder. This usually happens with large email servers run by Google/Yandex/Microsoft etc. Nightly versions of Delta Chat for Android already do and upcoming releases for all platforms will periodically fetch the messages from the Spam folder. There are also plans to watch this folder just like your Inbox if it got Delta Chat messages recently, so eventually this problem will be solved.
The most controversial difference is the lack of forward secrecy. This allows easier multi-device setup and simpler key management at the cost of some post-compromise security. It is a tradeoff, and I don’t yet understand what happens if Signal servers or XMPP PubSub servers storing OMEMO keys start to forge new devices that are only shown to other users but not you, and what happens from the point of practical security in this case, it may be worse or better than Autocrypt/OpenPGP model depending on how user acts in the situation of attack. One way to introduce forward secrety without complex key management is the model of “secret chats” (Telegram) or Off-The-Record chats. For further discussion see Off-the-Record chats and all the links there.
From the encryption point of view, messages are encrypted with Ed25519 + AES by default, which is more or less the same algorithms as used by any reasonably secure messenger, there is hardly any practical difference.
How does anonymity compare between Signal and Delta Chat in terms of governments being able to discover relationships between users that are messaging each other?
Currently all the To and From headers are only transport-encrypted. Your provider can monitor who you send the messages to and from which addresses you receive them. Signal server technically can do the same, even with the sealed sender feature, but it likely doesn’t do it, compared to Gmail which almost certainly does. Smaller and self-hosted providers likely don’t store this metadata and you can setup Delta Chat to quickly delete old messages from the server.
Why the word “could”? And does anything change in the above paragraph in the case of 1:1 non-group chats?
The idea is to hide the To addresses in the encrypted part, and actually put all receipients in Bcc, so To contains undisclosed-recipients:; group. This way if you send a message from your example.org to example.net and example.com users, example.com server will not be aware of example.net existence at all. “Could” because it is not currently implemented, it will likely be implemented after the next release as part of “protected groups” effort: protect chats 🛡️ · GitHub With 1:1 chats it’s hard to do anything about metadata without complicated Privacy Enhancing Technologies such as PIR (Private Information Retrieval) or Mix networks such as Katzenpost. I am not aware of non-research messengers capable of this level of metadata protection.
Delta Chat team has contacts of many groups successfully onboarding non-technical users, it’s definitely possible.
Yes, currently the implementation just sends the link. There is also experimental more integrated support for basicWebRTC server in desktop, currently it’s disabled in 1.15 series, but there is a working prototype of accepting the calls from within desktop app. As for truly integrated 1:1 WebRTC calls, it should be technically possible. I did some experiments at ~link2xt/webrtc-clipboard-call - WebRTC call-via-clipboard application using React and TypeScript - sourcehut git, establishing a WebRTC call requires exchanging only two emails, but you need a separate external TURN server to bypass NATs, which email providers do not provide. Overall, current WebRTC implementation is not yet as good as it can be. The best thing we can do short-term is providing an integrated Docker setup (here is a setup I use for local testing on Raspberry Pi: GitHub - deltachat/docker-mailadm: Local testing environment for Delta Chat based on mailadm (https://github.com/deltachat/mailadm)) for self-hosted small email providers, with a TURN server and basicWebRTC installed and preconfigured for new accounts. NAT bypass is the main problem of decentralized setups and one of the reasons Matrix integrates Jitsi Meet with a whole web server behind it as a widget.