Item — HN Reader

I like this idea.

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.

4 comments

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

> "using ICE (from WebRTC)"

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.