On Tue, Mar 2, 2021 at 5:00 AM tom petch <daedulus@xxxxxxxxxxxxx> wrote:
On 01/03/2021 14:22, Phillip Hallam-Baker wrote:
> Yes HTML is a disaster for email. But so is plaintext wrapped at 66
> characters by the server because people didn't know better.
>
> The reasons HTML is a disaster are
>
> 1) There is no standard for HTML in email.
> 2) HTML has been turned into a presentation format.
> 3) Email messages used annotations for a decade before HTML which doesn't
> support them
> 4) The SMTP email infrastructure does not provide a viable means of knowing
> what formats are accepted by a recipient so there is no way to fix this.
>
> One painful side effect of 1 and 2 is that messages come with embedded font
> size specifiers which is beyond stupid. The sender has no idea what device
> I am reading something on. But Gmail will happily chose font size settings
> that are frequently stupid. I have no control over that as a user.
Going back to the original, having ranted about my number one hate, the
loss of privacy to anyone else on the list .....
The points you make are all good, and good reason why IETF mailing lists
should silently discard text/html attachments.
No it shouldn't. The reason HTML email is so crappy is precisely because people here failed to realize why the other 3 billion Internet users wanted it. And you are still making that mistake.
Only a very very small fraction of the world is fond of VT100 console output. It is a significant fraction of IETF but its still a minority.
HTML email is bad because nobody in the places which might have had influence wanted to make it really good.
SMTP has had a good run. So has the telephone system. But they are both long past their prime and need to go the way of the fax machine. I still have two fax machines in the house, its a function of the printer. But neither has been hooked up in five years now.
The replacement is quite feasible. Here is how I plan to go about it.
1) Open callsign registry.
Alice creates a public key pair, registers the public part in the callsign registry claiming the name @alice and specifying her current service provider where people can reach her.
Traditional RFC822 email addresses are owned by the domain name owner. Alice doesn't own alice@xxxxxxxxxxx and she can't take it with her.
The registry itself doesn't provide any services. It doesn't even provide query lookup, only zone transfer. This is so we can make the names really really cheap.
2) Contact catalog
Alice exchanges her contact information with friends. This is a kimono affair, she probably doesn't put her email address or her telephone in her public contact. But she has a contact specifying her SMTP, OpenPGP, S/MIME etc. And unlike traditional contact formats that aren't backed by PKI/TKI, this one automatically updates.
3) TKI
Threshold key infrastructure allows Alice to manage her private keys without knowing she is doing it.
I am not going to be replacing SMTP on day one. Mesh messaging is deliberately limited to 32KB messages. That might well be reduced to 8K before launch. But consider this, I am providing an open system that allows banks, stockbrokers, healthcare providers to reach their customer and send them secure messages that comply with HIPPA, GDPR etc. It is a system that allows them the security of their private infrastructures and the ubiquity of SMTP.
The Mesh is designed to allow these people to offload their costs. Running their proprietary messaging systems is expensive and not really that good for the customer. An open system serves them much better. So just like my brokerage buys me anti-virus subscriptions, I think that a few bucks a year to give me Mesh secure messaging will work.
And another thing. The Mesh is an open framework that makes it really easy for app designers to build their own stuff on top with confidentiality and integrity controls built into the core. All you need to achieve OPEN secure voice and video conferencing is to use the Mesh presence protocol to establish a WebRTC session.
And one more thing, Mesh Messaging is limited to 32KB precisely so that it can be used to send TB of data at a time. The raw video of the Mesh architecture series is 4TB. I should be able to send that to my editor by mailing it to them. Not by SMTP, I am not because it is a fore and storward system. Mesh messaging limits push messages to 32KB but the message sent can be 'please pull the raw video files from https://....'
So no, I don't plan to replace SMTP directly. Nor do I intend to replace the telephone. Instead, I am architecting an open system that is capable of growing by filling completely different needs and just happens to make them unnecessary.
The point when I have won is when you can buy cheap Mesh 'phones' for the home which are a combo of Mesh video, Mesh voice, Mesh messaging and they are also the remote control for your TV and smart home.
Oh and yes, I will be making a subset of HTML the basis for the messaging part.
