Modern email can be built from borrowed parts

I would advise reconsidering keeping the current format exactly. Something that would allow conventional email addresses to kept in a list that disambiguates them unambiguously would probably be a good idea.

You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale, which causes you major problems. I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.

That improves the ability of more language environments to be able to handle the email as a stream or in chunks with "normal" libraries and practices. MIME parsers in languages that tend to favor pulling everything into RAM as a string are still more likely to have been forced to face this issue already.

> You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale

Why? Even if your system loads emails into memory a whole email at a time, that doesn't imply that it will load large numbers of emails simultaneously. The kind of processing that can be done by stream-processing large numbers of emails in parallel seems rather limited to me.

> I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.

If we're specifically talking about being able to short-circuit after headers, then why not a JSON header followed by JSON representation of the body?

FWIW, I'm on desktop but I do have JS disabled (more precisely, I use NoScript).

This results in the top and left-side bars staying decorative and unobtrusive, but the concurrent visitor counter thingy is floating well above the bottom-right of the page. But then, as I shrink in the page width, the left-side bar and the concurrent visitor counter swap sides, and also a bunch of the content from the top is added to a new bar at the bottom. Eventually, the horizontal space between the side components becomes irrelevant such that they function as an additional bottom bar. At which point, maybe 40% of the vertical space is used for navigation and other shiny toys. This is really annoying, and the overall experience is inconsistent across widths.

(Also, at all widths, the top-bar has a transparent background, so main page text interferes with top-bar text as it scrolls.)

All of this is done in CSS, so presumably it can be fixed that way too.

I Linus Torvalds needs them. And that's a good enough reason for their existence as far as I'm concerned.

Basically what iOS messages does with SMS. I would note that this hasn't resulted in everyone using iOS messages as a communication protocol, but it does make users aware when it's not in use, with some inherent social pressure.

When dealing with any kind of network effect and existing user behavior, though, especially one as ingrained as email, I would highly recommend being judicious about using the word "just," given that these are mutually-reinforcing effects. Imagining a solution is a world away from implementing one.

Still, I think you're on the right track: create a new protocol on top of an old one, use the same input methods and user behaviors, call attention to when someone is not using it (e.g., green bubbles), and make it extremely easy for existing services to migrate to use it (i.e., the standard/standards body, notably NOT what Apple has done). One part that's missing here is some pressure to make this happen: positive pressure (economic, product sense, persuasion) or negative (economic, social, regulatory).