On Mon, Jun 16, 2025 at 12:32 PM John R. Levine <johnl@xxxxxxxx> 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.
