I wrote a #DeltaChat blog post for technical users who are skeptical about how it works
Everything You Think You Know About DeltaChat Is Wrong
blog.feld.me/posts/2025/03/del…
Everything You Think You Know About DeltaChat Is Wrong – Makefile.feld
I am smitten with DeltaChat... DeltaChat has been making massive strides lately and I think you should consider using it as your full time secure messenger.blog.feld.me
Peter Vágner reshared this.
treefit
in reply to feld • • •Do you already know
support.delta.chat/t/list-of-a… ?
@deltatouch (ubuntu touch client) would be worth mentioning, especially with the blogpost from @lk108 : delta.chat/en/2023-07-02-delta…
Arcane chat is technically a soft-fork of the android client with special patches and extra features by @adbenitez
Delta Chat: Introducing DeltaTouch, a new community created client for Ubuntu Touch
delta.chatfeld
in reply to treefit • • •treefit
in reply to feld • • •gvs
in reply to feld • • •feld
in reply to gvs • • •@gvs Simplex has two options for routing messages: the centralized SMP servers, and a 2-hop onion/Tor-like private message routing using forwarding nodes. Both of these are easily blocked if you want to shutdown access to Simplex for users.
XMPP: easy to block
Anything using Nostr: easy to block
Shutting down all email services in your jurisdiction: much harder to accomplish
👺кину奇诺［流浪者］👹
in reply to feld • • •gvs
in reply to 👺кину奇诺［流浪者］👹 • • •feld
in reply to gvs • • •@gvs @adiz "known service providers" -- every email server is a DeltaChat service provider.
Do you think Russia is going to shutdown Yandex to stop people from using DeltaChat on it and cripple their own country's ability to use the internet?
The most they can do is demand all email servers in their jurisdiction block all encrypted emails, period, which requires custom technical solutions for each provider and will have severe consequences as well. Encrypted emails are not as uncommon as people think.
If I work in the government and want to be a whistleblower I could literally use my government email account with DeltaChat. Maybe they'll eventually detect that I'm using it, but they'll never be able to decrypt those messages.
gvs
in reply to feld • • •They can be, but they keep and leak metadata. In some places, e-mail logs have to be stored for 2 years. So using your government e-mail account to use deltachat still reveals who you are talking too.
Neither does that argument negate that SimpleX now defaults to https traffic, which you think would be more likely to be wholesale banned then mail?
feld
in reply to gvs • • •@gvs @adiz What metadata are you concerned about?
Are you aware that you can encrypt nearly all the MIME headers? To, From, Date, Subject, etc?
👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz @gvs Russia or China over IRC is not interesting.
What E2EE are they using successfully?
Matrix and XMPP?
Are they using it directly or are they being forced to use a VPN/Tor to try to connect?
👺кину奇诺［流浪者］👹
in reply to feld • • •>Are they using it directly or are they being forced to use a VPN/Tor to try to connect?
Directly. Quite straightforward. We've had zero issues. @gvs
feld
in reply to 👺кину奇诺［流浪者］👹 • • •gvs
in reply to feld • • •@adiz
feld
in reply to gvs • • •@gvs @adiz
MAIL FROM can always be noreply@
RCPT TO is of no consequence as the DeltaChat accounts which are on Chatmail servers are random/anonymous, and they'll even be ephemeral soon.
gvs
in reply to feld • • •With a valid domain, with an IP logged unless on VPN/tor which works for SimpleX as well.
You stated that any SMTP can be used for deltachat, so non chatmail servers have to be taken into account as well
@adiz
feld
in reply to gvs • • •@gvs
> You stated that any SMTP can be used for deltachat, so non chatmail servers have to be taken into account as well
Yes that's one of its strengths. They can't really block all possible methods of exfiltrating data securely.
Let's pretend they do successfully figure out how to get every email service in the country to block PGP mail? Delta controls the clients, they can just work around it. Unlikely but possible scenario: just generate random PNGs as attachments to innoculous mails and append the PGP data to the end of the PNG...
What next, they block all email attachments? LOL
👺кину奇诺［流浪者］👹
in reply to gvs • • •>You stated that any SMTP can be used for deltachat, so non chatmail servers have to be taken into account as well
And this continues to be the cruc of my argument. Everyone shilling DeltaChat does so with the disingenuous argument that "you can just use your existing email!"---which isn't really honest. There are major providers where it doesn't work. Assuming that does work, the recommended "best practice" is to have a separate email address entirely to use with DeltaChat vs. your primary, normal email address. And then, thereafter, to address all the performance issues associated with [
*squints*]……trying to use email as an instant messenger platform……, and to utilize all the marketed features supposedly available immediately out of the box, the recommendations and solutions are to spin up, or have an account on, a specialized email stack.By the time you do all of this one could otherwise be using an instant messaging protocol made for instant messaging.
Ultimately, the "sales pitch" is, dare I say, intentionally dishonest. @feld
feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz @gvs best practice is to use a separate address, preferably a Chatmail server if possible.
But if you can't because you exist in an environment with extreme limitations, use your normal email.
That's it. That's the whole sales pitch. You lose some anonymity and only a little extra metadata is exposed, but still nobody can MITM your messages. Your conversations are still secure, plus you gain a TON of functionality.
Oh, now you want to do realtime collaborative editing of a document? Add the WebXDC app to your chat, and boom E2EE P2P connection established and realtime group text editing activated between all members. No need to use a third party service that may not even be accessible to some people in the chat.
👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz the default deployment is with a tool called "cmdeploy" that is Ansible-ish python which SSHes to the server and does everything, installs the configs from templates, does Acme HTTP-01, etc.
I do not like this because I don't want HTTP-01, I want DNS-01 especially as my original tests were behind NAT and the tooling has some test for connectivity built in and wasn't detecting the public IP properly so that annoyed me.
Updating is as simple as a git pull on the repo and running the same deploy command again.
HOWEVER, as I said I do not like this method so I maintain a separate implementation using a Chef cookbook that does not rely on a Chef server.
I have a video showing the entire deploy process to a fresh Debian VM. It's very fast and simple to do.
Video (only 2 mins long):
video.infosec.exchange/w/o9byi…
My cookbook repo:
github.com/feld/chatmail-cookb…
The official chatmail deploy tool:
github.com/chatmail/relay
GitHub - chatmail/relay: chatmail service deployment scripts and docs
GitHub👺кину奇诺［流浪者］👹
in reply to feld • • •I'll bookmark this. I just read through the GitHub page. A lot more stuff than I figured ahead of time.
By comparison, on Debian, to get Prosody (XMPP) working you:
sudo apt update sudo apt install prosody -y>setup DNS records >open the ports >modify the Prosody config >pull certificates >import certificates
sudo prosodyctl check configIf everything looks good:
sudo systemctl enable prosody.service && sudo systemctl restart prosody.serviceDone! You're online. Start issuing/registering accounts and to chat with people! It's that easy. Extremely straightforward. Prosody has an update?
apttakes care of that withsudo apt update && sudo apt upgrade -y, just as it does with every other ordinary binary package. I have some transports and bridges setup that ship as Docker containers. Equally as straightforward and painless to get setup and running.When I upgrade from Debian 12 to Debian 13, guess what? Everything is just going to work. If I have to move my service to a new machine I just copy the Prosody directory contents over and import the PostgreSQL database. So simple. So straightforward. So easy to manage. I like that.
feld
in reply to 👺кину奇诺［流浪者］👹 • • •👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz the good news is that by then it doesn't matter, there won't be much of a purpose of self-hosting because your client will automatically learn of all the available Chatmail servers and self-register ephemeral email accounts and jump between them completely transparent to the user.
At that point deploying Chatmail relays is just strengthening the overall network
👺кину奇诺［流浪者］👹
in reply to feld • • •>At that point deploying Chatmail relays is just strengthening the overall network
If it becomes that easy (i.e., as easy as setting up an XMPP service, e.g.: Prosody) then I'd deploy and maintain a ChatMail server solely to strengthen the network even if I don't utilize the service itself.
feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz tbh I found Prodody to be a pain in the ass to setup, I never even got attachments/HTTP working right after hours
MongooseIM/eJabberd was easier, but it still sucks IMO
feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz @gvs
> Are all the features advertised functional out of the box on deployment of a ChatMail server?
Majority of the features are in the client. The one thing you get with Chatmail is functional (and secure) push notifications on iOS and Android devices via APNS/FCM. Desktop doesn't need them as IMAP PUSH works there. *Some* Android devices can use IMAP PUSH, but depending on how aggressive the vendor changed Android to kill background processes etc.
> And, is it easy to manage/maintain a ChatMail server
Run package updates, maybe deploy the latest Chatmail changes once a month or so? There are some middleware services in Python that will be rewritten to Rust eventually. A couple of Dovecot/Postfix config tweaks have happened in the last few months as well. It's fairly low maintenance. I have apt Unattended Upgrades enabled on my servers so they take care of themselves including rebooting as necessary.
feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz
> By the time you do all of this one could otherwise be using an instant messaging protocol made for instant messaging.
Except when that protocol is blocked, but email still works.
If you're happy living in your little bubble where nobody is censoring the protocols you're using, feel free to keep doing whatever you're doing. But your suggested protocols have failed the people the DeltaChat team is helping.
QED
feld
in reply to gvs • • •@gvs @adiz Turns out Simplex using port 443 doesn't make it "difficult to block", because Russia has done it. Not just blocking the known public servers. They have DPI working that detects and blocks Simplex
github.com/simplex-chat/simple…
[Bug]: ALL default server banned in Russia (By Russia central censorship) · Issue #4933 · simplex-chat/simplex-chat
GitHubgvs
in reply to feld • • •@adiz
feld
in reply to gvs • • •@gvs you keep saying SimpleX is a bigger target with no evidence. Did SimpleX get sued by Russia? DeltaChat did, the court case just concluded today:
merlinux.eu/press/2025-05-14-r…
👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz have you actually tried it yet, though? It cost you nothing but a minute of your time. No need to provide any identifying information to make an account, and the account will be auto-deleted if it's idle for too long.
click the link in my bio to message me. I'll show you some cool stuff that no other messenger has.
👺кину奇诺［流浪者］👹
in reply to feld • • •>have you actually tried it yet, though
Yes, I have. And, it worked. But, it sucked. And I don't want to go through the lengths to make it not suck (like a dedicated address for it + a Chatmail deployment) when I already run an XMPP service which does everything DeltaChat does but better + more.
pwm
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz this statement is technically inaccurate. Xmpp and Delta chat have the same federated model, so architecturally they are equivalent.
However, a key pain point for me for xmpp is that media attachment is out of band with regards to the protocol, occurring over http. It has all the same privacy concerns that media uploaded to the fediverse does. As media sent over Delta chat occurs in band (email attachment) and is end-to-end encrypted, it is strictly better from a privacy perspective.
However, from a normalfag perspective, interface remains the chief detriment of using xmpp over other solutions. The xmpp ecosystem has been waiting for "someone else" to make a good, functional, attractive client forever. It is not a good argument to say that all it needs is a client that has not been developed in 20 plus years. One client that is a functional clone of something that normalfags are used to like telegram or Whatsapp, is an enormous selling point for people not concerned with, or unable to understand arguments for privacy.
I like xmpp. I like Delta chat. But there will be no one true instant messaging solution until a plurality of users exist that brings it to dominate the market. Currently, those are all proprietary networks tied to services like Facebook or well, mostly Facebook I guess.
feld
in reply to pwm • • •@pwm @adiz
> The xmpp ecosystem has been waiting for "someone else" to make a good, functional, attractive client forever.
they did. It's called iMessage and Whatsapp 😂
The open source community is never going to fill this gap. I'd like to be proven wrong, but I've been waiting for 20 years now...
wuhan.bat™
in reply to feld • • •@pwm @adiz
waiting just as long. hasn't happened. the desktop ui for deltachat feels wonky and i'm slowly moving away from handset although arcanechat for 'droid is pretty okay.
what i like about deltachat is i already have a mail system which i use for.. mail. i can still keep encrypted mail separate from delta(openpgp) encrypted messages and it just works. i've handed deltachat to people in this thread, elsewhere on fedi, at the local coffee haus, and to the chick i'm dating who's not technical. so far so good.
i was always an enthusiast of xmpp, but damned if i can't get anyone to talk on it regularly so i use it for a transport bridge for fun, nothing serious.
feld
in reply to wuhan.bat™ • • •wuhan.bat™
in reply to feld • • •wuhan.bat™
in reply to wuhan.bat™ • • •GitHub - dignifiedquire/dreamer: Experimental deltachat client
GitHubfeld
in reply to wuhan.bat™ • • •@jae @pwm @adiz the tauri branch can be found here. I've never tested it, know nothing about it right now really
github.com/deltachat/deltachat…
GitHub - deltachat/deltachat-desktop at simon/tauri-flatpak
GitHubwuhan.bat™
in reply to feld • • •feld
in reply to wuhan.bat™ • • •👺кину奇诺［流浪者］👹
in reply to pwm • • •Everyone talks about XMPP and bad clients, but I just don't have this experience. There are multiple clients available and they all work well for me. 🤷
It's kinda a moot point when Delta Chat has just the one client.
I can concede media being facilitated by HTTP in XMPP vs. within the protocol itself. Still more performant and capable than trying to do file transfer over SMTP. @feld
feld
in reply to 👺кину奇诺［流浪者］👹 • • •Just one client?
DeltaTouch for Ubuntu Touch
ArcaneChat for Android
ArcaneChat TUI
DeltaChat on KaiOS (feature / flip phone)
kdeltachat for the KDE folks (stale at the moment though)
👺кину奇诺［流浪者］👹
in reply to feld • • •Ah, I've only seen the DeltaChat app and I had sought out other alternate clients at the time as well.
>Ubuntu Touch
🤣🤣🤣
@pwm
feld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz @pwm it's pretty easy for you to build a client on any platform if you want. You get to skip all the annoying parts of reinventing the SMTP/IMAP/PGP and Iroh functionality. In fact it would be stupid to reinvent it because the core has been audited multiple times.
So you just wrap the core DeltaChat JSON-RPC server (written in Rust) and treat it like an API service, and you're done.
👺кину奇诺［流浪者］👹
in reply to feld • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •just because there are client libraries for these protocols in another language don't mean they're good or safe
edit: I should really emphasize that the only safe PGP implementation is rPGP in Rust, and it has some required functionality you will not find in GPG, Sequioa, NetPGP, etc that is being leveraged for additional privacy. It would be a security downgrade to not use it.
edit2: anonymous recipient is an example, which makes it impossible for an adversary to analyze the PGP data and know who it was intended for because there is no exposed public key ID. The only way to know who the message was for is to successfully decrypt it with the recipient's key! github.com/rpgp/rpgp/issues/50…
Use anonymous recipient for generated packets · Issue #507 · rpgp/rpgp
GitHubfeld
in reply to 👺кину奇诺［流浪者］👹 • • •@adiz @pwm
> Everyone talks about XMPP and bad clients, but I just don't have this experience.
If you lock yourself in a box where only Android and Linux desktops exist, sure, there's an *okay* XMPP experience available. Conversations on Android is like the only good client available.
But the experience is still terrible on Windows, Mac, and iPhones
m0xEE
in reply to pwm • • •@pwm@darkdork.dev @adiz@mtl.jinxian.casa
Does it not send some sort of key over XMPP when you are sending a file to an OMEMO chat, making the data transmitted over HTTP useless without it? I never looked into it myself, but attachments sent without OMEMO look like normal links you can access from a web browser, those sent with OMEMO encryption have aesgcm:// schema.
👺кину奇诺［流浪者］👹
in reply to m0xEE • • •aesgcm://. @pwm @feldm0xEE
in reply to 👺кину奇诺［流浪者］👹 • • •I'm just not that knowledgeable about XMPP and not sure what that means 🤪
Does this mean that the URL is encrypted or that the file has to be downloaded and then decrypted with a key sent over XMPP?
@pwm@darkdork.dev @feld@friedcheese.us
m0xEE
in reply to m0xEE • • •Yeah, the key seems to be sent over XMPP separately, making HTTP traffic useless even if intercepted. Good enough!
Encryption for stateless file sharing
Marvin Wißfeldfeld
in reply to m0xEE • • •@m0xEE @adiz @pwm that's similar to how Signal does it as well, and I think iMessage(?). Probably Whatsapp for groups too. Makes most sense anyway.
Fun part is that if the web hosting is not owned by the chat app team it has a potential for metadata leaks. Signal groups use CloudFlare, so you can just ask CloudFlare for the logs of who downloaded a file from their CDN and you get the IPs of all members of a Signal group. So you better hope that nobody has infiltrated your top secret anonymous anarchist chat group and shared a file because there's a way to unmask the members
👺кину奇诺［流浪者］👹
in reply to feld • • •There are ways to unmask IPs, anyway. If the concern is about deanonymization or infiltration or loss of encryption then honestly the most likely threat in any system is a mole, not people pulling server logs from service providers or man-in-the-middle attacks, etc.. And, there is virtually no way to program or digitally defend yourself out of infiltration if you're running a group or organization. 🤷
Luckily, we run our own websites and XMPP server, etc.. @pwm @m0xEE
👺кину奇诺［流浪者］👹
in reply to 👺кину奇诺［流浪者］👹 • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •Phantasm
in reply to 👺кину奇诺［流浪者］👹 • • •👺кину奇诺［流浪者］👹
in reply to Phantasm • • •feld
in reply to 👺кину奇诺［流浪者］👹 • • •feld
Unknown parent • • •@m @adiz @gvs Outlook requires OAuth now. Not even application-specific passwords like Google and others support.
The DeltaChat client had OAuth support, but removed it because it was not worth chasing the vendor implementation bugs constantly.