Re: Fully functional email address

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Jun 16, 2025 at 12:32 PM John R. Levine <[e-mail]> wrote:

> On Sun, 15 Jun 2025, Christian Huitema wrote:
> > First, to the general topic of email: basically, email is dying. Or
> > rather, it is becoming really hard to deploy individual servers. ...
>
> People have been saying that e-mail is dying for at least 30 years.  That
> part is constant, whatever it is that's going to replace it keeps
> changing.
>
> You are right that it is hard to run your own mail server, but there are
> lots of places that provide excellent mail service and support if you pay
> for it.  I find the complaints about free mail services odd.  They're
> free, you're at least getting what you paid for.
>
> Incidentally, the reason that mail will never go away is that it is fully
> federated, doesn't require people to be online at the same time, and is
> easy to archive and search.  So far none of the replacements do that.
>

That is almost a complete description of the barriers but you are missing
one: There is no transition strategy. It is not enough to have a better
messaging format, I built that eight years ago. The entire problem is how
to move from where we are to where we want to be.

Which is why I am so excited about DNS Handles and combining them with
JSContact.

My original idea for providing end to end messaging for users of Blue Sky
was to bind a Mesh profile to the DNS handle address same as we do for the
DID that maps to our ATmosphere account. And that works fine but means that
the only people can use it are people who have my messaging client and it
only works for one app. It doesn't work for SSH or for signing Git commits
or the like.

So my next approach was to bind a DNS address to a Mesh contact assertion.
Which was kind of silly because the spec says 'replace with whatever
JSContact becomes'.

So given my handle @phill.hallambaker.com, you can pull my JSContact
information and that gives you all the contact information I am offering
for all the applications I am offering it for. You get my code signing
keys, URLs for all my blogs, my S/MIME, OpenPGP etc keys, everything. And
there is a slot that can be used for specifying update mechanisms including
a key to authenticate the new contact data.

Doesn't have to be a DNS handle, can also exchange the contact info via QR
code and the mechanism provides encryption and authentication controls. So
if Alice and Bob meet in person once and exchange their contacts via QR
code, they have end-to-end security with direct trust for every application
they use to communicate - past, present or *future*.


What does this mean for email?

One thing we can do is use the contact scheme to specify that we use a
particular profile of SMTP, such as 'my outbound server doesn't change the
content by adding stupid footers' or 'I accept HTML mail profile X'. And
yes, we could do an SMTPbis based on that premise.

But if people are using email apps that support the proposed approach to
contacts, the app designers aren't going to be interested in a slightly
less s***y version of SMTP if they know they can send this message to Fred
versus some completely new protocol that doesn't have the 50 years of
baggage SMTP has to carry about with it.


If people start using DNS Handles as a means of exchanging JSContact data,
that is going to become their effective address for everything - including
voice.

As a user, if I have the choice between paying the $0.50/min my corrupt
price-gouging monopolist US telephone carrier charges me to make a call to
the US from my cell phone and paying $0.00/min, guess which I am going to
do?

Yeah, have tried the SIPP client thing, they still plug into the legacy
telco infrastructure, experience is tremendously underwhelming and it isn't
end-to-end secure. The JSContact approach means I can reach any of my
contacts provided that there is at least one protocol we both share.

In this model, the federation comes from the DNS, so even if Signal won't
open up their proprietary service, I can effectively open it up in spite of
them. Open services that use standards based protocols and accept inbound
calls from users of different services will naturally grow while the
services attempting to remain closed will naturally wither.

If people are using this system to avoid paying the monopolist's
international calling rates, they will end up using it for messaging and
mail as well.

All it will take to turn MOQ into a voice/video messaging scheme is to add
a presence service so Alice's devices register with the presence service
and get a notification when Bob's device sends a request to talk to the
presence service. Asynchronous messaging is exactly the same thing, just
with the message being stored for later collection.