It&#x27;s hard to make money in that space, yes.<p>I&#x27;ve considered merging mail and messaging, so that email protocols are used to do the things people do with instant messaging, Telegram and such.  The first step is to get away from queuing mail.<p>A first step is a new kind of mail forwarder, one for machines that don&#x27;t have local mailboxes (which is most non-mail servers). It acts as an SMTP server and client. When an email comes in, and the sender reaches the end of the DATA section, the forwarder checks its forwarding list to see where this mail is supposed to go.  It opens a SMTP connection to the destination and sends the email.  The incoming SMTP connection is held open while this is in progress. Any problems are reported back to the sender immediately with an SMTP status code.  There are no bounce emails, no queuing, and no possibility of joe-jobs.  All mail is handled immediately or rejected immediately.  (This only applies to single-address messages, and only to &quot;To&quot; addresses. Everything else is bulk.)<p>The next step is an IMAP server which has the same immediate orientation.  When it gets an incoming email, it sends a push notification to any connected clients, while holding the incoming connection open.  If at least one client is responding, a SMTP success status is returned.  Otherwise, you get some status such as 251 (User Not Local, Will Forward.)<p>Then, a threaded email client.  It would help to have the convention that an email with subject but no text, text but no subject, or text the same as subject is displayed like an instant message.<p>All of these can be done independently, and are backwards-compatible. If you have all of them, email is equivalent to instant messaging - you can tell if it was delivered, it goes through immediately, and it works like a conversation.<p>Of course, there&#x27;s no big-money startup in this.