### Teknikal's_Domain

#<NTA:NnT:SSrgS:H6.6-198:W200-90.72:CBWg>

# Delta Chat: Instant Messaging Using... Email?

So this is a fun one, and likely a long one. Come, let’s talk about the unlikely backing for a decentralized, privacy-focused communications platform, the very weird ways in which IMAP can be used, and a hopefully final wrap-up to my streak of rambling about PGP.

To summarize buzzwords aside, Delta Chat is a IM -like, free, open-sourced, messaging app available for most major platforms: Android, iOS, Windows, Mac, and Linux. Delta Chat (or just ‘Delta’) is unique in that it’s… just an email client, really. The entirety of it is founded on standard email, with one special twist. Users do not all need to install Delta to communicate, and, realistically, being frank, it only provides two benefits over regular email: Autocrypt, and a Telegram- or, supposedly, Messenger-like chat-style interface. Do not get me wrong though, I really love these sort of interesting takes on “what can we do with the technology that we have,” and do not take that previous statement as me saying the app is a complete waste, far from it. But anyways, let me break down how it works.

## Core Infrastructure

At the core of Delta is your email account, with your standard SMTP / IMAP settings. Delta likes to make three connections to the IMAP server when it’s up, and immediately put them into IDLE, meaning the clients will still received ‘untagged’ information as defined in the IMAP spec, like if the number of mails in a mailbox changes, but the server can safely shuffle those connections over to low-priority queues. Delta also will create the top-level folder “DeltaChat” on the IMAP server if it can, which is where it will put all messages that it has received and handled. As much as using plain email as your infrastructure has a lot of benefits, since you likely already have an email account (I mean, they’re literally necessary at this point), and privacy-focused people will likely have one that they trust and is secure (ProtonMail, maybe?), that means that you don’t have to worry about another account on another platform, and the security of your communications, and your user data, is completely in your hands and up to you. The disadvantage is that email can be slow at times, with things like multiple layers of spam checking, greylisting, trying to find a valid MX for a given domain… But usually, after the initial messages, you’ll likely be able to talk just fine, and if both users are using accounts on the same mail server then communication can indeed be faster than other instant-messaging apps, like Telegram.

Receiving messages is easy, just spawn some IMAP connections, wait to be told there’s new mail, and either file it into the folder and display to the user, or just ignore it if it doesn’t apply, it’s that simple. Sending is also simple… it’s called sending an email. Authenticate to your account’s SMTP server and send it off. Delta can be told if you want it to actually care about all emails you get filing them under the heading “Conversation requests,” or just the ones that started with conversations on Delta in the first place, to avoid in-app clutter.

## Encryption

Messages can be sent end-to-end encrypted as well as in plain text, though Delta will try to encrypt wherever possible. This is done through a standard called Autocrypt, which I will describe like such:

Autocrypt is a layer on PGP, wherein it uses PGP as the base method of email encryption, why would you reinvent the wheel when there’s a perfectly good starting point right there, and adds the setup and configuration on top of that.

### Autocrypt Level 1

In theory, there will be multiple levels of Autocrypt that a client can implement, but right now, we have one: Level 1. How this works is that Autocrypted emails have a Autocrypt header, which looks like this:

Autocrypt: [email protected]; [prefer-encrypt=mutual;] keydata=BASE64


The addr attribute must match the email’s From header, the prefer-encrypt attribute, if specified, will only contain the value mutual (for now), which means that this user would prefer to use encryption wherever possible, and keydata is literally your entire public key block. The entire header cannot exceed 10KiB in size, meaning you should keep your keys relatively small, since a 4096-bit RSA key is already 5KiB. RSA keys are common, but you must support Ed25519 keys for signatures, and Cv25519 for encryption, which are smaller in comparison.

From this, when a Autocrypt-capable MUA receives a message with the Autocrypt header, it can use the information to decide if it should grab the user’s public key from the header, and start encrypting messages sent to them.

There’s also such a thing as a setup message, which is a special multi-part message which has a bit of PGP data on the end, allowing for one MUA to “export” its keys and status into a message, that others may import, allowing for multiple MUAs for a single user to have the same keys and preferences.

### Capable Clients

Besides, well, this one, many clients right now support Autocrypt, including a Thunderbird extension, K-9, Enigmail, (Neo)mutt, Emacs… there’s a fair bit. The one part most fail at is the setup message as described above.