I agree in part.
Over 90% of my emails are from mailing lists and SMTP mailing lists are a real Rube Goldberg affair. This is the exact problem NNTP set about trying to solve. It is a flawed solution but the idea that mailing lists are a separate modality is sound.
That said, I think far too often IETF protocols have failed because they have tried to do too little. Take PKIX which has three certificate status mechanisms because each time we tried to do the job properly, there was a chorus of 'don't try to boil the ocean'. And we ended up with an inadequate solution that inevitably led to the next one.
What SMTP lacks did not exist when it was first proposed. We did not have the technology even if we understood the requirements.
* We have portable telephone numbers, why don't we have portable email addresses?
* Why do I have to use different protocols to send Alice a message of 100 characters, 10MB and 10 GB ?
I have phase 1 of the Mesh ready for release:
The basic premise here is that the missing part of PUBLIC Key Infrastructure was managing the private keys. The Mesh is designed to be a configure and forget technology. Once you have connected a device to your personal Mesh and said what its authorized functions are, all the provisioning of keys and credentials takes place automatically.
No matter whether you want your end-to-end messaging scheme to be based on OpenPGP, S/MIME or Mesh Messaging, the Mesh can do all the heavy lifting of managing private keys and credentials for you.
Phase 1 of the Mesh provides an end to end secure password vault. Now provisioning public key pairs to devices so that they can access a password vault for authentication is a necessary transitional strategy but it is clearly bogus long term. When I was cutting the demo reels I said the next phase will be to provision out FIDO keys and credentials to the devices.
After reading the FIDO alliance materials and working on the problem a bit, I have changed my mind: Every browser already supports everything I need in TLS Client Authentication. All I need to do is use the Mesh to provision TLS Client auth keys and certificates to each device.
All we need to do is to write a profile that allows Web sites to specify Mesh TLS client auth certs and we are done (for authentication at least, not for ceremony).
I do agree that we need multiple types of messaging interaction but I think we can use a common messaging protocol base with all the authentication / encryption / payment schemes in place.
Where I plan to go in phase 3 is workflow.
On Wed, May 18, 2022 at 7:53 PM Jim Fenton <fenton@xxxxxxxxxxxxxxx> wrote:
Reading this long thread on the introduction problem and all sorts of other things reminds me that it isn’t productive to try to solve all of email’s problems with a single protocol. Email evolved as an easy way to contact basically anyone, and as a result got used for a lot of applications with different (and even conflicting) requirements.
We should be working defining a number of protocols that handle some of the things that email is used for today, and that email doesn’t do well. Some examples might be mailing lists, newsletters, advertising, notifications, and even personal correspondence. Some of these have an introduction problem, and others are explicitly opt-in and could solve the problem at opt-in time. They might even be merged together for the user so they don’t need to look at multiple things. And yes, there would still be email to handle the “everything else” cases.
I’ve been playing around with something to handle notifications, but it’s not clear how that would achieve deployment even if it worked well. There is a definite chicken-and-egg problem here.
-Jim
