> We really do have quite a crisis of non-interoperability
Interoperability in communication software is impossible. I know this will upset a lot of people here but its just what we have seen time and time again.
Interoperable and standard software can not innovate because it is impossible to innovate since you need all vendors to agree and move in the same direction as you. Look at how ircv3 went. They promised the absolute bare minimum change to make irc slightly more modern and they weren't able to pull it off in time.
Discord could not be interoperable with other systems because most of its features did not exist at the time it added them. Interoperability means catering to the lowest common denominator of feature sets.
As discord has shown, siloed platforms are not the end, people will move to a new platform if it is clearly better. Discord was much much better than the rest so everyone moved. If someone else makes something much much better again they will move again.
> Interoperability in communication software is impossible
emails have been interoperable since the beginning of time!
It's only impossible because the business models formed after the explosion of the internet required that they own the platform for profit. And doing so requires that other platforms not intrude. Hence, the failure of interoperability.
Which is why email is an absolute nightmare and missing so many features and takes so long to implement the most basic security and privacy. Outside of business use, email has become the newsletter and password reset center because it doesn't work well enough and hasn't kept up.
The IMAP protocol is a known dumpster fire but getting jmap implemented over every email client and server is basically impossible. Gmail avoids this by just implementing their own proprietary protocol which only works with gmail and the web ui/apps.
> email has become the newsletter and password reset center because it doesn't work well enough
Have you considered that it’s the password reset center because it’s the only thing that works well enough?
Anything completely proprietary is a joke for security from a business continuity perspective. It’s the same reason serious companies don’t depend on “sign in with Facebook” as their only login method.
Well that’s a clause doing a lot of work. I guess email could have been the permanent contact repository a la Facebook if it had been easier for people to own their own addresses
Emails aren't encrypted, because there is no good way to manage trust between users at this point. PGP exists, but it's key management sucks in many ways. But look at a lot of large corporations where the trust can be bound to one service and encryption will be just one click away. S/MIME is a widely adopted standard (https://en.wikipedia.org/wiki/S/MIME) in email and works well.
There's no good way to manage trust between users because the services have to be interoperable. Look at messaging services like Telegram or Signal; end-to-end encryption is easy because they're single entities who decide how all messages are sent and received on their platforms.
I don't think communication services themselves have to be interpretable to manage trust correctly. See PGP used in email, git, package signing, etc. - completely unrelated actions, same trust network.
Not an expert in this, but if I can access any website using HTTPS, so should be possible for email? Do we have any technical blocker or is it simply that biggest players don't want it?
Email does use TLS for encryption to the server but once it hits the server (usually owned by a mega corp like google) it gets decrypted so they can read it.
Email encryption is different because HTTPS certifies that you are connected to the owner of that domain name. How do I certify to you that the email you just received came from me and not someone pretending to be me?
The only bullet proof secure way is if I visit you in person and hand you a copy of my public key and then you use that key to verify my emails. We have had tools to do this with email for over a decade but they are so inconvenient that no one uses it outside of a few privacy nuts.
I use PGP quite often. And I know how hard it is and how much it lacks.
But I'm no 'privacy nut'.
A legitimate easy and underused option is how kraken employs it. I've uploaded my public key. They now send all transactional, security and other mail signed and encrypted.
This is a solid solution to phishing.
The only part 'missing' is how I get my pub key on my kraken account. For me it was an export+copy+paste. But it should probably as easy as an OAUTH alike flow between kraken and my mailprovider. 'Kraken wants to import your public key to sign and encrypt it's emails to you'. An UI thing.
When you access any website using HTTPS the parties involved are You and the Webserver, and the data is encrypted in transit over the open internet. When you request a page, the webserver needs to know what page you request in plain text, so it makes sense for the webserver to have access to the request. With email, the parties who want to communicate are (e.g.) You and Me, and the parties involved are (You, Your company email server) and (Your company's email relay server, My company's spam-filter and DR email clone server), (that and My company's email server) and (My company's email server, Me).
There isn't anything quite like the Browser - Webserver simple connection to encrypt. I would like my connection encrypted to my mailserver using SMTP/POP3/IMAP/HTTP + TLS, which it can be. I would like my email server to talk to your email server using TLS which it can do, but isn't guaranteed, there are several approaches to it (STARTTLS and others). I would like incoming mail to be spam-filtered which means a service that can read the content. My company would like incoming email to be malware and phishing filtered, which means accessing the content. My company would like outgoing email to be signatured and branded, same again. My company requires email to be archived for legal reasons and cloned off-site for DR reasons. The design of SMTP involves store-and-forward, failover and fallback options, multiple MX records, so there's not a trivial path email always takes from sender to recipient. Attackers will try to intercept SSL connections and force fallback to plain text SMTP and people would rather email arrives than doesn't arrive. Tons of companies are using ancient not-updated network equipment which proxies and edits SMTP traffic as it goes through. Coworkers would like Webmail which almost necessarily requires the server having access to unencrypted email to show it to you in a browser.
Trying to put some kind of "secure" on top of that pile of entrenched systems is much harder than saying "the biggest players don't want it", what would it be, which layers would it go in, which sides would manage it, how would it interact, who would standardise on it, how much bother is it for users and for people who forgot their password? The main approach is to public/private key outside email and send encrypted blobs to each other, which is full of key management problems, or a service which intercepts email and pulls the text out and sends on a HTTPS link and a blank "someone sent you an encrypted message. Sign up and login to view it" which sucks, but is a lot more practical and does actually work.
The way I generally imagine interoperability with larger and more complex applications is that providers can implement their own extensions and optional features, but that the most basic data elements are generally isomorphic. Would I expect Discord server permissions to be a shared protocol with ease, perhaps not. But every chat app we use has the same basic fields for a message such as 'id', 'timestamp', and 'text'.
Our entire ecosystem under the chat application is based upon interoperability, from Ethernet to IP to TCP to HTTP to even HTML (note how you use a single web browser to use all of your favorite websites!), so I don't want to be too quick to rule out that it's impossible just because it is difficult.
I would, however, agree that the incentives for it rarely exist. But with proper incentives, I'd say we could achieve some pretty amazing protocols for a lot of modern use cases.
The problem is, this kind of thing becomes annoying for users very quickly. When you use Discord, you expect that everyone has all of the features available and that moderation tools work properly everywhere. Lets say your friend is using telegram which is bridged to discord, now you want to invite them to a private group in the discord server, oh but you can't because telegram doesn't support discord roles.
And then on telegram you try to open an encrypted chat with someone on IRC, but their irc client doesn't support that.
Users don't care about talking to people cross platform as much as they care about everything working properly. Its easy enough to have 3 messaging apps on your phone.
You can use OTR [1] with some IRC clients to get E2EE. That said, you can also get E2EE on Discord if willing to violate their AUP using BetterDiscord [2] + DiscordCrypt [3]. That it violates their terms should be a signal they need your data to have value.
Mostly agree, although I do still think it's solvable in theory, e.g. if chat platforms had strong incentives to implement the same popular feature sets (for example, think of how many websites implement various optional HTML features such as metadata tags, since it helps them on social media, chat applications, search engine results, and so on).
I think a federated system is probably possible. If Matrix comes out with a killer server and client combo in the next few years, it could take off and really work. But I think if too many server implementations are created, they will end up in a state where its not possible to add new features anymore because a large percent of the user base won't be able to use them because their server implementation does not support them.
Having compatibility between systems like between discord and telegram is just going to be a nightmare no matter what you do since they both want to decide on their own what the features should be.
We have plenty of other successful interoperable standards. HEVC. Wifi. Even Javascript. Sure, perhaps bureaucracy has caused them to move more slowly than they could, but on the whole these forums produce good technologies.
I'd offer an alternative explanation for why we haven't seen interoperable communication software—because proprietary systems make more money.
Wifi, HEVC, and to some extent JS have a single owner or group which is able to make authoritative decisions which improves things.
Its easy for the MPEG group to say, this is our new standard. Thats what it is, not debate. But imagine trying to come out with Email 2 and getting that to work on every email server and client.
Not being the most popular at any given time does not mean it's impossible. IRC (and XMPP for that matter) has been around for a long time and it's still possible to run your own server or connect to someone elses, usually with a choice of multiple clients.
How many "innovators" have been born and died in the time that IRC has been around? It seems to be that proprietary stacks are impossible long term, while IRC and open standards continue to exist and evolve, even if they aren't popular right now.
IRC still exists but the age or IRC is long over. Sure, people still use it, but some people still use myspace. IRC is lacking most of the features that the average person considers the bare minimum level of features.
Being able to see messages while your computer was turned off is bare minimum. Being able to use your phone to connect and receive push notifications is bare minimum. Being able to share a photo is bare minimum. Having a profile picture is bare minimum.
Some of these features can be sort of had with client extensions or middle steps like irc bouncers but the average user does not care for this. It should just work and every other platform just works.
The average user also doesn't care if the proprietary messaging platform of the day dies and is replaced with a new one because its easy to sign up again on the next platform
Not sure if it's a counterpoint or an agreement, but Communication softwares are already not interoperable with themselves:
* In discord, you need to install the "native" client to be able to share your screen or see other peoples' shared screen. The web client cannot.
* Microsoft Teams in Firefox does not do Calls; "Native" Microsoft Teams in Linux cannot "raise hand"; Microsoft Teams in Chromium on Linux cannot do the background thing.
Some of those may have evolved, I have only used Teams in chromium recently.
Lots of software does not do calls on Firefox because they rely on a broken alpha WebRTC implementation in chromium and don't work with the proper implementation in Firefox. Chromium is the new IE6 (and Safari is IE5.5)
Interoperability in communication software is impossible. I know this will upset a lot of people here but its just what we have seen time and time again.
Interoperable and standard software can not innovate because it is impossible to innovate since you need all vendors to agree and move in the same direction as you. Look at how ircv3 went. They promised the absolute bare minimum change to make irc slightly more modern and they weren't able to pull it off in time.
Discord could not be interoperable with other systems because most of its features did not exist at the time it added them. Interoperability means catering to the lowest common denominator of feature sets.
As discord has shown, siloed platforms are not the end, people will move to a new platform if it is clearly better. Discord was much much better than the rest so everyone moved. If someone else makes something much much better again they will move again.