Which communication protocol or open standard in software do you wish was more common or used more?
Whether you're really passionate about RPC, MQTT, Matrix or wayland, tell us more about the protocols or open standards you have strong opinions on!
You're viewing a single thread.
I wish people used email for chat more. SMTP is actually a pretty great protocol for real time communication. People think of it as this old slow protocol, but that’s mostly because the big email providers make it slow. Gmail, by default, waits ten seconds before it even tries to send your message to the recipient’s server. And even then, most of them do a ridiculous amount of processing on your messages that it usually takes several seconds from the time it receives a message to the time it shows up in your account.
There’s a project called Delta Chat that makes email look and act like a chat app. If you have a competent email service, I think it’s better than texting. It doesn’t stomp on the images you send like SMS and Facebook do, everyone has it unlike all the proprietary services, and you can run your own server for it that interacts with everyone else’s servers.
Unfortunately, Google, Microsoft, etc all block you if you try to run your own server “to protect against spam”. Really, I’m convinced that’s just anticompetitive behavior. The fewer players are allowed to enter the email market, the less competition Gmail and Outlook will have.
As much as I like ProtonMail too, unfortunately their encryption models prevents it from working with Delta Chat. I’d love to see Proton make a compatible chat app that works with their service.
I made an email service called Port87 that I’m working on making compatible with Delta chat too. I’d love to see people using email the way it was originally meant to be used, to talk to each other, without being controlled by big businesses.
The delay is there because email has no deletion support.
And a host of other shortcomings.
I'd rather we replaced email with matrix
If you’re relying on the remote server to delete something, you can’t trust it no matter what protocol you’re using.
For a regular email, the chance to undo might be fine, but for real time communication, it’s just an unnecessary road block.
Maybe if it was optional per recipient, or per conversation, or better yet, depending on the presence of a header, it might be fine. Gmail only supports all-on or all-off.
If you’re relying on the remote server to delete something, you can’t trust it no matter what protocol you’re using.
I mean yeah I wouldn't bet my life on it, but for the 99% of regular communication it's fine. That's no reason to not have it in the protocol and muck around with 10 second delays instead.
Oh, another awesome thing about email is that you can ensure that your address is always yours, even if you use an email service provider like Gmail. Any provider that supports custom domains will allow you to use your own domain for your address, then if you want to change your provider, you keep your address. So, since I own hperrin.com, I can use the address me@hperrin.com, and I know it’ll always be mine as long as I pay for that domain.
This is a much better model than anything else. Even on the fediverse, you can’t have your own address unless you run your own instance.
If your email service provider goes out of business or gets sold off (skiff.com, anyone?), as long as you’re on your own custom domain, your address is still yours.
I’m working on custom domains for Port87. It’s definitely a feature I think every email provider should offer.
Yes, I shifted to my own domain after my default ISP of 20 years decided that email was just too hard, you know? They didn't outright say it, they just started batch processing emails so that I'd get all my daily emails at around 2 am the next day. Super handy for time limited password reset emails!
A few hours reading a guide and setting up a $5/mo linode email server with SPF and dmarc, a few more hours transferring 20 years of IMAP mail from my old account to a folder, and a month or so of changing a few site contact emails over each day when they emailed something to my old account, and now I've got an email server on my own domain that is 10 times faster at sending/receiving mail than my old ISP ever was.
And now I can have amazon@mydomain.com and career@mydomain.com and random other disposable addresses so that when they are inevitably sold off for the $$$ I can just dump them and maintain a spam free inbox.
SMTP is actually a pretty great protocol for real time communication.
remembers greylisting is a common thing
Yes, I mentioned that. That’s not a protocol issue, that’s a big business controls everything issue.
greylisting will typically only be applied to people who you haven't interacted before, so I don't think it is a big deal. It would be similar to how many major chat apps hide away suspicious messages from new people in some "invites" section that is often hidden by default.
SMTP is a terrible protocol. Text based for sending effectively binary data with complex header wrapping and "generate a random delimiter" framing. We really need a HTTP/2 of SMTP.
That being said I agree that it exists and works. The biggest blocker to more IM-style communication is largely the UI and user expectations. I have no problem having quick back-and-forths over email but most people don't expect it.
Fair enough. Sending binary data over SMTP adds a lot of overhead, because it all has to be encoded. We should fix that.
Honestly my biggest complaint is header wrapping. Technically you need to wrap lines at 998 bytes (not that any reasonable server actually cares). But in order to wrap a header you need to add spaces (because you can only break a line after whitespace). But where spaces are unimportant depends on each specific header. So you need to have custom wrapping rules for each header.
In practice no one does this. They just hope that headers naturally have spaces or break them in random locations (corrupting them) because the protocol was too stupid.
Binary protocols are just so much simpler. Give the length, then the data. Problem solved. Maybe we could even use a standard format for structured headers. But that would be harder to do while maintaining backwards compatibility.