Okay, I understand more fully now that the web server can’t initially see the fragment part; it does not show up in any logs because it’s not transmitted. That’s how HTTP works. A script running on the page can transmit it but that would be detectable client-side; even if it only ran every now and then (and served up a static page the rest of the time) that’d be too big of a risk for a project to take on.
With that in mind I can understand more fully how me using words like “leaking” and “spying” is galling and I definitively do want to back pedal from that, and even apologize, at the very least for my tone. (I still think I’ve been getting at least as much grief as I’ve been giving in this thread. Exacerbated by how the situation is [overall] still so so absurd.)
I also hear the secondary point about how on a well-configured Android/iOS device with Delta Chat already installed, there’s not even any requests made to https://i.delta.chat, that addresses with that prefix is intercepted by the OS and sent directly to the app and do not need to call out. Understood. While that is a much smaller point than the fragment argument since in all my testing of this, I accidentally did get sent to the web page in a browser more times than it didn’t, I’ll absolutely grant that it is a non-zero point since I understand that it can work correctly some of the time and that the intent is for it to work correctly all of the time at least on mainstream mobile.
I still just find that this is a “centralization backslide”. Delta Chat used to be super decentralized and now it’s less so since invite links do refer to this server and it is used to a non-zero extent.
But let’s say for the sake of argument that it was still the old-style OPENPGP4FPR links in those QR codes. (And, I’m trying to use such QR codes as a way to mitigate the situation best I can and I generated one such code.)
We still have these issues:
1. It is very hard to bootstrap a conversation if both or even just one of the parties is on chatmail. You need the QR code or a non-trivial, several-lines-long link. I did manage to do it by generating a QR code from the person’s link and loading that QR code as an image in Delta Chat. (I do also understand that pasting the link is also supposed to work and that it’s probably just a temporary bug or something that makes that not work, not an architectural decision.)
Gone are the autocrypt heydays where all you needed was an email address and we’re back to the bad old PGP days when you needed to do out-of-band data exchange in order to start up a convo.
Autocrypt and WKD both solved this in competing, not fully mutually compatible ways, but then Chatmail unsolved it and we’re back to where PGP was when… actually PGP never was this bad. You could always at the very least email a key and hope and pray out of some sort of wishful TOFU thinking that the key was legit. Even more so once we got TLS and DKIM on our precious li’l emails.
︎ Even IRL keysigning parties often involved hand-writing key fingerprints rather than having to have a digital camera at hand. But with chatmail, you need out-of-band digital communication (or the ability to write down a four-lines-long URL and then generate the qr code from that at home) to start your in-band digital communication.
To me this is absurd. I saw some of y’all were talking about perfect being the enemy of good above but that’s kind of a sideways take since it’s less often about perfect vs good here than it is chat vs mail. I’ve seen, again and again, the mail experience become compromised in favor of the chat experience. And you know what? A lot of the times, I’m cool with that. I get that there’s no easy way to do inline quoting. That’s fine. That’s not a showstopper.
Shutting down email entirely the way chatmail sets out to do, that is a problem. It’s a double problem when it leads to a worse chat experience too (e.g. the bootstrapping problem). [Now, I have been able to reply to chatmail users encryptedly from the other email app but only after having gone through the bootstrapping process in Delta.]
I mean, I get that for spam reasons we do not want to let people just start a gajillion anonymous accounts. (And I’ve been pretty free with giving out my GPG public keys to anyone but now this means that yes spammers can use Chatmail if they wanted to spam me. Due to install base that’s a losing proposition right now but it does put a damper on wanting to give out public keys.)
But chatmail accounts being able to receive at least one unencrypted-but-with-an-autocrypt-header message would be half way to a solution to the bootstrap problem. They would give me their email address, I’d email them, and we’d be off to the races. The remaining half would be chatmail-to-chatmail convos. That’s not a problem for me since I’m not on chatmail, but I guess, for them, some sort of specially crafted “approach over SMTP” protocol would work.
I.e. the Delta Chat client apps write and read the email, just how it does when you import the QR code (my client a message that just says “Secure-Join: vc-request-with-auth” and that message isn’t visible on the other end. I’m not sure how it comes that that message manages to become encrypted when the QR code I imported doesn’t inctude a key, just a finger print. How was the key from them even received? I.e. how can the QR codes even work to bootstrap but the email address not work to bootstrap when the QR code doesn’t have the keys either!?).
Also the Date: headers are all messed up…? Delta Chat shows the real dates but my mail server shows them all over the place. I got a chatmail message from someone today with these headers:
To: "hidden-recipients": ;
Subject: [...]
Date: Wed, 14 Jan 2026 00:11:06 +0000
But the Received: headers have the actual date (because my postfix added them). What the heck’s going on there? Anti-fingerprinting? It messes up notmuch.
Okay. Now that I know that I need to look at the Received headers for the real dates, I now see that my Delta Chat first does send an unencrypted “Secure-Join: vc-request” message to them and then I get an encrypted “Secure-Join: vc-contact-confirm” from them. So it is sending an unencrypted “approach” mail in order to bootstrap things. It’s just that it has become impossible for users to do it on their own. (And I guess the idea behind that is that it’s trust-out-of-band as opposed to TOFU.)
2. Delta Chat (and its forks, clones, and wrappers) is still one of the few email apps that only half support PGP. (Yeah, yeah, some entirely don’t, like Hey, and those are all awful. A bar that low shouldn’t be what we aim for.) But what I mean is that I get emails that are in PGP because they’ve gotten my key (from an .asc file, from a HPKS server, from my WKD setup [which is how come all mails from all Proton users ever get encrypted to me; I don’t use Proton but they get my keys from WKD], or from just scraping the key out of the Autocrypt headers manually) and they write to me encryptedly and I can’t reply from Delta Chat encryptedly. I finally thanks to VCard can start a new chat with them (when I tried it a few months back it did not work and instead an unencrypted message got sent but maybe it does work now) but I can’t reply. I can reply from another mail app and that’s what I usually do actually but I then still can’t reply from Delta Chat.
Normally when I want to start a new convo with someone who is not on Delta Chat but they don’t use e2ee, what I do is that I start it from another mail app and then keep that convo going from Delta Chat. That makes sure that on my end I still see it as a chat w/ their contact name, but the topic is set. I can start messages with topics from Delta Chat but then the chat itself is sorted under that topic and not under that person. Not the end of the world but enough to nudge me into more often just go ahead and start it from the other app. At least I can reply from Delta Chat but when it’s encrypted, I can’t.
