Delta Chat

Zero metadata, group descriptions, native audio/video calls and much more!

Tue, 31 Mar 2026 00:00:00 +0000

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:

No cleartext Auto-Submitted or threading headers. In addition to Subject, To, and group membership headers, we’re now also protecting Auto-Submitted, References, and In-Reply-To. This means that all meaningful header metadata now lives exclusively in the encrypted part of messages, implementing full Header Protection (RFC 9788). Transport servers only see a minimal so-called outer envelope.

Randomized Date header. The outer Date is 5-day randomized, preventing timestamp-correlation from attackers with access to temporary server message archives. Delta Chat would not need this header at all, but we decided to maintain compatibility with other encrypting email apps, and classic email servers, which often require this outer Date header to function at all.

SecureJoin v3 hides cryptographic identities. When the user scans a QR code or clicks on an invite link, multiple administrative messages are exchanged in order to establish a chat and verify the encryption setup. The new SecureJoin protocol (link contains more beautiful hand drawings!) encrypts all initial messages, and also shows how to skilfully evolve a protocol to be both forward- and backward-compatible, thus avoiding any friction for users.

No cryptographic key information in OpenPGP messages anymore. We have finally enabled OpenPGP anonymous recipients after waiting five months to give everyone time to upgrade their chatmail clients first. Please make sure all your devices, and those of your contacts, are using at least the v2 security-upgrade releases from August 2025 . Especially apps older than June 2025 might encounter “unable to decrypt” messages otherwise.

No “Sealed Sender” yet, but also no phone numbers or private data recorded at chatmail relays. Chatmail profiles are created with random addresses and without asking for any personal information. We have some ideas about eventually implementing “Sealed Sender”, but are more likely to aim for Autocrypt2 support first, a new IETF specification draft for Post-Quantum-Cryptography and Reliable Deletion (“Forward Secrecy”).

orange: random, green: hidden, everything else: no meaningful data

Native calls on Android and iOS!

Audio and video calls on Android, iOS now behave like native phone calls: you can keep a call running in the background while switching to a different chat or even another app. Another useful use case is to talk while playing in-chat games like chess! Under the hood, calls use peer-to-peer WebRTC with signaling via regular Delta Chat messages. The feature is still behind the “debug calls” setting but probably not in the next release anymore.

Native video calls on DeltaTouch (Ubuntu Touch)

Google and Apple are highly problematic centralized authorities for the mobile ecosystem, which is why we are supporting developments on alternative mobile ecosystems to the best of our abilities and resources. Luckily, there are some private donors supporting development of DeltaTouch in particular, a pretty much feature-parity Delta Chat client available on many “Lomiri” platforms. DeltaTouch recently also landed audio/video calls, compatible with Delta Chat and all other chatmail clients. If you have C++ and QT knowledge and interests, by all means consider helping in the Codeberg DeltaTouch repository, and the friendly and skillful developers behind it.

Group and channel descriptions

Groups and broadcast channels now support descriptions that members see in the group profile. Descriptions are end-to-end encrypted and synced with member additions, making it easy to tell new members what a group is about.

Background audio message player

For those of us who like interacting via audio messages, this is golden: both Desktop and Android now support playing audio messages in the background.

Download on demand revamped (what a journey!)

We had to fundamentally re-implement the years-old “download on demand” feature, because it was relying on “cleartext headers” that aren’t available anymore (see the intro on zero-metadata above). For larger messages, and messages with an attachment, Delta is now internally sending two messages, one small and one large. This provides receivers the choice to first download all small messages, and automatically or optionally download the larger ones:

Calls can get through without first downloading potentially megabytes of attachments.
Delta Chat iOS notifications work without crashing on large messages.
Not yet fully downloaded messages are correctly placed in chats (instead of weird 1:1 email messages).

We still know about a few shortcomings but it should mostly just work fine. For those interested in the breadth of past and ongoing implementation efforts, search for ‘pre-messages’ and pray the apparently increasingly vibe-coded GitHub infrastructure grants you results.

“At-risk” user needs: 1. availability 2. telegram 3. security

For over a decade, security-oriented messengers have been urged to match the latest cryptographic protocols, with Signal often cited as the gold standard. With the current releases we are closing in on the security and privacy gaps between Delta Chat and Signal. But we’d like to kindly remind everyone that Telegram has reached more than one billion users. One billion people! Many of whom prioritize user experience and UI features, happily providing message content and metadata to the billionaire hands of Mr. Pavel Durov, who offers nothing more than a “Trust me, bro!” attitude. His skills in security propaganda are second to nobody!

Delta Chat has always been a pragmatic UI-oriented project. We aim to provide the features users expect without centralization and monopoly traps. Even with limited resources compared to tech giants our newest releases continue to drive usability and modern UI features forward. An impossible dream for Telegram channels users, Delta Chat’s encrypted broadcast channels are evolving to provide a more secure and private alternative. Also, our public ‘find a messenger with more convenient onboarding’ challenge remains open for submissions. No strong competitors emerged so far :)

As we enter 2026, the rise of authoritarianism makes communication resilience critical for an increasing number of “at-risk” users everywhere. If a tool is blocked or unavailable, its features, security or otherwise, provide exactly zero benefit. Real-world availability is the very foundation of security in emergency situations, and in this regard, Delta Chat apps are likely second to none. Even the New York Times seems to agree and we are not quite done yet developing more resiliency features …

Maximizing availability and resilience through multi-path delivery

Single-path messaging systems suffer from a fundamental flaw: if your primary server is blocked or goes down, communication stops. Centralized services like Signal, WhatsApp, or Telegram are easily targeted and if they go down themselves, there is no remedy whatsoever. Also the decentralized Matrix requires depending on a single home server, creating a persistent single point of failure.

Our new releases introduce resilient multi-path message delivery. Each profile can now use multiple relays or mail servers for sending and receiving messages. If one is blocked, messages automatically flow through another. Tapping into the growing network of chatmail relays, Delta Chat users can finally achieve true transport-layer redundancy, and transport operators can sleep better knowing that if their relay goes down it will not prevent users from chatting. You may imagine it as providing multiple evasive paths for those seeking to evade the All-Seeing Eye of centralized surveillance and control. For Rust experts interested in the implementation, start from the “multi-relay” development issue.

any of two relays of Alice or Bob can fail, but chatting works

Currently, adding secondary relays is a manual step in “Advanced Settings -> Relays”. Ensure all your devices are upgraded to version 2.48 or later before enabling this feature.

After conducting more research and iterative streamlining of multi-path operations, we aim to automate the onboarding process so that profiles learn about new relays organically. We are setting ourselves the mad goal of providing an unstoppable, planetary-scale and very private Internet messaging experience, while using and improving IETF Internet messaging (email) protocols, with room for community developments, adaptations and variations at every level.

If you would like to support our efforts, please consider contributing or donating, running a chatmail relay, or explore the enjoyable wilderness of using or creating secure mini-apps, without depending on any app store or hosting servers.

♥ thanks for following and supporting us ♥

Delta Chat V2: a major security upgrade, beautified contact profiles, new email action and direct app access in chats

Mon, 04 Aug 2025 00:00:00 +0000

With Delta Chat Version 2, chats are end-to-end encrypted, always and by default. Previously it was possible that chats without green checkmarks could contain messages without end-to-end encryption. Not anymore. Consequently, Version 2 drops all lock icons, most green checkmarks and a few “decryption problem” dialogues, simplifying the user interface and raising the floor for real-world security outcomes. After all, most users don’t want to engage in theorizing and checking end-to-end encryption. They have actual lives to live, and enough challenges to tackle already. They just want a reliable fun-to-use messenger that keeps their chats, messages and contacts private. The decade long discourse on how to achieve this “just” is ongoing, and V2 releases are our contribution to it.

Rolling out major security-upgrades into federated ecosystems

V2 releases maintain compatibility with older releases, even though they roll out a major security upgrade across many hundred thousand devices, across dozens of apps and bots, at relatively random points in time. During 8 years of development, we never needed to ask users or developers for “co-ordinated upgrades” like for example Matrix and Session did in 2025. But how could we avoid asking for such painful coordination, when other federated messaging projects struggle?

First of all, the planetary-scale email system is mature and has separation between transport protocols and message formats. There are no sudden changes in the SMTP protocols which deliver 360 billion messages per day. There are many battle-tested server implementations. Upgrading any of the many chatmail clients is largely unrelated to how servers upgrade.

Second, Delta Chat and all other chatmail clients embed the chatmail core Rust library. This means there is a single central place where “moving the ecosystem” can be implemented. The key v2 work in the chatmail core Rust library added 4696 and removed 6299 lines of code, netting a removal of 1603 lines of code. It fundamentally changed how “identity” and end-to-end encryption is handled in chatmail V2 messaging. Chatmail clients, though? They don’t need to do much more than pulling in a V2 core version, drop some UI elements, adapt a few APIs and enjoy vast security and compatibility benefits. It’s as relaxing as it sounds (except for chatmail core developers who bear the brunt if anything goes wrong).

Third, low-level chatmail core developments are moored to UI and UX goals, and involve ongoing usable security research into federated messaging systems. Our protocol- and cryptography-experts accept constraining their designs so that they fit actual UI and UX goals, not the other way round. Providing smooth distributed upgrading across the ecosystem is a key UX goal which all teams aim for.

Fourth, luck. We may have been just lucky, all things considered :) Our centralized core Rust architecture and mature email protocols with transport/content separation help but do not guarantee that we never have to ask users unpleasant questions or for forgiveness. “Nothing works all the time” is a long-running meme in chatmail circles, with a double meaning. It was probably coined around the second 10-day gathering in Kyiv 2019.

Chatmail relays: a second layer of E2E enforcement

Chatmail relays are used for default onboarding of Delta Chat users and

provide random interoperable email addresses without asking for any private information,
enforce OpenPGP end-to-end encryption with metadata-minimization for all sent and received emails,
enforce strict Transport Layer Security (TLS) and Domain Key signing (DKIM)

Chatmail relays and apps each independently enforce transport and end-to-end encryption across the world-wide growing secure chatmail ecosystem. New relays are automatically interoperable based on cryptography and IETF standards. No permission from us needed.

Classic email usage was enhanced but requires opt-in

You can not receive or send messages without end-to-end encryption when onboarding with chatmail relays, but you may manually setup a classic email account, also as an additional profile. Messages without end-to-end encryption will then be marked with a mail icon. Only classic email profiles offer the new “new email” UI action that allows to set a subject and add email address recipients before sending a cleartext email. With Version 2 releases, emails without end-to-end encryption are generally easier to recognize because chat avatars will also use the same boring mail icon and chat messages in mail chats will never become end-to-end encrypted.

Contact Profiles are more beautiful on all platforms

While users have few problems navigating identities in small private circles, the new more beautiful contact profiles aim to help navigate larger chat circles where members frequently get added or removed. The new contact profile aims to help users to identify group members and chat partners more easily.

Shortcuts to recently used apps in chats

All Delta Chat clients now provide direct access in the chat title bar to recently used webxdc apps. For more background, we recently wrote about refined app discovery, notifications and home screen integration at Replacing billionarish platforms with zip-files, and about the introduction of realtime Peer-to-Peer networking, followed by running a Quake multiplayer game co-ordinated between chatmail peers.

PS: the chatmail ecosystem is moving

In 2016, Signal founder Moxie Marlinspike claimed in the ecosystem is moving that federated systems, and email in particular, can fundamentally not do end-to-end encryption:

So while it’s nice that I’m able to host my own email, that’s also the reason why my email isn’t end-to-end encrypted, and probably never will be. By contrast, WhatsApp was able to introduce end-to-end encryption to over a billion users with a single software update. So long as federation means stasis while centralization means movement, federated protocols are going to have trouble existing in a software climate that demands movement as it does today. (Moxie Marlinspike July 25, 2017)

Challenge accepted :) Today, the chatmail ecosystem of apps, servers and bots is living proof that email based end-to-end encrypted messaging is not only possible, but even rolling out big security enhancements throughout a federated system can work. But there is a fun twist that reinforces Moxie’s core “centralization means movement” argument: chatmail Rust core beats Signal in terms of being one centralized codebase that is used in all chatmail clients. All federation protocols and IETF standards are implemented in this one centralized library with a single database schema, whereas Signal’s Android, iOS and Desktop versions each use different databases (making migration between platforms hard) and different languages to implement networking, higher level data structures or even some cryptographic properties like Sealed Sender.

In the cryptographic machine rooms, centralized chatmail core efforts co-evolve with the security-audited rPGP Rust library which implements state-of-the-art end-to-end encryption protocols and algorithms. Few know that Delta Chat uses the same Ed25519 Rust signing crate as Signal, that chatmail only uses a minimal carefully selected subset of OpenPGP, and that current-day OpenPGP collaboration between various players is pretty enjoyable. Chatmail clients are not implementing any aspect of OpenPGP, TLS or email protocols. The embedded chatmail Rust core and rPGP do all the heavy lifting, both backed by multiple security audits.

To make a longer story short, we recently posted about our commitments to federation:

We are basically doing what #signal and in particular Moxie refused to do, or declared impossible: federation.

Both the #email and #activitypub ecosystems are all about federation.

However, #deltachat is vertically centralized in that all UIs use the same #rust core which implements all networking, encryption, chat/group/message logic in a single centralized place. The now 40+ #chatmail mail relay network is driven by centralized code.

At each level, replication and federation is built in.

PPS: What some of you may be curious about

We revised our Encryption and security FAQ and include notes on Forward Secrecy, Sealed Sender and Post Quantum Cryptography. To hear about our conceptions of usable security and future plans you may watch two security talks from June 2025.

PPPS: What regular end-users wonder about :)

A while ago, a contributor’s parent and long-time Delta Chat user got back saying: “Everything is fine! But why does each message have a hand bag?”

A big user surge and funding for decentralized scale

Wed, 04 Jun 2025 00:00:00 +0000

Beginning June we witnessed a sudden surge of Delta Chat usage especially in the US and Cuba. We don’t know the social dynamics behind it but it probably helps that Delta Chat apps resiliently work on all platforms and offer a pleasing user interface which increasingly many families, groups and communities appreciate. Be that as it may, let’s look at some indicators of the recent surge, then highlight centralization risks and our mitigation efforts.

5000 new users per hour on the default chatmail relay

Fun fact: after some performance adjustments to Dovecot, the small physical server keeps humming along at 20% CPU and 20% IO pressure without consuming noticeable disk storage.

1.8 Million Google/Apple push notifications per day

This daily number reflects the incoming messages for chatmail users who installed their app from Google Play or Apple store. F-droid, Desktop or classic e-mail users are not reflected in this number. Number of daily push notifications was around 350K end of February 2025.

Google Play Android downloads crossed 500K downloads

Note that we generally recommend F-droid or other non-Google sources of installing Delta Chat apps and only have a somewhat informed guess that at most half of Android users use non-Google sources.

Funding for a globally scaled chatmail relay network

There are many community-operated chatmail relays on all continents but most new users choose the default onboarding relay in Germany, reproducing the known problem of formally decentralized but centralized in practice offerings. We are engaging in two key Research and Development areas to fundamentally mitigate this centralization tendency and achieve distributed scale, along with improved resiliency and privacy:

Cryptographic hardening: Using e-mail addresses as transport but not as a source of identity; hiding cryptographic identities from transports; and further minimizing visibility of meta-data in messages.
Multi-transport: Allowing a chat profile to use multiple chatmail relays interchangeably, releasing users and operators from making “life-long choices” in favor of “as long as it works” choices.

However, public funding for these key infrastructure efforts suddenly dried up earlier in 2025, disrupting our ability to follow through with our always usability-driven work. We are now seeking to finance key development work through donations, aiming to provide decentralized secure messaging infrastructure at global scale, all open to third parties joining the fun in a permission-free manner. A Minecraft-like world for messaging.

Donate to the new chatmail infrastructure OpenCollective (Europe)

Donate to Delta Chat app developments (Libera, BTC, IBAN, OC)

Nothing like in-person cross-project gatherings: DIFF!

Last but not least, if you are interested in more technical details and want to engage with our various contributor teams and communities, the place to be is DIFF in the Black Forest starting this weekend or, else, for now, sorting your way through our development repositories and the twisted maze of community and contributor chat groups :)

Delta Chat Desktop, but running inside of Firefox 🦊

Thu, 22 May 2025 00:00:00 +0000

As part of the project to port Delta Chat Desktop from Electron to Tauri¹, we’ll showcase a setup where our Desktop app runs in Firefox and does not depend on Electron or Chromium anymore. This video and post walks through what works already, and what doesn’t and is generally aimed at developers and expert users.

Delta Chat, running in the Firefox Browser

Features:

☑️ Basic functionality (such as sending and receiving messages)
📎 Sending attachments
🔔 Notifications (while the tab is open)
1️⃣ Badge counter (number in tab title)
🦊🧭🏐 Works in Firefox, Safari, and Chrome
🔐 HTTPS with self-signed certificate
🔑 Password Protection
⬇️ Download attachments or open in browser (useful for PDF)
ℹ️ Local Help also works
🌐 Language based on Browser

Here is a video that shows the Browser Version in action:

Though it is not standalone, it still needs a server component because Chatmail core² can not yet be compiled into a WebAssembly to run fully in the browser, but more on that later.

Why we made a Browser Edition

So why did we make a Desktop version that works in a Browser? We had three reasons:

Lots of people rightfully criticized depending on Google’s Chromium and resource-hungry Electron³.
To give access to development tools and add-ons on all browsers.
To bring back automated integration testing for Delta Chat Desktop.

Possible future use cases

There are many more ways this web version could be used besides the ones already mentioned:

“Delta Chat Web” - run core on a mobile device and connect to it from a computer over a local network for a WhatsApp web-like experience.
Delta Chat as a service (for example, a company could host instances for all their employees).
It could be a way to port Delta Chat to special operating systems⁴ that have a browser and rust support, but have no support for Electron or Tauri¹.
Run Delta Chat Web on your Raspberry Pi / home server connect from your devices
- treefit already made a plugin for running it on home assistant

Delta Chat Web inside of Home Assistant

Diving deeper into technical details

To make the Web UI of Delta Chat Desktop independent of Electron, we needed to make our code more modular:

We switched to the JSON-RPC API, which we highlighted in a previous blog post.
We created a new Runtime interface and moved all direct calls to Electron into a RuntimeElectron class that implements this interface.
We also moved nearly all the logic to the frontend/UI code, so the runtimes are even simpler to make and maintain because they contain less and simpler code.

Effectively, the web-based UI of the desktop client became independent of Electron or Chromium. To add a new Runtime you just need to implement the runtime interface and load it when you start the app.

The code of the runtime interface: https://github.com/deltachat/deltachat-desktop/blob/main/packages/runtime/runtime.ts#L29

Downsides and Caveats of the Current Browser Version

The current approach has the following caveats that you should to keep in mind

If you host the server component on a VPS, then the VPS will become the place where the messages are decrypted, so you break the premise of the end-to-end encryption: "end device to end device".
You need to host the server component for each user, so you need to build management software if you want to use this for a SaaS project/product.
Currently, only one client can connect to the Chatmail core at a time, because there is only a single event queue.
If you would connect multiple clients right now, then they would steal events from each other.
The current security could be improved: The WebSocket server does not perform origin validation and the login has no timeout/cooldown on wrong passwords. But those would be easy to add.

Also, some features are still missing in the browser version:

webxdc chat-shared apps
experimental maps/location-streaming
viewing HTML emails

These missing features, and especially the webxdc app sandboxing, require more work. See Webxdc security blog post for a deep dive into the issues.

What comes next requires helping hands and contributions

Besides the issues noted, a Web version of Delta Chat that fully satisfies end-to-end encryption guarantees needs the Rust Chatmail core library to run in the browser. Rust in general compiles to WebAssembly (WASM). For example, the security-audited rPGP end-to-end encryption library is implemented fully in Rust and is continuously tested with WebAssembly targets. However, there are some key challenges to address for a “standalone” Web version:

Find a solution for both database storage (currently Chatmail core uses SQLite as an embedded C-library) and arrange fast file storage for media files, avatars etc.
Find a solution to Browsers being unable to perform SMTP or IMAP network protocols; this could involve Chatmail relays offering a minimal HTTP/WebSocket interface to bridge the gap.
Support webxdc realtime P2P networking and support running in-chat multiplayer Quake III Arena realtime gameplay; Our friends at Iroh are themselves working on Web-versions
Explore how well the Chatmail core async Rust code can run in WebAssembly; this could involve a lot of refactoring.

See the Web version topic in the Delta Chat Forum for further discussion.

If you are not really into programming, it might be hard to understand how hard these issues are. But no worries, even if you are a programmer, or even with ourselves as matter experts, it’s hard to predict :)

Invitation to DIFF June 7-17th in Freiburg

The best way to discuss with many of us is by making it to an in-person community gathering. This crazy year of 2025 around we are inviting to the DIFF gathering starting in just a few weeks.

Donations needed

While some of our work is funded through public bodies, a lot of it is not. Please consider sending a monetary contribution if you can and appreciate our efforts and want to enable more. Thanks!

If you want to try the experimental browser version yourself, then you can find the instructions at https://github.com/deltachat/deltachat-desktop/blob/main/packages/target-browser/Readme.md.

Tauri is an alternative to Electron that is smaller, because it uses the web view provided by the operating system instead of including a whole Chromium browser. It is also written in the memory-safe compiled language rust, which offers security and speed benefits. There will be another blog post going into more detail soon; in the meantime, you can learn more at https://tauri.app/. ↩ ↩²
Formerly known as Delta Chat Core. It is the core library all our UI implementations use. ↩
Though It should be said that despite it’s flaws, Electron has served us well over the years and we are grateful that it exists. But it is never good to be too dependent on a single framework, especially one that is so resource wasteful and hard for us to extend or contribute back to. ↩
I’m thinking BSD flavors, Haiku, or other rare enthusiast operating systems here ↩

DIFF Invitation June 7-17th

Mon, 12 May 2025 00:00:00 +0000

During June 7-17th many of our contributors and from neighboring projects will gather in Freiburg in the Black Forest. We will use outsides and insides of the oldest “free and democratic school” in Germany, the “Kapriole”. DIFF currently stands for “Decentralized Internet Federation Fusion”.

Who is coming? What is happening at DIFF?

There will be plenty folks from chatmail developments, from Delta Chat Android/iOS/Desktop/UbuntuTouch, chat bots, webxdc app development as well as Iroh and rPGP projects, and then some who engage with reviving Peer-to-Peer file sharing, or develop Watch2Gether. We are to be joined by people from international solidarity groups, an Ukrainian video and photo artist, piano and noise musicians and likely a theater professional who is to help creating the “Can you arrest a protocol?” play about three anti-cryptography court cases … which might see an experimental premiere during DIFF.

You are invited to join any of this. If you want to bring some friends or conspirators, be our guests.

Co-working, cross-concern hacking and diversions

As of May 12th there are 30+ people arranging themselves to make it, with about a dozen to do so during the full date frame. On some days, some will likely use the opportunity to climb nearby hills, jump into rivers or lakes, or engage in other diversions. Maybe a so called Union of Egoists is not an entirely unfitting reference of how our gatherings typically play out. You may also get some vibes by reading a report about a gathering in Kyiv a few years ago.

The school will be generally open from morning till evening and everyone may also cling together in small groups, take a room and also do internal project sessions. We’ll see to arrange for some food and drinks. Commercial food places are in walking distance. On some days we probably do presentation/demo evenings, and announce them publically. The place is also exceptionally well suited to have kids around and Freiburg is also generally a vacationing area, with quick train rides to Switzerland and France.

Attending and joining DIFF

If you, maybe along with a group of like-minded people, want to join DIFF, that’s quite possible still! If you are an individual interested in any of the above, we’ll see to help you feel at home and welcome. Please take note of our Community standards.

Please send a direct message to our Fediverse @delta@chaos.social or to our delta team address (invite link) and from there we’ll add you to a group chat that uses an webxdc editor and other chat apps for further co-ordination. You will need to care for some accommodation yourself. There also are some possibilities for sharing a room or space if you bring some sleeping gear. DIFF also serves as a testbed for arranging event onboarding and communications in chat groups and chat apps, ahead, during and after the gathering.

Thanks to the Wau-Holland Stiftung

We are grateful for the the support of the Wau-Holland Stiftung who agreed to finance the rent for the location and a travel grant. Many thanks!

Messaging editing, deletion and saving now available!

Wed, 26 Mar 2025 00:00:00 +0000

No need to blush or melt in agony after sending a message anymore! Editing and deleting messages is now available in most app stores :)

How is this possible you might wonder? There are three core pillars about how Delta Chat functions that maybe also help to rectify often occuring misconceptions:

Delta Chat is not a classic e-mail client. It doesn’t show you the content of a mailbox (IMAP) folder. Delta only fetches new messages but never looks back at them. E-mail servers function as message transport only, not storage.
Delta Chat uses special messages to co-ordinate encryption, metadata and group interactions. Examples for special messages are reactions, group creation or membership changes, multi-device synchronization messages, secure encryption negotiation and now also editing or deleting a past message.
Delta Chat implements a Peer-to-Peer messaging paradigm. Unlike with other messengers including WhatsApp, Matrix, Threema or Signal, there is no server side metadata or message state so there is nothing to modify. Edit/Delete are just special messages interpreted by chat partners’ devices.

With those fundamentals out of the way, let’s look at the new features in turn and maybe start with “saving” messages before editing or deleting them ;)

Empowering “Saved Messages” memory

When you forward a message to the “Saved Messages” chat the message will preserve a “>” link jump to the original message. Messages you saved will have a small bookmark icon in the chat so you can easily recognize that you already saved them. There also is a new action when you select a message to save or bookmark it so that it appears in “Saved Messages”. The best: saving/bookmarking is always synchronized between your devices.

Typo-fixing galore: Editing Messages

When you select a message, you can now pick the stencil (“edit” action) and will be back as if the message were a draft. Note that you can only edit the text but you can not change any attachments. Once you send the message, all your chat partners will see an “edited” message, also indicated the message bubble.

Deleting messages across devices

In the past, every time you deleted a chat or a message from one device you would need to go to all your other devices and repeat the process over and over. Now message and chat deletion is synchronized across all your devices without breaking a sweat. If you posted something accidentally (passwords, wrong files or pictures etc.) you can also delete your own messages for everyone in the chat now.

Limits of rewriting the past?

Neither deletion or editing currently have particular restrictions, and there is no history of message edits. You can retract your own message from a year ago, and edit a message 10 times. Will this happen and cause annoyances? If so, we’ll see to address issues and iterate. In any case, antagonistic or malfeasant chat partners have also many other ways to trick and annoy, and it may be a good idea to avoid or block them generally. Meanwhile, enjoy your new typo-fixing, organizing and retracting powers!

From C- to JSON-based APIs of the Rust "core" library 📚

Tue, 11 Feb 2025 00:00:00 +0000

Foremost this is a quite technical post. Read our other blog posts if you want something more targeted at end users.

If you have not yet looked at the Delta Chat source code, you might not know that we have a Rust core library that holds everything together. Infrastructure features like encryption, email and network protocols, chat, contact and message management are implemented in this Rust core library and all apps of the current Delta Chat family as well as chat bots benefit from it:

The core library does all the infrastructure and interoperability work and exposes high-level methods such as getAccounts, getChatlist, getChatContacts etc. so that it’s much less work maintaining apps or bots on all platforms, because they can fully focus on implementing user interactions and interfaces.
The core library is thoroughly tested with Rust unit tests and functional integration tests in Python using live-servers, and core is what makes all apps fully interoperable with each other.
The core library can easily be used to write bots and new apps/clients (like DeltaTouch, a client for Ubuntu touch made by Lothar in about a year as a side project, read the blog post).

The C Foreign Function Interface (CFFI)

The C Foreign Function Interface, for short CFFI, was the first way to link to core. It was introduced back when Björn started the Delta Chat project. He wrote the core in C and forked the Telegram Android app for the UI, which is written in Java, so the core is connected via CFFI¹ and JNI (Java Native Interface). Later when we moved the core to Rust, the CFFI stayed unmodified which greatly helped to keep the ecosystem stable while the infrastructure implementation radically changed.

The advantage of a CFFI is that most programming languages have a built-in way to bind to it.

A peek into how the CFFI methods look like (from deltachat.h):

#define DC_CONNECTIVITY_NOT_CONNECTED        1000
#define DC_CONNECTIVITY_CONNECTING           2000
#define DC_CONNECTIVITY_WORKING              3000
#define DC_CONNECTIVITY_CONNECTED            4000
int dc_get_connectivity(dc_context_t* context);

typedef struct _dc_chatlist  dc_chatlist_t;
dc_chatlist_t* dc_get_chatlist(
  dc_context_t* context,
  int flags,
  const char* query_str,
  uint32_t query_id
);
size_t    dc_chatlist_get_cnt(
  const dc_chatlist_t* chatlist
);
uint32_t  dc_chatlist_get_chat_id(
  const dc_chatlist_t* chatlist,
  size_t index
);
uint32_t  dc_chatlist_get_msg_id(
  const dc_chatlist_t* chatlist,
  size_t index
);
dc_lot_t* dc_chatlist_get_summary(
  const dc_chatlist_t* chatlist,
  size_t index,
  dc_chat_t* chat
);
void      dc_chatlist_unref(
  dc_chatlist_t* chatlist
);

Most methods here provide a pointer to a Rust structure, which can be used to access its properties through specialized methods. After using such a structure, you need to free it using the _unref methods (like dc_chatlist_unref), otherwise you will create memory leaks.

Why implement a new way to talk to core?

While the CFFI in Android and iOS was working fine, in the Desktop version which is based on Electron it was more problematic. Electron contains a full browser which uses multiple processes, and you can’t easily pass pointers to C-structs over process boundaries, ignoring that this would a bad idea². On Android and iOS, you can just call Delta Chat core from the UI thread, because this thread is in the same process that the Delta Chat core library was linked to and not a completely different process like in Electron. So we ended up writing a JSON API on top of the Node.js NAPI bindings on top of the C bindings, more about that below in the comparison.

The other problem in Desktop that it is basically single-threaded and while Delta Chat core uses async Rust, the CFFI blocks on nearly all calls (note the block_on):

pub unsafe extern "C" fn dc_get_fresh_msg_cnt(
    context: *mut dc_context_t,
    chat_id: u32,
) -> libc::c_int {
    if context.is_null() {
        eprintln!("ignoring careless call to dc_get_fresh_msg_cnt()");
        return 0;
    }
    let ctx = &*context;

    block_on(async move {
        ChatId::new(chat_id)
            .get_fresh_msg_cnt(ctx)
            .await
            .unwrap_or_log_default(ctx, "failed to get fresh msg cnt") as libc::c_int
    })
}

In Android and iOS, you can easily start threads or offload blocking tasks to other threads, but on Desktop, each call blocked the main process and led to an unresponsive experience. Even though the communication between our main and UI process was already using async Electron IPC, Electron froze the UI process every time the main process was blocked.

Out of these and other frustrations, the idea for a new way to talk to core was born.

The history of the JSON-RPC interface

First there was only talk, like there were discussions of what wire format to use: CBOR, message-pack or just plain JSON. Then treefit started writing a deltachat-command-API project which was passing requests and answers over JSON. There were two goals: make Desktop development easier and to make the experiment of a KaiOS client possible ³.

After he got the first prototype working, Frando cleaned up and rewrote its code to make it more idiomatic and professional. He also factored out the generic JSON-RPC code into a separate library and the procedural macro into a dedicated Rust crate, so that it can also be used by other projects, which was named yerpc.

Then we merged our temporary “Delta Chat JSON-RPC” repo into the core repo and moved Desktop over to use the new JSON-RPC API, which was easy thanks to the generated TypeScript bindings that gave good auto-completion. Though DC Desktop still used the CFFI and Node bindings as transport (see picture below), until May 17, 2024, when treefit migrated it to use the deltachat-rpc-server binary that uses stdio as a transport⁴.

RPC stands for Remote Procedure Call. Which is basically a way to call functions/methods remotely.

Desktop architecture versions:

Figure 1: When adding a new method we need to touch the code for the components shown in red, gray means that it is not touched, and green means the API code is generated and you can directly call it in the UI code.

The benefits of JSON-RPC over CFFI

Less Code to write - Simplify development

As you can see in this “meme”, adding a method with JSON-RPC is much simpler than adding a method to the CFFI. This is thanks to 2 factors:

A new method does not need to be defined in every component. (see also the “Desktop architecture versions” diagram above)
Code generation: TypeScript client wrapper code and OpenRPC definition are auto generated from the Rust code. (including documentation comments)

Error handling

Error handling in C requires much discipline: a common pattern in C is to return a status code and write results to a pointer that was provided as an argument to the function. Take this example from libimobiledevice’s lockdown.h:

enum lockdownd_error_t {
  LOCKDOWN_E_SUCCESS = 0,
  LOCKDOWN_E_INVALID_ARG = -1,
  LOCKDOWN_E_INVALID_CONF = -2,
  LOCKDOWN_E_PLIST_ERROR = -3,
  LOCKDOWN_E_PAIRING_FAILED = -4,
  // ...
}
lockdownd_error_t lockdownd_client_new (idevice_t device, lockdownd_client_t *client, const char *label)

In our CFFI we are not as strict, we mostly use 0 or NULL pointers to indicate errors:

dccontact_t * dcget_contact ( dc_context_t * context, uint32_t contact_id ) > […] Returns The contact object, must be freed using dc_contact_unref() when no longer used. NULL on errors.

int dc_may_be_valid_addr ( const char * addr ) > […] Returns 1=address may be a valid e-mail address, 0=address won’t be a valid e-mail address

That seems straight forward, but we had a serious bug with an experimental feature because of this.

The error handling bug that led to lost accounts

At the time, there was a bug in the iOS app where accounts would go missing seemingly randomly. Later we found out that only experimental encrypted accounts were affected by this issue.

The bug was basically that Delta Chat iOS thought that locked accounts would be unconfigured, because both unconfigured and error did return the value 0. And if an account was unconfigured, the welcome screen was shown, and this welcome screen has a “back” button that deleted the unconfigured new accounts. But such an account was not in fact new, only dc-iOS thought it was, because dc_is_configured() returned 0.

We fixed this bug by adding a call to dc_is_open() to the welcome screen⁵:

         let selectedAccount = dcAccounts.getSelected()
-        if !selectedAccount.isConfigured() {
+        if selectedAccount.isOpen() && !selectedAccount.isConfigured() {
             _ = dcAccounts.remove(id: selectedAccount.id)
             if self.dcAccounts.getAll().isEmpty {
                 _ = self.dcAccounts.add()

Getting more information about errors than just the fact that an error occurred

As written above, you mostly get to know that and error happened but not what error. So where do we get the error from?

For dc_configure(), you can listen for the DC_EVENT_CONFIGURE_PROGRESS event, if progress/data1 is 0 then comment/data2 contains the error message.
For the other cases you can use dc_get_last_error() to get the last error sting from the last error event - without possible races from waiting for or looping through events.
- But if you do many operations from different threads there can still be races, at-least in theory.

How JSON-RPC solves these issues

There are two kinds of responses to a JSON-RPC requests: a response or an error. An error contains an error code and an error message string.

--> {"jsonrpc": "2.0", "method": "foobar", "id": "1"}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "1"}

In Delta Chat we currently only use the error string. Our JSON-RPC clients (JavaScript and Python) automatically convert these error responses to errors in the target language and return/throw them:

So we always know which call an error belongs to, and we don’t have the risk of mixing up a boolean return value and error.

Named fields in events

In the CFFI you have the following functions to get the data from events:

Return Type	Call Signature
int	dc_event_get_data1_int (dc_event_t *event)
int	dc_event_get_data2_int (dc_event_t *event)
char *	dc_event_get_data2_str (dc_event_t *event)

To know what the data1 and data2 are about and if data2 is a string or an integer, you need to look at the event’s documentation: https://c.delta.chat/group__DC__EVENT.html

/**
 * Emitted when SMTP connection is established and login was successful.
 *
 * @param data1 0
 * @param data2 (char*) Info string in English language.
 */
#define DC_EVENT_SMTP_CONNECTED           101

With the TypeScript bindings on the other hand, you get named and typed properties.

Examples of events in JSON-RPC:

[
  {
    "kind": "SmtpMessageSent",
    "msg": "Message len=2402 was SMTP-sent to example@nine.testrun.org"
  },
  {
    "kind": "MsgDelivered",
    "chatId": 34,
    "msgId": 1342
  }
]

Usage in TypeScript:

dc.on("SmtpMessageSent", ({ msg }) => {
  console.log(msg);
});
dc.on("MsgDelivered", ({ chatId, msgId }) => {
  console.log(chatId, msgId);
});

This works very well with IDE auto-completion and “IntelliSense” (hover to get documentation).

Async usage in Delta Chat Desktop

As described in the beginning, before JSON-RPC we had issues with desktop getting unresponsive when there was a bit more API traffic, for example when fetching a lot of messages. While the CFFI is blocking, with JSON-RPC you never block on a single method call since you just have one bidirectional stream of JSON-RPC messages. This really speed up desktop and made it more responsive.

Easier to use than CFFI over process boundaries

CFFI needs to be linked, which also means it will become part of the process that linked it. JSON-RPC on the other hand requires no linking and is transport-independent, since it is just sending and receiving JSON objects. At the moment 3 transport implementations exist (Electron-IPC, stdio, WebSocket) and it is easy to create new ones.

It is even possible to use the new webxdc realtime API to connect to a remote Delta Chat instance on another computer, similar to the idea of implementing some remote desktop webxdc app. The webxdc realtime API is also an interesting topic in of its own, read its announcement blog-post to learn more.

JSON-RPC API is slowly moving to become the primary API

Delta Chat Desktop and some chat bots use the JSON-RPC API everywhere while Android and iOS apps are only using JSON-RPC APIs for new features that don’t get a CFFI anymore. However, we have no autogenerated wrapper/client for any language besides TypeScript. For other languages, the client-code needs to be written and maintained manually. It is still easier to add new methods to JSON-RPC than to the CFFI, especially where core returns complex struct with many fields: In CFFI you would need to create a new opaque struct, accessor functions for the properties and an unref function and wrappers for those functions. In JSON-RPC you just write the Rust struct & method and process the returned JSON in the client.

While Desktop starts core as a subprocess and performs JSON-RPC requests via STDIN/STDOUT, the other platforms use CFFI calls to perform JSON-RPC requests, for both synchronous and asynchronous access to core⁶. Previously, CFFI APIs were also used in Desktop before it switched to the subprocess approach. See the graphic above in “The history of our JSON-RPC interface”. Using the CFFI-API for performing JSON-RPC calls allows to incrementally use a CFFI-using code base to migrate towards using JSON-RPC APIs.

Three areas where contributions and advances are welcome :)

Currently, we only have automatic code generation for the TypeScript bindings. It would be great to also have automatically generated bindings for Swift, Java and Python. If you have background in generating bindings for these target platforms, and want to get your hands dirty, please get in touch.

The core library has many Python integration tests using the CFFI to Rust core. If you have experience with pytest and want to help porting integration tests to JSON-RPC, please checkout our current functional test suite and submit a PR or get in touch.

Last but not least, the JSON-RPC documentation is still not as high quality as the CFFI one. If you, dear reader, want to help and care about good documentation, we’d be happy for help, maybe driven by trying to write a little JSON-RPC chat bot yourself? Copying the generally good CFFI documentation and improving JSON-RPC API docs step by step would be warmly welcome and supported.

Conclusion / TL;DR

The JSON-RPC API has the following benefits over our CFFI API:

Reduces time to change the API, because you need to edit fewer files.
Better, more robust error reporting.
Complete TypeScript client code generation helps to catch some bugs early during build time.
All methods are non-blocking, which allows for a very smooth user experience without UI freezes.
JSON-RPC over stdio is easy to use from all kinds of programming languages without any complicated linking steps. (like NAPI or the JNI we need to use in the Android app⁷)

So all in all JSON-RPC is a huge step forward in simplifying Delta Chat development.

Replacing billionairish platforms with ZIP files

Thu, 23 Jan 2025 00:00:00 +0000

How can we evolve and deploy web apps without allowing developers or operators to become a “billionaire in the middle”? There are many ways to try to address this challenge and some involve the technical Internet protocol foundations. The “Web”, and the HTTP protocol in particular, arguably played a big part in producing tech billionaires with their possibly unprecedented power and money concentrations today.

Joined by XMPP-messengers Cheogram and Monocles, and supported by many contributing experts in the background, we are playfully addressing the no-billionaire-platforms challenge with webxdc, a container format and API for “chat-shared web apps”. Technically, webxdc apps are network-sandboxed HTML5 apps and instead of the HTTP protocol they use Peer-to-Peer send/receive APIs implemented by webxdc-capable messengers, rebasing relations between developers and users by saying

Bye Bye to surveillance capitalism: Users have both the code and the data of their web apps in their hands and benefit from end-to-end encrypted messaging not only during regular chat messaging but also during their private web app usage.
Bye Bye to user policing (logins, passwords, OAUTH, TOS and privacy policies etc.): Web app developers never obtain or touch any user data or user identities, and can have peace of mind of not being responsible for any data, and not having to program identity management and social discovery UIs. Messengers already provide it through arranging chat groups or rooms.
Bye Bye to depending on a corp or org that enshittifies: Messengers, as decentralized runners of webxdc apps in chat groups, can not hold web app developers, their users or data hostage. Consult Cory Doctorow’s “Ulysses Pact” for why this is a good idea.

This all sounds too good to be true, right? But what if another reality is possible by just stretching out our hands and grabbing it?

Let’s look at some recent webxdc community advances, new webxdc app capabilities along with updates to the webxdc specification, and finally at some community-produced webxdc apps already in everyday use, as working first approximations on how to replace whole Venture-Capital platforms with a ZIP file :)

Integrated and streamlined webxdc app discovery

There is a curated collection of apps available at https://webxdc.org/apps which got a thorough UX/UI streamlining by Jag Talon, a former DuckDuckGo frontend designer. It’s a static web page offering “tool” and “game” search with short descriptions and per-app URLs so you can point people to a particular app. The web page sources its content from this json app list file, generated by commits to the codeberg submission repository. Anyone can run their own curation pipelining and re-use the web interface.

The new webxdc “app-store” web view was designed to integrate well with webxdc-supporting messengers through an “attach-app” action of the chat message input field. Apart from Cheogram, Monocles and the mainline Delta Chat apps, also ArcaneChat (a soft Android-fork) and DeltaTouch (a Lomiri-based UI for UbuntuTouch phones and some desktop environments) offer this new instant attach-app action. Delta Chat apps run the app-picker with cached data so it works during offline times. Most messengers also allow to configure a different URL for an alternative app-picker web page.

Note that webxdc app store sites seed apps but don’t control anything afterwards. They can not collect any metadata or content data about their usage. It’s like distributing .exe files in former times, only safer and more convenient through permission-free and decentralized web-app curation sites. Sorry GAFAM, not sorry.

Webxdc apps can cause instant notifications

We collectively specified and implemented a new webxdc notification mechanism so that apps like Chess can cause a system-level notification between app users aka “it’s your turn”, and the calendar can notify about “your chat partner added a new meeting date”. Webxdc app developers re-use the existing push notification machinery of their host messengers without having to scream at Google or Apple compliance bureaucracy themselves. For webxdc apps to “notify” users they need to specify a list of identities when sending application updates. The webxdc.selfAddr spec describes the details of the new carefully designed “per-app” identity scope.

Webxdc apps can query sending rate limits

Different messengers and transport servers have different “send rate limits”, namely how many messages are allowed to be sent per time duration, and how many bytes an application update can carry. The updated editor app now respects sendUpdate limits, providing for a smoother transport-adaptive user experience. The recently introduced webxdc realtime channels have a specified 128KB size limit for ephemeral application updates. Ephemeral realtime application updates are only distributed between devices actively running a webxdc app that called the joinRealtime API.

Webxdc apps can be placed on mobile home screens

On Delta Chat Android and iOS phones you can now add a running webxdc app to your home screen. Tapping a webxdc app on your mobile home screen will directly start it, and everything remains responsive also while offline. Remember, there is no HTTP server for webxdc apps. All webxdc app state is local, and each webxdc app sends and receives updates by interacting with “localhost” only, leaving all actual network routing to messengers, while being itself blocked from leaking anything to the Internet.

Replacing VC-funded platforms with a ZIP file …

There is no shortage of Venture-Capital fueled mediator platforms that offer “free” web apps or mobile apps (mostly web-apps in disguise) to mediate interactions between private circles. What if you could run such apps in your private chats without needing any mediator, sign-ups, logins etc? Here are a few fun VC-platform-replacement candidate zip files.

Split Bill allows everyone in a chat group to register “expenses” and provides a “balance” view of who owes/is owed currently. Anybody who enters an expense becomes part of the bill but you can also “join the bill” if you don’t add expenses. Split Bill intentionally provides a basic UI. If you feel inclined to add features like a “settle up” button, please fork from the codeberg split-bill repository, maybe tell Jag about it, and submit a new app to the webxdc collection. Or maybe you have an idea how to evolve the split-bill app to become a “solidarity-party” app to help accounting when organizing monetary support for people in need?

Shopping List allows families, friends and other collectives to easily arrange for daily shopping. The “Shopping list app” provides a simple view for entering “missing” items which can be “checked” when someone bought it. It’s recommended to have a special-purpose “Shopping” chat group/room to ask aboutor clarify specifics of shopping items. There even is a “dark mode” and an icon to disable/enable “chat notifications” when the shopping-todo-list changes.

Who doesn’t love todo-lists, the bane of modern existence?
Now you can do them nicely in a chat group. Or maybe you prefer the classic checklist, one of the first webxdc apps back in 2023.

Wonster is a popular daily family puzzle challenge. Every chat group gets their own unique Wonster challenge.

Webxdc app developers may improve an app over time or they may call it a day. The webxdc specification aims to provide long-term backward-compatibility. Once written apps are to work for a long time, on today’s as well as future webxdc-capable messengers. Say Bye Bye to integrating with complex frameworks, broken dependencies, “forced API level upgrades”, new toolchains or store buereaucracy like “your app will be delisted if you don’t declare compliancy with X” etc. Nothing can prevent using a webxdc app with friends if you have, in your hand, the zip file and a webxdc-capable messenger with a chat group/room to “run” it. No worries about VPS or web hosting, DNS or SSL certificates. Peace!

Curious and interested to join some “replace-VCs-with-ZIP-files” fun and work? Getting started with webxdc development provides tutorial material and introduction chapters on what is involved when replacing HTTP with Peer-to-Peer protocols.

We are handing over the mic to the wonderful Rosano who did a succinct intro video a while ago.

watch "just web apps" on youtube

Thanks to NLNET and NGI for their support and vision!

Much of our efforts described above became possible by the vision and support of NLnet-managed funds, financially supported by the European Commission’s Next Generation Internet programme.

Delta Chat introduces realtime Peer-to-Peer networking

Wed, 20 Nov 2024 00:00:00 +0000

Are you interested in enshittification-resistant application development? After almost two years of collaboration with the wonderful Iroh team, and years of discussions with numerous experts in the decentralization space, we are happy to announce that Delta Chat 1.48 apps on all platforms contain state-of-the-art Peer-to-Peer networking support, including hole punching and forward-secret end-to-end encryption. Concretely, Delta Chat now establishes private Peer-to-Peer gossipping networks between users who start a webxdc app that uses the new joinRealtimeChannel() API.

In the following sections, we discuss the “Pixel app” shown in the video and other realtime example apps, before providing more technical background and a closing note on the importance of protocols and specifications in our endeavours. If you want to try out any webxdc app, including the realtime ones:

Install Delta Chat, create a profile and establish a chat with someone
Tap this invitelink to the xstore bot and wait until you receive the store app
Start the store app, pick an app for download and then share it to any chat

Pixel app: small, offline-first and realtime

The source code of the pixel app shown in the above video

consists of 241 lines of Javascript (including all dependencies),
offers collaborative realtime pixel-drawing
and is offline-first as it does not require users to be online at the same time.

The pixel app achieves its hybrid offline-first and realtime connectivity by using two separate webxdc messaging APIs:

webxdc.sendUpdate to relay “application updates” through the regular host messenger channel (e-mail for Delta Chat, XMPP message for Cheogram and Monocles).
realtimeChannel.send to relay ephemeral application messages to any P2P-connected chat partner.

To learn the theory behind how the pixel app achieves “eventual synchronization for all users”, we suggest to dive into our Shared Web Application state chapter and then re-read the 241 lines of Javascript with a particular eye to “Lamport Clocks” – no framework or dependency needed to use this science-fiction-sounding technology ;)

If you want to improve the app, please fork and submit your variant. There already is a Color Pixel app fork where each participant draws pixels in a different color.

Pong app: realtime-only and implements clock synchronization

The pong app repository provides a simple two-player implementation of the classic pong game. UX-wise it’s rudimentary but it does implement basic “clock synchronization” which is an important consideration for any realtime networked gaming app.

Wouldn’t it be nice to have more original or more modern versions of Pong? Maybe also with sounds and colors? Also, to provide a “rollback algorithm” you might look at a 3rd party WebRTC-based Pong development writeup to understand what’s involved.

In any case, if you want to improve on this little Pong classic game, please fork and submit your variant.

Realtime Editor: cursor positions and immediate collab

The realtime editor app is a collaborative editor that can show realtime cursors and changes. However, it’s also behaving as an offline-first app, similar to the pixel app above. If you join a chat-shared realtime editor app later, you’ll see all changes consistently combined. The realtime editor is a fork of the basic webxdc editor but with realtime capabilities added.

Wouldn’t it be nice if there would be coloring of edits? Maybe provide a slider that allows to go back in document history? Or maybe a way to import a picture into the realtime pad?

Again, if you can improve this editor tool you are more than welcome. Please fork and submit your variant.

Unix terminal app: realtime with a chat bot

The xdcterm app demo allows to run a chat bot in Javascript and then establish contact with it from your chat profile. The bot will create a group where you can add more members all of which can see a shared terminal (it’s as if screen-sharing is built-in).

If you want to play with or improve this rudimentary terminal app, please fork and feel free to let us know. You can not submit it to the webxdc app store because it requires a running chat bot on some unix-ish server.

Live Chat: realtime chat in a chat :)

The LiveChat app provides ephemeral chatting with realtime typing-indicators between anyone in a chat group who starts the live chat. Messages are not persisted and all history is cleared when you close the app. If all users have closed the app all content is gone. There you go. Fully ephemeral, end-to-end encrypted P2P chat at your fingertips :)

You may use a Live Chat app in a larger existing chat group to host a fast “ephemeral side conversation” that will not cause any network traffic for other chat group members who don’t join the live chat.

Get ready, player two!

To get started on webxdc app development, we recommend the following readings:

Please don’t hesitate to get back to our fediverse account, the webxdc support forum category or other contact addresses.

Technical background on our Iroh/P2P integration

A joint focus with the Iroh team has been to support all platforms reliably, including mobile platforms. For the last half year Delta apps had an opt-in experimental “webxdc realtime” setting which, after extensive testing and bug fixing, is now enabled by default.

How private P2P networking is established

Only if you start an app that uses the webxdc.joinRealtimeChannel() API will Delta Chat initiate participation of your device in a P2P network. Delta Chat will send an end-to-end encrypted “system” chat message to a group chat that contains an Iroh Ticket. When receiving devices also join the realtime channel, they can establish a direct connection immediately because the ticket is already on record. No lookup in a global distributed hash table slows down or complicates the initial connection. The federated e-mail system is used to bootstrap an ephemeral Peer-to-Peer network.

You may download the Realtime Check app and share it into a chat to perform network latency analysis between realtime messaging peers. You can already run it in “Saved Messages” between two devices in a multi-device setup.

To establish a direct P2P connection, two interested devices will use an Iroh Relay which typically runs on every chatmail server, mirroring the existing e-mail federation. If your chat profile is using a classic e-mail server then a global default relay is used, operated kindly by the Iroh team.

The Iroh relay server combines both STUN and TURN functionality, to allow peers to discover and directly connect. Additionally it relays messages as long as no direct connection is established. For more details please check our Rust deltachat::peer_channels docs.

Identity on the P2P network is ephemeral, and encryption is forward-secret

Delta Chat uses ephemeral cryptographic identities for any P2P messaging. When Delta Chat is closed or stopped by the operating system, then a new ephemeral identity will be created on the next start. Moreover, Iroh uses QUIC on the networking layer which implements Forward Secrecy.

Ephemeral identities and forward-secret encryption shield against an attacker that collects encrypted network traffic and later compromises your device to try to decrypt past recorded traffic. Not only the Live Chat app but all realtime webxdc apps benefit from the ephemeral and end-to-end-encrypted Peer-to-Peer messaging provided by the Iroh stack and its Delta Chat integration on all platforms.

A privacy note on IP-addresses

Delta Chat does not store IP-addresses anywhere and it does not expose IP addresses in the user interface or to webxdc apps. Iroh relay servers do not see all the IP addresses that user devices advertise to each other (for example relays don’t see peer’s WLAN addresses), and relays also do not store any IP addresses when facilitating a P2P connection.

However, chat partners may learn about your IP address if they deploy some network monitoring tool or use a modified version of Delta Chat. If using webxdc apps with a potentially hostile chat partner is a concern for you you may disable the “webxdc realtime” setting in “advanced settings” to be sure that Delta Chat will never attempt any Peer-to-Peer connection with anyone. Don’t forget to then also be careful when clicking on any HTTPS-link in a chat as a hostile sender could use it to extract your IP-address as well.

Specifications, protocols and the freedom to exit

When other webxdc-supporting XMPP messengers like Cheogram and Monocles implement the new webxdc realtime API, they are not required to use Iroh but can instead use other existing XMPP ephemeral messaging capabilities.

The webxdc.joinRealtimeChannel() API is a minimal high-level API that is easier to use than the classic WebRTC Browser P2P API because a webxdc messenger implementor carries the burden to manage all dynamic connectivity, discovery and network routing aspects.

In fact Delta Chat apps themselves could evolve to use a different implementation for webxdc realtime communications. We’ve noted in the Fediverse lately that Protocols and specifications provide freedom of exit and the new realtime API specification is a practical example for that.

Thanks to NLNET and NGI for support and vision!

Our introduction of the webxdc realtime API has been supported by NLnet, themselves funded by the European Commission’s Next Generation Internet programme.

Instant Onboarding and Instant Message Delivery

Fri, 31 May 2024 00:00:00 +0000

A major milestone in our 6+ years long project history: With the rolling 1.46 app releases you can start chatting without a pre-existing e-mail address. Just provide a name and then tap “Agree and continue” to create a chat profile using the default chatmail server. Or visit other chatmail servers and tap the invite on their home page.

Great, a new chat profile in a few seconds, but what now?

Getting in contact with others is indeed a fundamental problem for any non-mainstream messenger. In the next two sections we suggest how to get in contact with some bots and humans, before highlighting more news about the 1.46 release series, and providing some of our thinking around the UX and UI direction of Delta Chat and chatmail servers.

Getting in contact with chat bots and “DeltaFans”

You may tap “invite links” on a device where Delta Chat is installed like the following:

To verify things work, send a message to echo@nine.testrun.org and observe the echo reply arriving quickly.
Checkout a “Public Bots” index bot to receive a little web app to view and start interacting with a selection of yet more bots. Rest assured, no ChatGPT inside ;)

If you feel more adventurous you may contact Delta Fans, an highly-experimental “community” chat profile which was recently shared in the fediverse and lives on many people’s devices.

Troubleshooting: if tapping an invite link does not open a chat for you, you get re-directed to the i.delta.chat website where you may “copy the link” behind the “Open Chat” button, and then paste it into the “Scan QR Code” screen of the Delta Chat app.

Getting in contact with human fellows

When using default sign-up with chatmail servers you can only send out end-to-end encrypted messages. You can setup guaranteed end-to-end encrypted chats by

adding a new contact through a QR code scan, or
sharing your own contact info as an “invite link” that any receiver who has installed Delta Chat can tap to start a chat with you, or
sharing a “group chat invite” that any receiver who has installed Delta Chat can tap to join the group, or
being added to a secure group chat which will allow you to message any group member.

Note that setting up secure chats works just fine in mesh networks in the Amazon Rain Forest or in regions that are cut off from the wider Internet. No central key server or other global infrastructure is required.

New: Introduce a contact to chat partners

With the 1.46 releases you can now “attach” a contact to a chat message, and any receiver can tap it to start chatting with the attached contact. The contact attachment has the vcard format and contains your name, avatar, e-mail address and encryption information so that the initial message can be end-to-end encrypted to the contact, allowing it to travel to other chatmail and e-mail servers safely.

New: Instant push notifications for Android

Instant message delivery through push notifications is not only available for iOS but now also for Android devices, without giving Google and Apple any access to user data. Check out our new push notifications FAQ section for more details. “Messages not arriving or arriving with long delays” has been a recurring real-world issue that we hope is now soon becoming a thing of the past.

Chat profiles: on your device and in your hand

Delta Chat does not store or keep data at e-mail servers but only uses them for ephemeral message transport. When first onboarding with Delta Chat you’ll create a “Chat profile” which initially consists of your chosen name and avatar, and an automatically generated encryption-setup, e-mail address and password. If you tap “use other server” and “manual login” you can manually specify an existing e-mail address and password.

Over time, your chat profile accumulates contacts, chat groups, messages and media files. You can transfer or duplicate your chat profile to another device, either by a QR code scan or by exporting it to a file and then importing and using it on any other device. Chat profiles are literally “in your hand” and stored on your device(s). No chat profile data is stored on any server, also not in encrypted or PIN-protected form. Chat profiles use servers only for end-to-end encrypted message transport.

Are we turning our back on classic e-mail?

No.

Firstly, chatmail servers are fully interoperable e-mail servers, but they do away with spam-checking and unnecessary rate-limits, allow anonymous sign-up without requiring any private data, and are faster and more efficient than classic e-mail servers.

Secondly, chatmail servers run the popular postfix and dovecot server software in a minimal configuration, with small tweaks for optimized onboarding, speed and security. Both systems are proven Free and Open Source software used by tens of thousands of e-mail providers for billions of messages per day.

Thirdly, you can still use your existing e-mail address and there are many providers with which Delta Chat works well, apart from the lack of push notification support.

Lastly, while Delta Chat aims to offer easier onboarding than Whatsapp, Signal or Telegram you can also use and regard it as an e-mail app. All Delta Chat apps offer multi-profile support which means you can have a profile for instant chat messaging and another profile with a pre-existing e-mail address for classic e-mail purposes.

Are we de-emphasizing e-mail addresses in the user interface?

Yes.

We aim to make Delta Chat more approachable for the many folks who do not care about or are even critical of “e-mail”. With some likeliness that’s not you because you are reading this post here :) But you probably know people who don’t rejoice when hearing “e-mail” but who might appreciate that Delta Chat

provides a convenient and reliable messaging experience,
does not require a phone number or any other personal data,
offers privacy, censorship resistance and free choice of server,
offers in-chat games like 2048, Chess or Hextris, and in-chat tools like an editor, a calendar and a checklist.

In light of all these features, we prefer to not require would-be-users first to understand what “e-mail” has to do with anything. As a 20-year old woman once fed back “E-mail? Isn’t e-mail just there for spam and work?” E-mail in the form of chatmail is so much more than that but we still think it’s good to let e-mail addresses recede into the background of Delta Chat just like phone numbers typically recede into the background of classic phone-based messengers.

Chatmail makes e-mail cheap again

With our new chatmail-based instant onboarding system, e-mail addresses are becoming, like in the early 2000s, cheap and virtually free. But this time around, there is no company posturing to “do no evil” luring everyone to their central “ethical” service and then drop the pretense soon after. Running a chatmail server is a cheap activity that we want people to be able to do on the side and on low-end hardware all across the world. Chatmail is best described as an ephemeral end-to-end encrypted messaging routing system running at Internet-scale.

Internet standards FTW or: e-mail strikes back!

How often have you heard “E-mail is dead” or “here is this brand new thing to replace e-mail” from marketing pushes throughout the last two decades? How often have you heard “The Web is dead and replaced by mobile apps” only to find most mobile apps being a thinly veiled web view, anyway?

By contrast, Delta Chat fully embraces both E-mail and Web standards to avoid the pitfalls and failures of past and present “inventing a new standard to replace e-mail / the Web” efforts. Our new “Instant onboarding” relies on chatmail servers that operate as part of the existing massively distributed e-mail network to provide a fast and secure basis for decentralized instant messaging.

In other words, Delta Chat is a messenger that fundamentally heeds the warning of XKCD 927 :)

XKCD 927