The way to accomplish the change is to propose upgraded versions of SMTP, IMAP, et al that are backwards compatible with existing protocol versions. This way the infrastructure can update incrementally. If both clients in an email exchange and all the servers they're using in between support the new versions you get the features. iMessage manages this pretty well.
There are two key requirements for anything that would actually supplant email:
1. Call the protocol "Email 2"
2. Build something that actually justifies the name
I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server.
Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy.
There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
Another alternative is to support cross communication between email and this new protocol until it has enough users that supporting email stops being a priority. Then start offering new installations with email compatibility off by default until the majority of the users are on the new protocol, then keep email support only on lts releases and finally remove email completely. This way you avoid having to carry the baggage of email forever and having to support an old protocol full of backwards compatibility hacks. This is all in theory, in practice I doubt this will ever get close to replacing email.
That works pretty well for IPv6, doesn‘t it (actually, it does not)?
The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6.
If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
You make a great point. A very popular protocol or standard is never fully replaced. Either it continues existing next to the new thing (IPv4/IPv6) or gets an update while still having to deal with backwards compat (HTML, CSS). Whatever the case is we'll still be dealing with email in 20-30 years from now.
Na. We’re talking about adding a protocol to a list of a handful which people use regularly. What you just said sounds like something I would have heard in the 90s about using email for legitimate purposes. Why do we need email when we have fax? (Granted fax still exists, but it’s no email killer.)
This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
