Deployment strategy for email+ Was: Mail is worse than everything except...

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 13 May 2022 16:28 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B0AC14F743 for <ietf@ietfa.amsl.com>; Fri, 13 May 2022 09:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.393
X-Spam-Level:
X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD87D2QGhVBT for <ietf@ietfa.amsl.com>; Fri, 13 May 2022 09:28:22 -0700 (PDT)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A803EC15EB27 for <ietf@ietf.org>; Fri, 13 May 2022 09:28:02 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id i11so16153700ybq.9 for <ietf@ietf.org>; Fri, 13 May 2022 09:28:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JwzM4SqZ3f6qE6bc/02XkeO+9sIQerEiHxcv2VYEwbc=; b=5xIXY8gZ7TxLKF3Lr4k2TZb6jC0cD5914C6h5OZ3AUAYJd5+Og3yR69bTvGIst58qM U4+eL1i0ABlpeAygrB5jvgfrgNGRh0f3odPDWNs7iyF4HJIs5DjzvXAALRZ4KPRRWnTD oy+OAryUBTt2sS3ZUyUWoxhDvOXQ7cU2ecDJcZm5Dgtb6JtFmtbGdHs7DS8nsY7Iwaj2 6y+E+Z5qk+EuPdjyNzTMdrxs3bWh+EahAwkzQbSupKmB9arv3twWRolAFRe/LBNay1Ei UYb4hZiU2Rmb/C6EWlnFa/gRKx/2eb2y748N4zu2XGh0RZNgaDK0yZGJfdOuy7dWGPf+ D/Lw==
X-Gm-Message-State: AOAM532YbhGIlndJZoAZqoMKc0TRYOoM9ItxnZzLzSefv26DLKZC1xxN O8YSbWFH+rfbWAZFqD+iSYL0VP9biSL48vfIBA/0R3CI
X-Google-Smtp-Source: ABdhPJyhZdfk1dMMmoPTrZXMI4Zi57HUtUV0HvDReUr9mXjsjtd9xlW6Fm0H4vmJ27iutVyxt0UXO4NoATaplcY6Q/I=
X-Received: by 2002:a25:d314:0:b0:649:1be0:505e with SMTP id e20-20020a25d314000000b006491be0505emr5476897ybf.501.1652459281704; Fri, 13 May 2022 09:28:01 -0700 (PDT)
MIME-Version: 1.0
References: <20220428221138.9BFD63F11488@ary.qy> <e11aeebf-22f6-b067-db4f-ea84fe41abc5@network-heretics.com> <CAMm+Lwj7ZZn_enfkfMgLiSRaQbyEi6pBwoEdkdppA-=eOt8RRQ@mail.gmail.com> <f2856072-7c03-cf1f-9ee4-f48d84290f6c@taugh.com>
In-Reply-To: <f2856072-7c03-cf1f-9ee4-f48d84290f6c@taugh.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 13 May 2022 12:27:49 -0400
Message-ID: <CAMm+LwgtH=2G8VbdDeUWRO9KtZxByqmjW=Wh1JVvux9_zU2K1w@mail.gmail.com>
Subject: Deployment strategy for email+ Was: Mail is worse than everything except...
To: John R Levine <johnl@taugh.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007deea905dee72897"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ui5hQOkPALG2rHUAj_T16i5LH94>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2022 16:28:24 -0000

On Fri, Apr 29, 2022 at 11:20 PM John R Levine <johnl@taugh.com> wrote:

> > It will certainly be an unpopular thing to say but I will say it:
> Protocols
> > wear out over time.
>
> In principle I wouldn't disagree, but in practice I don't see how we
> migrate from SMTP to SMTP++ or whatever.
>

The devil is in the deployment. That is why I have always had a deployment
plan and designed for deployment.

First: The Web succeeded, every other network hypertext scheme failed. Tim
Berners-Lee knew what he was doing, he calculated his moves. I watched him
and I am copying the same approach.

At this point, I have running code:

Demo Reel - YouTube
<https://www.youtube.com/playlist?list=PLK2hHAOxepEgZtTxX3BtkPUDIJ3--_FAu>
https://www.youtube.com/playlist?list=PLK2hHAOxepEgZtTxX3BtkPUDIJ3--_FAu

It is not a replacement for SMTP at this point. It does contain a messaging
system but that is limited to messages of 32 KB. It does not compete with
SMTP or even SMTP+S/MIME. It is a secure messaging layer for supporting
asynchronous workflow interactions. That is something which has value in
the enterprise as a basis for automating clerical processes.

One big failure in the IETF way of doing things is to limit the scope so
the deliverable doesn't come close to being a minimum viable product.
Another is that discussion of the UI is out of scope. Both doom efforts to
fail.


The Mesh is not a vast amount of code, in fact the code base has shrunk
considerably over the past three years. But the functionality is now
comprehensive. Mesh users currently get:

* An end-to-end secure password vault.
* A contacts directory that automatically updates.
* A means to secure data at rest and easily share it with their co-workers.
* Management of keys and credentials over all their user and IoT devices.
* End to end secure sharing of bookmarks, network configs, application
credentials across devices.
* Provisioning of OpenPGP and S/MIME keys.
* A 2FA replacement that is better than anything on the market today.

I am currently working on adding:

* The ability to create life-long callsigns that do not expire and do not
require 'rent'.
* An end to end secure messaging client with text, voice and video
modalities.
* A GUI management tool to replace the linemode.
* A Web browser that has the bookmark and password management integrated.

My profound gratitude to the folk at Microsoft whose .NET7, MAUI and
WebView2 platforms enable me to produce demoware that is close to
production quality in a remarkably short space of time. The first iteration
of the Web Browser took less than a day and the skeleton was up in under an
hour.


The big difference between my work and others in the industry is that I
have no shareholders. I am not building a walled garden designed to acquire
a group of users and bind them to my service. Mesh accounts are fully
portable. There are no switching costs. If Alice decides she is fed up with
service from Mathmesh.com, she can move to a rival and take all her data
with her. The contact details and forwarding addresses all update
automatically.


You know as well as anyone that for decades people have been saying e-mail
> is dead, everyone uses X instead, but the X keeps changing and e-mail is
> still around.
>


And here is how I plan to unthrone SMTP.

First get people to make use of my contacts book to exchange signed context
assertions which can include the credentials required to establish
end-to-end secure communications by means of any messaging, chat, mail etc
protocol. So your Skype, Signal, WhatsApp, SMTP, OpenPGP, SSH, S/MIME etc
contact info can all be presented in a contact.

[NB, this email is going to be too long as it is without folk quibbling
about whatifs. Yes Alice can create separate contacts so she only exposes
her email address and phone number to a select number of important
contacts.]
Alice and Bob can exchange contact information in various ways. They can do
so directly if they meet in person and bump phones. There used to be a
wonderful app for that until Yahoo bought it up and shuttered it. Yes,
iPhones can bump to iPhones via airdrop but that is a walled garden.

Alternatively Alice can put a QR code on her business card and Bob can scan
it. Alice can send Bob an email with a link.

Support for cases where Alice and Bob interact directly is relatively
straightforward. But for cases where there is an employer, I need PKIX
style capabilities. And for cases where Bob is going to get Alice's contact
information from Carol, I need a really short, really easy to use
identifier with the absolute minimum of clutter. Which is where my callsign
registry comes in. This allows Carol to tell Bob to contact @alice.


So at this point, if everyone is using my contacts book, the conditions
have been created that make the emergence of SMTP+ inevitable. Because
Alice's contact details will contain both her RFC822 SMTP address and the
contact details for email+.

The way I see email+ initially getting traction is within enterprises. 80%
of the employees in most large enterprises have little or no email
interaction with external users in an enterprise setting. So having one
email protocol for internal emails and a separate protocol for external
communications is entirely practical. In fact this is already the case with
Outlook and Exchange. Adding an extra protocol handler to Outlook and
Thunderbird is actually pretty straightforward.


Once the switching costs for deploying a new email protocol are addressed,
the only thing we need to add is some advantage for the new scheme. This is
really not a problem. Mesh Messaging is limited to 32KB but messages can
contain a link to an attachment of any size. So while I don't have code
yet, I know what advantages Mesh Mail can provide:

* Every mail is signed, no spam impersonating the ceo
* Every mail is end-to-end encrypted
* Every mail is subject to access control, no spam from unauthorized parties
* Mail messages can be of any size because large messages are pulled, not
pushed.
* Mail messages integrate into workflow.


If this type of open, mail messaging scheme gains ground inside
enterprises, it will start being used between enterprises as well.

Seems worth a shot.


PHB