On Wed, Jan 5, 2022 at 8:18 AM John C Klensin <john-ietf@xxxxxxx> wrote:
But, again, I think we are going around in circles. Other than
acting as a two dimensional prototype or representation for said
wheel, this doesn't appear to be about SMTP (with or without
encryption) except for an (IMO extravagant and unrealistic)
claim that the proposed new system will supplant it. Can we get
to clear statements about what specific problems are being
solved, how the proposed mechanisms will solve them, and what
their scope/ applicability are?
If people care to look back, I am really not the person who keeps raising SMTP.
My goal is to build a communication later that is end-to-end secure and supports all communications modalities, both synchronous and asynchronous and puts people in full control of their digital life:
* An account that belongs to Alice, not the service provider that she is using
* Zero switching costs when changing providers
* The ability to send messages of 1 character to 10TB
* User defined workflow interactions
* Separation of contact hailing interaction from messaging
These requirements are not entirely new of course, I have raised similar requirements over the years on this list. The reaction to my earlier proposals was 'you cannot possibly build such a thing'. So over the last three years I have done exactly that. I have running code and documentation with examples generated from that running code. They do not currently meet every requirement in full but they do provide a proof of concept for a system that does.
Now to be fair, these are not the only requirements that I have raised, architecture is an iterative process and requirements are dialectic to implementation. Those are the requirements that I have met. If people want to discuss adding or changing the requirements, it is a bit late. The code I will be releasing this month is Phase 0. Meeting the remaining requirements and going to a Beta release is Phase 1. The Callsign proposal that began this discussion was my attempt to begin discussion of requirements for Phase 2.
When I raised requirements, people dismissed my proposals as impossible to implement, I was a fool tilting at windmills then. I was met by derision and contempt by the usual bullies who see every new idea as a threat to their personal position. Yet I do have running code.
The reason I knew the Mesh was possible was that I have a much wider grasp of the available technology than most people in this organization. I identified Threshold cryptography as the key technical advance required to meet my requirements and persuaded two very senior ex-NSA people they should try to put that technology on the NIST roadmap.
The reason I have no interest in creating any development dependence on SMTP or Jabber is that having built my system, I can see that the technical requirements implicit in the architectural requirements lead to the following situation:
Use cases:
Alice knows Bob having met him. They exchange contact details. Bob supports receipt of encrypted messages. Alice can now send Bob end-to-end encrypted messages.
Alice knows Carol having met her. They exchange contact details. Carol does not support receipt of encrypted messages. Alice sends messages to Carol plaintext
Architectural requirement:
Sender must know the messaging protocols/formats they accept and the public key of the recipient if supported
Technical requirement:
A contact catalog synchronized across all of the user's devices that are authorized to send messages
Means of publishing, updating and verifying contact information
At the moment, I do not have a messaging interaction specified. But I do address Mail and the use of OpenPGP and S/MIME credentials. I have not written the scripts themselves yet but the idea is that all Alice needs to do to be able to receive OpenPGP or S/MIME email is to run a script and it will automatically configulate Outlook or Thunderbird with her keys. And she can do that on all of her devices so that they can all read the S/MIME etc. mail. Which makes it much easier for Alice to post a note in her contact saying 'end-to-end encrypted messages preferred' which in turn allows the client to automatically encrypt messages without Alice needing to lift a finger on her mouse.
Sure, I can and I have done (most of) that. But just think through what it means.
The only people who are going to be using automatically encrypted mail messages are going to be the people who are using Mesh extensions or something that provides the same functionality to their email client. And every one of those users has an email client that is integrated to a contact book that gives Bob the ability to post, 'I accept NG-MTP' in their contact. And then, instead of sending the message via SMTP to be mauled and harassed by anti-spam filtering heuristics, the MUA is going to post the message via NG-MTP instead.
If Jabber was a rip roaring success, building on top of SMTP/Jabber might make sense but it is barely on life support. Meanwhile Slack was bought for how much?
The Web didn't just happen by accident, we spent a lot of time thinking about deployment strategy. I ran simulations to test out different strategies. I think I know where this goes. Finding all the companies who felt threatened by Time Warner's Interactive TV and persuading them to work together worked out well for us then. Why shouldn't it work now when even more companies are afraid of being gobbled up and commoditized by Big Tech?
