I got banned by WeChat last week for a while for using "unauthorized plugins". They seem to also be adamant about not allowing people to run WeChat on virtual machines.
Seriously, WTF? It's none of your business what device I use and whether it's virtual or not.
I got a cease-and-desist from Facebook many years ago for trying to write a Perl interface to their messenger.
I own and control my devices, damnit. I hate these walled garden messaging apps that seem to actively thwart innovation. All I want is a protocol (which I'm even happy to pay for!) and I will decide how messages present themselves on my end.
Many years ago I used Pidgin to interface to MSN, ICQ, AIM, QQ, Gtalk, Yahoo, Zephyr, and a couple others. It was great -- I had E2E encryption (sorry Pichai and Whatsapp I had E2E encryption on ALL of my messengers before you all decided to wall-garden your apps and then do some stupid PR stunt about E2E encryption years later), automatic human language translation, automatic LaTeX rendering, and a bunch of other features, all of which I don't have now because the messenger apps everyone uses now are anti-innovation. We've taken a huge step backward.
I got a discord account banned recently, and they wouldn't tell me why. My guess is that it has to do with my using a weechat bridge rather than their garbage client. I have to do the same for slack and for signal (which, by the way, is terrible even with signald), because they too have garbage clients. I have a much better experience when just using plain IRC.
It's slow to start, constantly downloads a bazillion updates. Information-wise, it's not very dense. It's hard to customize; doing so requires a bunch of hacky stuff: https://github.com/AryToNeX/Glasscord/wiki/Installation
Using a third-party client is a bannable offense under the terms of service. I hate the little "emoticon" icons that are all over the place. It set itself to auto-start on boot (this behavior may be different on win/mac). I don't like trusting it with my messages. It tries to show what applications users are running at the moment. There have been some improvements, but I still don't trust the security of electron.
These are some of the ones I can remember off the top of my head. Generally, it always seemed like it was both trying to baby me and seem "cool". It's many of the things I hate in modern software in one application. It's a chat app, which should shut up and show me messages, not try to double as a social network. It's also a voice conferencing app, which should shut up and transmit/receive audio, not try to double as a social network.
I know a lot of other people who seem to like it as well; good for y'all. All of this would be much less offensive if it hadn't banned me for opting out of its webshit.
I'm going to assume you ask this question because you're honestly curious about GP's discontent with Discord's interface, so this is NOT directed at you, but ...
One of the things I've often noticed is that people like to shame me for being discontent with e.g. WeChat's interface or Facebook's interface. "What's wrong with it? I think it's great! [... and you're weird]" and that mentality of casting away hacker types who want to invent their own UIs is extremely toxic to creativity and innovation, but it's a pattern I've seen happen very frequently with all of these walled-garden apps. (Again this is not directed at you)
Yes, I totally agree with that being a problem. At the end of the day different UIs satisfy the goals of different people. It's a bit pointless to bash people for picking things that fit their lifestyle.
Pidgin still exists and there are plugins for lots of the modern messaging systems. Please note that OTR is no longer considered safe crypto-wise, there is an unfinished OTRv4 that fixes that.
>Please note that OTR is no longer considered safe crypto-wise...
I could not see any discussion of the deficiencies of OTR in the titles of the OTRv4 sections. Could someone direct me to a reference? This is the first I have heard of this. I thought OTRv4 was all about usability.
> - compared to Signal, it does not snoop your phone number
Great, leaking the user's email address which, more often than not, contains their real name is so much better. /s
Seriously, though, I don't think this comparison accurately reflects the differences between Delta Chat and Signal:
Signal uses your phone number for account lookup but not for addressing participants. Moreover, it uses a feature called Sealed Sender[0] to conceal even the cryptographic address of a message's author. In contrast, Delta Chat leaks the email addresses of the people participating in a [group] conversation[1] (and, thus, their social network) not just to one provider (as in the case of Signal) but to all email providers involved in hosting the conversation, meaning that, as a user, you have to trust not just a single but multiple entities. Meanwhile, Signal doesn't even know how many people there are in a group conversation.
You seem to care about whether the messaging provider knows your phone number / email address... but that simply isn't the attacker model most people have: they want the people they are talking to to not have their real phone number / real email address, and couldn't care less if Telegram or Snapchat or Google or even Facebook knows who they are taking to; essentially, they want a trusted provider to protect them against untrustable contacts, not to speak with their trusted contacts using an untrustable provider. Now, can you solve for both of these problems at the same time? I think so--and maybe Three.ma is exactly that!--but Signal doesn't seem to care, as they have a somewhat strange model of how people chat. The question, then, is mostly about how well the application supports creating unrelated accounts / aliases: what you really want is just some kind of separate user identifier (such as you get with Three.ma, or with services like Wire/Kik); but, barring that (as federation makes that weirdly hard), email addresses are way better than phone numbers, as it is way way easier to get throwaway email addresses--even ones from unrelated hosting companies--than throwaway phone numbers.
> You seem to care about whether the messaging provider knows your phone number / email address... but that simply isn't the attacker model most people have: they want the people they are talking to to not have their real phone number / real email address, and couldn't care less if Telegram or Snapchat or Google or even Facebook knows who they are taking to
I don't disagree but OP was specifically talking about Signal "snooping" one's phone number, so I was talking about a different attack vector.
Besides, to answer all those comments saying that they would set up a separate anonymous email address in heartbeat, we should not forget that the HN crowd is a rather unique group of people. How many of our grandmas would get themselves a new email address just for the purpose of signing up for Signal?
Finally,
> Signal doesn't seem to care
doesn't seem to be true. The Signal developers have been working on switching from phone numbers to usernames as unique identifiers[0] since at least 2019. As they have mentioned multiple times, though, it is a complicated change.
Your links do not demonstrate that they "care", nor do they even show it is "complicated". I have been following the Signal project since well before it was even called Signal, I talk with a lot of Signal advocates at the events where I speak, and I have spent lots of time digging through issue trackers and conference proceedings to get some concept of what goes on in the mind of a Signal developer (particularly Moxie, who has made himself the enemy of decentralized systems and even open source clients): they seem to only be doing this--and lazily to boot--because people are upset about it, not because they believe in the use case; they are extremely opinionated in their specific model of chat and generally insist that using phone numbers was necessary in order for network effect to work (along with commensurate defenses of all of the privacy SNAFUs related to it, some of which they have attempted to address, but half-heartedly). Put another way: you don't spend so many years shitting on an idea and claiming it would be actively harmful to your cause just to eventually say "ok, fine: we're working on it" without any explanation that "we made a mistake and hope the community can forgive our prior misunderstanding here" if you actually "care" about something.
> that simply isn't the attacker model most people have: they want the people they are talking to to not have their real phone number / real email address, and couldn't care less if Telegram or Snapchat or Google or even Facebook knows who they are taking to
Are you sure you're not extrapolating from your needs to that of "most people"?
I don't doubt that there are people for who need anonymous communication (whether just sender-anonymous or sender-anonymous, recipient-pseudonymous). But so far, I've never had the need for it.
Quite the opposite, actually: I wouldn't want to receive anonymous messages on Signal, at least not without opt-in.
No: I am not (in fact, I am really strange: I am a super famous person who has decided to have a single public phone number and email address that he gives to everyone). I think part of the problem here is that you seem to think leaning heavily into the anonymous communication scenario, but that isn't how other people conceptualize wanting to not have their real phone number or email address given to random people: the real play is almost entirely about being pseudonymous, where you might have your name (or a "well-known alias") and a photo of yourself attached to the account... but not a real phone number or email address (which tie your identity together to other systems). This use case is so common that even tech people whom I feel "should know better" opt for solutions like Apple or Facebook login rather than giving away their real email address to a random website!
So, first, to address this: it is frankly extremely rare to have a realistic attacker model that cares about eorher governments or a chosen large corporation having access to your chats, at least "in the West". Like, seriously: sit down and list who you think falls into this category... this is a list which starts with "political dissidents" and continues into some really strange low-likelihood scenarios, as the entire premise surrounds a government or law enforcement agency subpoenaing your messages.
Most of the people I know who are in this category are simply people who want to believe they will one day be targeted by governments for being too dangerous. I can still motivate this software for people, based mostly on scenarios involving bad people getting jobs at large companies to access your information (this is a big issue with Facebook), but even those scenarios barely work against companies like Google (which have good internal information controls). I have gone into this in more detail before (with someone shilling Signal who hilariously ended up just admitting that Signal doesn't work here as it is a "privacy issue").
The ironic thing is that, without also solving the untrusted contact problem, this set barely even includes political dissidents: I have tons of friends who do stuff like coordinate protests, and the #1 realistic concern is that the police--whom I also talk to a lot (I am an elected government official), and I know they do this--have managed to infiltrate their giant group chat and are just watching it all happen and writing down phone numbers. There is a big gap between anonymous and trusted, and it is where most use cases actually happen.
So, on the other side, pretty much every "normal" person constantly meets people with whom they want to communicate without giving away their real phone number / email address. How do I know this? Because that's what most people want to talk with the people whom they are casually dating. This is a big reason why everyone uses Snapchat for almost everything (and Instagram or TikTok for everything else): because it gives you a feeling of control over what people know about you.
Just earlier today I was watching someone on TikTok--in a video about dating communication--say "using Snapchat as the only form of communication during the talking stage is the move: I'm not giving you my phone number... we just met! I would sooner give you a urine sample" (this is an exact quote). The comments mostly agreed with everything she said (and she only had like three supposedly-"unpopular" opinions that were actually quite popular ;P); here are some of the strongest comments about the Snapchat mention.
> Yes! Snapchat! The only way they can’t use one type of social media to find you on other social media
> Yes about the snap vs phone number. I started online dating after a 15 yr relationship and I got a phone stalker that texts me with new numbers
> yeah idk why ppl hate on snap. I prefer it bc they don't have my last name or extra info on me and I can see more what they look like beyond a few pix
Were there people who disagreed with her? Sure, but they were all either advocating for refusing to leave the dating app in the first place (which is itself a trusted provider protecting you from untrustable contacts), were advocating for a different but similar solutions (that still don't involve giving out your phone number), or seriously said "I don't know if I am just old or what"... to which I will note "yes, you are apparently quite old :/".
> Snapchat is dead there are apps like Text+ that create burner numbers...that’s what I use
> Yeah you’re right about this but the Snapchat thing is enlightening as somebody who was an adult before Snapchat lol
> Great, leaking the user's email address which, more often than not, contains their real name is so much better. /s
So, how good is your spam filter for SMS/calls? /s
Personally, I rather give my mailaddress than my phone number. I can set up a new address rather quick. I cannot switch my phone number that effortless.
Maybe worth noting that spam calls/SMS are primarily a problem in the US.
In the European countries that I've had phone numbers in, these basically don't exist, and my phone number has been part of several data breaches. (That said, I am curious if this is a problem occurring in almost all or almost no other countries!)
As far as I understand, these problems are also in the process of being fixed in the US via caller ID authentication (to enable carrier-level filtering), which seems like the right approach: In the long term, it's more or less futile to keep a phone number out of data breaches or advertiser databases.
Would much rather use an email vs a phone number, 100%. Most email has good spam blocking compared to phone numbers. And you can hold multiple addresses without paying more per month on a cell plan.
About six years ago, I built a similar app for an old long-distance (many timezones away) girlfriend and I to send voice messages to eachother. (called 'duovox' - not released to public). It created recordings and other metadata/attachments and simply zipped them up with a password and custom file extension and sent via email.
The app was naturally registered with the custom file extension, so that clicking the email attachment in the Mail app would simply open the app and the message it contained.
Very simple. Very effective. And using an existing and secure (one would hope!) transport: email.
That's very nice, I'm sure people would be interested in your app !
> secure (one would hope!) transport: email.
The best strategy is to assume it is not (because it is not) and implement security at the end, like you did, because you have a specific usage that may not be generalized. End-to-end principle.
I'm using it for 1-on-1 chats in my family and the application makes you forget that it's smtp/imap/pgp underneath. It feels like a WA clone. Will it disclose past message contents on private key leak? yes.
If you fetch mails via pop3 be aware, you'll move them away before DeltaChat can move them into its own folder via IMAP to build its message threads. If you're doing IMAP only you'll see the messages with your mailclient unless moved. Maybe consider using a dedicated email-alias or account. If the receiving SMTP on submission doesn't strip your connecting IP Address in the Received headers this is quiet a lot on the wire that DC can't do anything about and where you would rely on transport encryption.
It made a point what a thoughtful chat-view, pgp-using email client can do, so I still recommend to give it a try.
I have only tested gmail to gmail and it was fairly quick. Under a second in my experience. Providers will differ but email is usually very fast these days.
I recently blogged about it [1] and think Delta Chat is the messenger we should migrate to.
Email is decentralized (at least when not everybody is using Gmail) and isn't a silo like WhatsApp, Signal, Telegram and Threema. Because what happens when Signal goes bad? Everyone has to move again...
I also don't like that Signal relies on phone numbers or a QR code from a phone to log in. Phone numbers are traceable to identities. They really should have used usernames or e-mail addresses.
Also, Signal's desktop app shouldn't require a stupid phone app to enable it. I have a big powerful setup on my desk and you're asking me to go around my house looking for a silly 6" device to give it permission to log in? That's backwards. It should be the other way around if anything.
Yes. Phone numbers are linked to a physical device (a SIM card or similar) or a contract (with a provider). An email does not need to contain a real name, and I'd say it's much easier for me to get a email with a temporary identity than it is to get a phone number for the same.
My only gripe with delta chat is that the metadata most email stores keep per email message is measured in kilobytes (sometimes tens of them). View-source is very enlightening. For email messages which are often 1K-200K themselves with attachments, and somtimes > 10MB, I guess it's acceptable.
For one line "How about lunch today?" messages, it just hurts my engineer bones to use Delta-Chat on a regular email server.
Yes, i'd guess a simple message might start at around 1kB and in a chat application you probably never exceed 2kB.
Considering the massive amount of data i can store on even the cheapest smart phone, the available bandwidth even under bad conditions,
i'd say, that's a totally acceptable size.
It could be less for sure, but it's not bad.
And it's plain text, so storage is not even a problem, it's easily compressed!
Now, don't let me compare 1kB data download to visiting a website and all the crapload i download for the simplest webpage nowadays...
I agree, in the grand scheme of everything internet/web, it’s not even a rounding error. And yet, the 2000% overhead is viscerally bothering me.
I’m not even saying “there must be a better way” - it is quite possible that there isn’t given the politics involved and the incumbents. Delta is usable, today, with everyone; no need for buy in from your addressees.
Yep. Actually, i've used it now with some friends and it works very well.
Part of them is only using email, 2 are using the apps.
Two quirks:
1. Of course your mail provider needs to have IMAP enabled (some corporate outlook/exchange installations do not).
2. It could be a problem if you mail provider has a limit on maximum mails per day. I've not experienced that problem, but still..
> think Delta Chat is the messenger we should migrate to.
Not really.
WhatsApp and Signal allow you to place audio and video calls, Delta Chat (by design) can't. And that's critical for folks who have families and friends in other countries.
This highlights the fact that there are too many protocols that are essentially reinventing the wheel. The problem isn't necessarily too many clients, but too many transport agents.
In a way, they're almost all reincarnations of what email, IRC or XMPP could already do, with a few makeup changes, often designed to lock-in the user and consequently fragment the user base.
What we need is perhaps more clients, with different interfaces but using the proven underlying protocols and implementing new features client side. Delta Chat, making use of email, does this, with the added bonus of SMTP's natural decentralisation and openness.
While I agree, I think using e-mail as the base is an attempt to compensate for the network effect. While XMPP is clearly superior as a chat protocol, it lacks a broad user-base.
With e-mail you can even chat with people who don't have the chat app. Maybe we need an XMPP e-mail bridge ;-)
Btw, when I click "open source" link on delta chat website, I may be not the only one expecting to be taken to the source repository instead of definition of what open source is. I found the actual link, just a suggestion.
Maybe we need email over the matrix protocol. Decentralized and using an already existing modern open protocol. The problem is that email has too much inertia.
Why do you think that? What would yet another protocol nobody uses bring to the table, smtp and imap don't? It's reliable, stable, decentralized and can be used securely.
Email is not decentralized. It relies on the central authority of domain registries. You theoretically can send emails in a more P2P way by using IP addresses, but then you lose the "reliable" and "stable" parts for many users.
It arguably can't be used securely. One of the prominent security researchers on HN actually wrote an article that promising E2EE for email is more harmful than helpful because it gives a false sense of security.
And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it.
In short, email security is a bolt-on, and it will never be part of the standard itself.
> Email is not decentralized. It relies on the central authority of domain registries.
By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS. In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead.[0]
> And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it.
The same is true of any system which is proposed as an alternative to email. Admittedly it will be difficult for a UI to convey the security properties of messages when you are interacting with users whose email clients don't support the recommended extensions, but there is always the risk that a recipient will copy-paste the plaintext of your securely sent message into an unsecured channel.
> By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS.
That analogy makes no sense.
Email is centralized because every time I send an email, I'm doing a DNS lookup.
By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records.
> In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead.
Yes, but then why are you using email at all? The whole point of email has been that it uses the domain registry as a routing mechanism.
It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore.
> The same is true of any system which is proposed as an alternative to email.
I don't think you understand this topic.
There are protocols with encryption schemes built into them. Email is not one of those. From the article I linked:
> "A number of standards exist for end-to-end email encryption, but so far, none have reached critical mass with vendors. Take Symantec. It supports both the S/MIME and PGP/MIME encryption, says Symantec's Kriese. That doesn't mean that the system easily interoperates with those of other vendors."
That is in contrast to Signal Protocol[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol.
> By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records.
I don't disagree with your general premise but Signal is not decentralised at all, and I'm pretty sure they don't hardcode the Signal API server IPs into their binaries so you still depend on DNS (plus their centralised servers).
> Email is centralized because every time I send an email, I'm doing a DNS lookup.
And every time the Signal app connects to its centralized servers, you're doing a DNS lookup too.
> By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records.
But Signal isn't a true P2P solution. As your linked description of the Signal Protocol states:
"It does not provide anonymity preservation and requires servers for the relaying of messages and storing of public key material."
> It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore.
If you're using HTTP and HTML and hyperlinks and URIs, then you are using the WWW. I suppose you could say that .onion addresses are the Dark Web, but saying they are not part of the web is pointless gatekeeping, like saying that HTTPS sites aren't part of the web because some web clients don't support TLS.
> I don't think you understand this topic.
That makes two of us then.
> There are protocols with encryption schemes built into them. Email is not one of those.
Again, this is an unhelpful observation. HTTP is a protocol that doesn't have encryption schemes built into it, but we didn't decide to throw it away in order to make the web secure. Similarly we don't need to throw away all existing email protocols and clients in order to have secure messaging.
> That is in contrast to Signal Protocol[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol.
No, email is exactly the same as the Signal Protocol in that regard, since all email clients' E2EE are compatible with each other as long as they're using the same (encryption) protocol. The fact that an SMTP server doesn't reject an email that isn't PGP encrypted is a feature, not a bug.
Metadata being available to the server isn't ideal, but a hub and spoke architecture where the hub has no knowledge of which spokes are talking is, if not impossible, then at least very hard, surely?
I feel like the first step is consistent encryption, then figuring out hiding meta data. Proxys that strip meta + delay emails to fuzz that might be a solution.
Agreed. In fact, if consistent E2E encryption could be assumed, then the proxies could be implemented as simply a dedicated address on each server.
For example, suppose alice@example wants to send an encrypted message to bob@server. Alice's client could wrap the message to Bob as an encrypted payload to a message addressed to switchboard@server, so that her provider doesn't learn Bob's address, and her provider could replace her metadata with switchboard@example before sending it to Bob's, so that it doesn't learn Alice's address.
Like a lot of open source projects this is a great idea with a lot of potential that's somewhat let down by poor design and UX, we really need more professional designers contributing to open source!
eg: How do you start a new chat – the primary function of this app? It's hidden in the "..." menu that looks like it contains the settings for the existing example chat.
in android you can start a chat just pressing in the + button, and in desktop, just typing the email address in the search bar should show a button to start a chat with that contact
I've been using this with one single solitary friend for about a year. It works really well and we both love it.
What has bothered potential adoptees is the idea it needs their email account credentials. People who don't think it is super cool already don't seem willing to adopt it. It would be nice if that changed.
Well, the account credentials would stay in the local client wouldn't they? There is no hosted web version of this (yet!) and no central server so there is no one to leak credentials to. The only receiver of the credentials would be your email provider, and you are already sending them that in your normal email client.
Big problem here is using existing email address with other sensitive data in the inbox.
Need to tie up with an email provider and give people an email address on signup. Also needs intelligent grouping of said email with someone's gmail on both the invite/invitee side.
Also, there's another app being worked on called Stamp is a similar messaging system as well, but uses an HTTP based transport instead of SMTP.
The things that set Stamp apart is that is has:
* Spam mitigation in the base layer so relay operators don't need to deal with it
* An indirect address lookup system so you don't get tied to one Stamp provider.
* No attachment to PII to start accounts. (No phone number or email required)
Considering the way delta chat chat works; that doesn’t matter much. Approximately nobody has that client installed. And SMTP is not ideal for these things.
Doesn't matter. The whole point of Delta Chat is that the other parties in the chat don't have to use it or even know about its existence. You lose encryption, but at least you can message those people. It looks just like any other email message.
I tried this out last week, hoping it would be good enough for me to cancel my plan of setting up a matrix server.
It's a nice idea, but I likely will not continue using it or try to sell anyone I know on using it because it doesn't let me share conversations between my different devices (like my smartphone and my laptop). If someone replies to a chat I send from my phone, I want to see the reply (and the whole thread, really) on every device I have Delta Chat installed on.
On startup, the Android app asked for my email credentials. There's no way I'm going to trust anyone aside from the mail provider with those credentials.
Use another address for this? I think the idea is to leverage email as opposed to depending on a central provider. Doesn't mean you have to use your main email address for it to function.
it depends if the receiver has an autocrypt-capable email client like k9mail, etc. it doesn't have anything to do with IMAP on the receiving end, but Delta Chat currently only supports IMAP so the sender does need a server with IMAP support to use Delta Chat, but the receivers don't even need to have Delta Chat
Uh, I don't think IMAP is generally blocked on iOS? Anyway, end-to-end encryption seems to depend on the email provider being able to support IMAP. So Hey.com is out but gmail can work if you enable IMAP support for example.
Also, end-to-end-encryption is not related directly to IMAP.
The issue with Hey/Protonmail/Tutanota is that they do not offer IMAP- or other standard-protocol-support - so you can just not log in with Delta Chat (nor with any other e-mail-client) to your Hey/Protonmail/Tutanota account.
If you log in to deltachat say with Posteo, you can write to other Hey/Protonmail/Tutanota accounts - but as the recipient cannot use Delta or other Autocrypt capable clients (Enigmail, K9), things cannot be encrypted. If Hey/Protonmail/Tutanota would support Autocrypt in their webclients, of course, this can change.
Email is the only practical hope to having a federated communication over internet. Unfortunately gmail and outlook has disproportionate share of email communication which is a threat to the open standards. It is possible to built a federated communication but it has to be built from scratch which is very hard.
Another IMO slightly more promising alternative is COI, the Chat Over IMAP protocol. It aims to extend IMAP servers while staying compatible with normal ones.
https://github.com/coi-dev/ox-coi
Unfortunately, the development is on hold (?). I really like how they seem to plan on integrating normal email client functionality into it, something Delta Chat is also missing.
I have tried both and would not recommend either to non-technical users at all, but I think that is not the primary audience yet anyway.
> It aims to extend IMAP servers while staying compatible with normal ones... I really like how they seem to plan on integrating normal email client functionality into it, something Delta Chat is also missing.
I don't see anywhere in DeltaChat's spec [0] anywhere it breaks compatibility with normal IMAP.
So long as your email client can use autocrypt standard (plugins exist for Outlook, Thunderbird, etc.), then you can make use of DeltaChat emails as normal emails.
Yes you can use DeltaChat for "normal" emails as well, but I was referring to the usability of it. I do not think many would ever ditch, say, Gmail in favor of Delta, as long as conventional emails are prevailing. The main problem here is that an email thread is not necessarily limited to a fixed group of people. With every answer, the audience might change, with different ways to address recipients (direct, CC, BCC; Merging different threads via FWD, manually editing quoted messages). It's hard to apply these principles to group chats, which is why Delta Chat simply doesn't.
DeltaChat isn't limited to a fixed group of people either? [1] And supports forwarding just fine. [2]
I think the useability problem is just that webmail as a whole has generally been stripped of features. If Gmail wasn't as constrained a client, you'd be able to do everything without caring if you had a "DeltaChat" client. It isn't an email-or-DeltaChat question. Both interact fine.
But the clients people are currently using go out of their way to make it harder/impossible to do simple things.
I read the specification, but I am really not sure I understand you here.
Say person A sends an email to B with CC set to C.
C then needs to reply to this email, but send the reply to D, with A as BCC and E as CC. From what I remember, such fine-grained mail sending configuration is not possible with DeltaChat because it does not fit common group chat mechanics.
> I think the useability problem is just that webmail as a whole has generally been stripped of features.
Looks like a very cool project. Slightly off topic question, is there a reason the email providers like FastMail or Protonmail don't just include XMPP as part of their bundle?
Love this concept. I’d really love to see this taken to the next level to create an email powered social network. You’d really just need a client that could parse the data.
I've kept pointing out for years that e-mail can be used for this. You can decompose e.g. even something like Twitter into mail servers + forwarding + mailing-lists. Back in 2001 I was part of using Qmail as a distributed message broker. We built a domain name registry with live updates where messages between backend components were sent as e-mails. It worked very well, and you get the ability to federate for free.
It's not instant, of course it relies on the smtp servers in between, but for a Gmail to Gmail test it was nearly instant, for my own mail relay to Gmail it was probably 10 seconds delay which is fine for me.
what’s not clear from the FAQ is whether it turns ALL your email into chat messages or only a subset, e.g. all email with a special header or tag in the subject.
I’m assuming it piggybacks on your normal email address as opposed to making you create a dedicated one for chat.
The default mode of Delta Chats "email interaction" setting is "show only chat messages". This includes replies to messages you sent out from Delta Chat, even if the reply came from another email app or a webmail interface. So you can chat with anyone who you know the email address from.
If you set email interaction to "all" then you see regular email appearing as a "contact request" if you haven't already accepted the sender. In current development repos there is already support for mailing lists, and for html-mail. With this and a few other improvements, delta chat can be used as an e-mail client in more situations.
So it uses the reply chain as identified in the email header.
It might be useful to actually define a new email header field (Or define a new value to put into an existing field), thereby making this an open protocol.
It's just an email client, acting on the delta chat emails (and moving them to a delta.chat IMAP folder).
It works transparently with a fallback that the receiver can still just reply in a normal email client.
It's how the whole messaging drama. Should be resolved and it's using decentralized infrastructure that is already there and reliable.
I have created some bots (mainly for Spanish speakers, Delta Chat ia used a lot in Cuba), bots to bridge with Mastodon so you can chat in private with users there or toot etc., bots to play games with friends etc. even to get xkcd comics etc
Compare to most IM systems Delta Chat is:
- easier to set up: you already have an email
- equally private: most IM systems leak metadata anyways. A global observer can infer your peers.
- compared to Signal, it does not snoop your phone number
- decentralized
- cheaper to run 1: managing mailservers is cheaper than managing both mailservers and IM servers
- cheaper to run 2: mailservers evolved for decades and are now pretty efficient, especially compared to most IM servers