After three intense months of work from more than a dozen contributors, #deltachat 2.48 releases are rolling. Maybe the most feature-packed releases ever?

- "zero metadata" messaging

- native Audio/Video calls on Android and iOS, as well as UbuntuTouch

- Group and Channel descriptions

- A new background audio player

- Revamped Download-on-Demand

and, last but not least, the long-awaited next-generation of messaging resiliency through "multi-path" routing ....

delta.chat/en/2026-03-31-zero

reshared this

in reply to zivi
@kbruen part of me feels like delta is so commited to staying “the email messenger” because of some sunk cost fallacy. dont get me wrong, it works, but theres so much extra working around flaws that wouldntve existed with a proper IM protocol that has to be done
in reply to zivi
No. Using email as a backbone is one of the big selling points. Otherwise, there's dozens of apps out there. Using the email infrastructure brings advantages no other protocol can bring, such as censorship resistance.
That's not the issue here. For example, the blog post mentions multiple relays, but only one seems to be used for sending, which feels like that meme of a miner giving up right before reaching diamonds. If Delta Chat would send each message from a random relay, the problem would pretty much be solved. Alas, I have a love-hate relationship with Delta Chat, and I often find the choices of the devs puzzling.
in reply to Kenny
@kbruen @zaire we are proceeding step-wise and aim to provide stable user experiences across versions. In the last section of the blog post delta.chat/en/2026-03-31-zero#… we already sketch a path forward that includes switching sending relays. But we need to move and change an implementation, and cant just work on the idea level alone.
in reply to Delta Chat
I've read the blog post. The last section doesn't say that you plan to have sending through random relays. Besides words that make the blog post feel like corporate slop ("research and iterative streamlining of multi-path operations"), what I gather from that section is that you plan to replace manually adding relays with automatically adding a relay after discovering it. If there will still be a primary relay where all the messages come out of, that doesn't address what I said, and it still provides metadata that users can be identified by.
in reply to Delta Chat

@kbruen @zaire

I like the step-by-step approach.

As soon as address-randomization is reached, the next complaint is that only the same n-adresses are in the pool. So the next request is to let DC create its own addresses. Get me right: This would be an awesome feature, I just use this to demonstrate that this is the nature of iterative approaches and ongoing improvements.

in reply to dexternemrod
I'm not complaining about iterative development, I'm complaining about the blog post being titled "Zero metadata, ...", the Fedi post having the bullet point "- "zero metadata" messaging", the reply saying "this release goes all the way".
Those are all incorrect, and the blog post text saying "close to zero metadata" sours the great achievement by introducing the shady vibe that asterisks and tiny texts in advertising gives.
The achievement of having removed so much metadata is great on its own, and I think misrepresenting it cheapens it and leaves a bad taste.
This entry was edited (Wednesday, April 1, 2026, 10:08 AM)
in reply to Kenny
@kbruen @dexternemrod @zaire in hindsight, maybe "zero metadata messages" would have been the more proper framing. Apart from the maybe too catchy tag the text goes into quite some details what "zero metadata" messages are about. We highlight in the "Telegram" section that while we are discussing about nitty gritty details of cryptographic terminology, they lure >1 billion users into thinking Telegram is secure ....
in reply to Delta Chat
Absolutely. I just hope you can also see my point that, if you don't like it when Telegram does it, then you should also not lure people with somewhat misleading claims that are then clarified in the details.
in reply to Götz Hoffart
@goetz You can "hide" all relays but one for now, this way all your contacts will send only to one relay and not trigger the bug in 2.43. This is actually done automatically during upgrade, by default all relays except the primary one are hidden right after upgrade, so you don't need to do anything.
in reply to Séverin Lemaignan
@severin thanks! Unfortunately, it is not likely the apps will offer contact discovery themselves. It would bring #deltachat closer to being a social media app, and invite spam and abuse which we are not prepared to handle due to the decentralized nature of our efforts. We do not know, mediate or see any interactions between users, an providing central discovery would break that privacy property.
in reply to Kevin_Runforrest

@Kevin_Runforrest @Delta Chat Audio / video calls on android are lovely! In call UI is awesome, ability to toggle both camera and microphone is working. There is even ability to switch audio outputs (speaker / ear piece).

An improvement to the future would be even more integrated incoming call notification experience. It would be nice to reuse android system support for this part too, so we can mute the ringer sound by pressing volume button and accept the incoming call by using the headset button.

I mean both convenience and accessibility when describing this.

Currently accepting the call can be done either by tapping the buttons in the notification area or tapping incoming call entry in the incoming message list. That includes multiple steps. Showing incoming call popup similar to how other apps are doing it would be more accessible.

Please don't take this as a complaining. I like these advancements very much. This is how I am envisioning it to work for the future.

in reply to ⁡jaseg
@jaseg yes, it's about message header metadata, and the fact that no cryptographic identities are visible on the transport layer, making it hard for hostile servers to track anything when users change relays. This blog post is not a security whitepaper, which we admittedly still need to update and produce.
in reply to Delta Chat

thanks for the clarification. speaking from my network security background, the whole timing leakage is what i’d call metadata and what your “zero metadata” thing is protecting (AFAIU timestamps and cryptographic identities) in a cryptographic protocol i’d consider straight up data, not metadata.

thinking about an average user of a secure comms tool, i’d expect they would be surprised to learn that something that is “zero metadata” still leaks timing and through correlation identities.

in reply to ⁡jaseg
@jaseg in the very first sentence we try to clarify the scope, i.e. "With the latest 2.48+ releases, a chat message reveals close to zero metadata to servers." The key phrase here is "to servers", and we then detail all the data that was made invisible to the server.
If you want to discuss this further, it's maybe better done in a support forum post.
in reply to pancake
@pancake thanks a lot for the report, we have a theory, how that could happen, i created an issue for that at github.com/deltachat/deltachat… - maybe you can confirm or refine the issue there
Unknown parent
@imyxh zero metadata refers to the messages and server state on disk. There is no metadata collected like phone number or identifying email address or group membership etc.. All data on the relay server can be wiped and the service recovers on fresh setup and chatting continues. But it's true, that traffic timing and IP addresses are visible to relay endpoints but also they are not logged or collected on standard setups. Still, it's fair observation that we can't claim "overall zero metadata".
Unknown parent
The media in this post is not displayed to visitors. To view it, please go to the original post.

this image posted on the blog with the caption "orange: random, green: hidden, everything else: no meaningful data" is so incredibly misleading because someone could very easily interpret it to mean: (a) send and receive addresses are randomly generated per message, (b) the MTA doesn't see the real timestamp, and (c) the recipients are "hidden" to the MTA.

but, as i understand it, NONE of those three things are true.

Unknown parent
mastodon - Link to source

holga

@imyxh i see your point but i think you may be over-dramatizing. I web-searched "deltachat metadata", got directly to the blog post under discussion and the first sentence reads: "With the latest 2.48+ releases, a chat message reveals close to zero metadata to servers. For cryptographers and messenger enthusiasts, here are the key points on how we turned email very close to zero-metadata". That's not so dramatically misleading as you suggest. Anyways, have a nice weekend / me out :)
Unknown parent
@imyxh @hpk there are several view points from which to look at the issue of metadata. For example whether assuming a hostile server operator or a system running as specified. It requires more evolved writing than the blog post or put discussion here to sort it out. We heart your critique and also thanks for the appreciation but we will not change the march blog post now, and rather take your critique into consideration for future write ups.