I wonder how latency impacts the "live chatting" experience.
Email protocols have specific impediments on egress and ingress: on one end to ensure that a sender isn't sending out spam (challenges, proof of work, etc), and on the other end to ensure the recipient isn't getting spam/malware/etc.
Add to that SPF, DKIM, DMARC processing along the way...
It's not uncommon to have conversations with a 3rd party along the lines of...
- Did you get my email? I just sent it a minute ago.
- No not yet. It'll come through.
...with this taking sometimes up to a minute.
We accept a certain latency with email communications, but I'm unsure that will offer a good user experience for interactive chat.
Emails and SMS message seem to have similar 'delivery time ranges' to me. I send this message, and it will arrive somewhere between pseudo-instantly and take a minute.
With my conversations, it is often a minute to get users to respond if they are working on multiple IM conversations and need to finish their thought, or are otherwise doing something meaningful outside of cyberspace anyways, so the delivery time is of less importance.
Boundless speculation: whatever the difference in instant delivery of a message and the human user noting/changing gears to address it and delivery taking (in your worse case example) 1 minute, just in time for the human user to be 'ready' to receive another message is too small to be meaningful for non-techie users.
Anecdata for those users in my contacts list that are techies: after about 5 IMs, further chatting seems to organically migrate to a phone call or desktop client session (Slack/Volt/Skype/Discord) rather than the approx 3 messages every 5 minutes my cursory glance at message times in Signal shows for the non-techie users.
While not directly comparable, text messages do often see some lag (especially when also considering something like MMS) so it could be said that there is some tolerance for latency.
A more distinctive difference could be the lack of rich media functionalities (sharing GIFs, stickers, etc) that have seen popularity in most messenger apps. This seems to be a middle ground between traditional email (professional) and mobile chat (casual) which could see some use but I can't imagine how user adoption would follow
I further like the idea in that it can expand as a product in several directions.
Eg. Also do a dns txt lookup for "chat" which can have a specialised server that the recipient is in control of (or subscribes to). It could bypass the legacy issues of email, but still provide a fallback in case the recipient uses email only.
One solution is to upgrade the IMAP connection to a direct TCP one, using ICE (from WebRTC). This was part of a project I helped work on: https://github.com/tkoft/GoingPostal
Would this leak the ip addy of the sender to the receiver and people along the wires?
Each time I looked into webrtc and websockets I think, I noticed the need for a stun/turn server in order to mask sender ip addys, but don't know enough about all that atm.
I love the concept of using existing protocols, but the implementation here creates a mismatch in expectation between the communicating users. I may be 'chatting' with someone that doesn't use Delta, and they just see short emails that don't conform to social norms for email content. Then they decide to cc a bunch of people into the conversation. Now what? The part of chat that I would like to see solved is end-to-end encryption for all, and interoperability between the existing protocols. This is just a shitty email client.
I have been hoping to see some new email clients that would auto load a feed of contacts and make the views appear similar to fbok / buddypress - have it auto load next emails and any images (if from contacts) - so an endless scroll could be - and option to reply to each post / feed item / email..
I think making the ux similar to what people are familiar with / similar to the most popular options (maybe like twitter and wechat too) -
we'd get a chance of getting people away from the walled gardens -
I'd love for new apps to not only provide that kind of ux, but also give options to send comments (and also recieve in the client and display) via other platforms like signal, matrix, activity pub, all the bridges..
It would need icons next to messages to show which portal they are coming from / going to, is it encrypted, etc.
I for one would very much like to see new viewing options for some shitty email clients.
I appreciate the home page of this delta chat is showing screen views for desktop, android, iPhone - wish all products did this.
This is cool, but probably not super practical. Gmail for example limits the number of messages you can send per day pretty strictly, so using it for messages would probably be unwise. Busy chats could probably eat the quota.
I see where you are coming from, but I disagree re: the practicality being limited by message sending limits.
Sister comment says Gmail allows 500 messages to be sent per day. 500 messages/day sent in napkin math = ~20 messages/hour. Per https://www.textrequest.com/blog/how-many-texts-people-send-... , American adults sent 128 or less texts per day in 2018. You can send triple that number & still not hit the Gmail limit.
For other email providers, the limit is even higher. I checked for Fastmail's equivalent daily message limits, and it enables 4,000 or more per day.
For me personally, if I'm going to be doing over ~ 50 sent messages in one day, I'm going to ditch the mobile device and move to a desktop as I prefer a full-size Model M keyboard to touchscreens wherever possible. Most of my awake time is at work or home, where desktops abound.
I don't want to speak for you or others' preferences on this, as admittedly I don't text nearly as much as most of my peers, but I suspect others also at some point reach for a desktop UI, whether native (Signal), electron (Slack), or web-based (FB Messenger / WhatsApp / pick yer poison) for in-depth, non-mobile conversations.
Based on some quick ducking (as opposed to googling), you are correct, 100-200 does appear to be the daily SMTP relay limit. I wonder if Google would raise that to, say, 500-1000 if Delta.chat started having a sizeable user market share?
My first instinct is it would likely be a hard fight. The limit is obviously a matter of preventing abuse, and changing it might change the dynamics for malicious parties or otherwise make mitigating abuse harder. This is probably an issue for most free email providers.
This is still a conceptually cool idea for many reasons, but for this and other practical reasons it may end up being preferable to use it with another email provider. Especially since I personally think JMAP is intriguing and this might be useful for Delta Chat.
I do worry that without good support for Google accounts and maybe even some other major free email providers (important: I really don't know,) Delta chat may face practical issues with gaining critical mass.
(Just for full disclosure and good practice, I am an employee at Google, but I do not work on Gmail and I'm speaking strictly as a user.)
I tend to agree with your point as shown. Every inch given to 'worthy causes' like Delta.chat can come with the cost of unscrupulous types like scammers/spammers.
I don't really expect Gmail to bend over backwards to accommodate this. Like you though, I worry that this could inhibit Delta.chat getting enough critical mass.
On the other hand, if delta.chat starts to collect some critical mass, Gmail would probably want to avoid the generation of a pro-tip like "don't use Gmail, they're too restrictive, use Fastmail/iCloud/Outlook instead" because that could cost market share...or they can increase that limit a bit and keep the status quo going well.
Full disclosure -> I am not a Google employee, but thank you for providing the caveat for your comment! Those tend to help comments be read in a more meaningful light, speaking for myself at least :D
"Sizeable" as in bigger than Google? Yeah, I guess so. Otherwise, I don't think it would care or it would make changes to Gmail's interface to try to make Delta.chat pointless for their Gmail users.
It's 500 recipients per day. That seems adequately high.
I mean, if you have a chat with 100 participants, you're limited to sending 5 messages that day, but having such big chat rooms is not really that common, is it? And if you really have that need you can get cheap account at e.g. Fastmail and increase that to 4,000 or 8,000 recipients per day.
Reading their docs, it seems like this uses Trust-on-first-use key exchange, so if there's an attacker passively observing the network at that point, they can MITM all future communications.
Also, the Autocrypt Level 1 spec, which this seems to implement, appears to be based on PGP, with the following caveat: "Sometimes Autocrypt recommends to send cleartext mail even though encryption appears technically possible."
Yes, if the attacker is strictly passive, tofu with public key should be fine. That the attacker is strictly passive is a pretty strong assumption though!
But email relies on free and open source standards while instant messaging is a walled garden that relies on closed protocols by some shady corporations that sell your data.
XMPP and Matrix (and arguably ActivityPub) are open specifications for IM, each with multiple interoperable implementations. (I'm counting mxhsd as a 2nd implementation of a Matrix server; I accept that it isn't mature yet.)
I can make quick replies to an email from a notification, but I can't write a long email in a chat client. And my email client is more battery efficient than Delta Chat. (It's been on F-Droid a while, I've tried to use it and want to like the concept, but it ultimately shows out as pointless.)
There's no reason to run two email clients on my phone to receive the same messages.
You'd think this would be covered in the FAQ. Maybe their client deletes the email once it is received by the app but then how do you use multiple clients at once (and so forth).
I think it's fascinating that you don't understand what is meant by that sentence. I'm a native german speaker and would probably not make that mistake but I can't imagine somebody not understanding the combination of the words "own" and "servers".
It sounds like CoI took (tempted to say hijacked) a subset of Delta Chat (protocol subset), something that was already shipping and working, and merely rebranded it.
I think this is the future of instant messaging. If we all would change instantly to delta.chat, whatsapp et al would go bankrupt and we would not lose a bit of security. At the moment everybody is fine with handing out their most private information to some huge corporations which already told us that we are dumb fucks. But maybe mankind deserves this.
I know that naming things is hard but... the chances this isn't mistaken for being somehow related to delta airlines is nearly 0. The fact that this chat has nothing to do with delta (i.e. difference calculation) but seems to just be using delta to say "We're different" seems like an atrocious business decision.
I wonder how latency impacts the "live chatting" experience.
Email protocols have specific impediments on egress and ingress: on one end to ensure that a sender isn't sending out spam (challenges, proof of work, etc), and on the other end to ensure the recipient isn't getting spam/malware/etc.
Add to that SPF, DKIM, DMARC processing along the way...
It's not uncommon to have conversations with a 3rd party along the lines of...
- Did you get my email? I just sent it a minute ago.
- No not yet. It'll come through.
...with this taking sometimes up to a minute.
We accept a certain latency with email communications, but I'm unsure that will offer a good user experience for interactive chat.