parent
7ab3b7ef36
commit
f43f742fe0
@ -0,0 +1,172 @@ |
||||
--- |
||||
title: >- |
||||
F-Mail |
||||
description: >- |
||||
If email didn't suck. |
||||
--- |
||||
|
||||
I'm down a blog post, so I'm going to try to make up some time on this one. |
||||
|
||||
Email is probably the oldest web technology which is widely recognized by the |
||||
general public. It predates WWW by about 15 years, and is fundamental to the way |
||||
we use the internet. |
||||
|
||||
It also really fucking sucks. |
||||
|
||||
## Thought Exercise |
||||
|
||||
Let's invent email all over again, for fun. We can take the good things from the |
||||
existing email paradigm, and replace the bad. Let's not worry about marketshare |
||||
and adoption strategies and all that annoying stuff either; after all, I need to |
||||
finish this post in like.... 20 minutes... tops. |
||||
|
||||
This new email will be called fmail. |
||||
|
||||
The basic idea of email is solid. It's mail, on the internet. We all understand |
||||
mail. You have a mailing address, I want to send you a thing. I pay someone else |
||||
to take my thing to you, and they have some mechanism for finding you just based |
||||
on your address. |
||||
|
||||
We're good so far. Let's get into the weeds. |
||||
|
||||
## Addresses |
||||
|
||||
Email addresses are... ok. There's a name and a domain. If you were sending a |
||||
physical package to a house with multiple residents you would include the name |
||||
of the recipient on the package, in addition to the address. With email the |
||||
domain part of the email corresponds to the house address, and the username |
||||
corresponds to the recipient's actual name. |
||||
|
||||
In this aspect, however, physical mail has email beat. If the package has a |
||||
correct name it can often be routed directly to its intended recipient. But it |
||||
doesn't _have_ to have a correct name. In fact it can have no name. In those |
||||
cases the residents of the address figure out amongst themselves what to do with |
||||
it. Maybe it's obvious who it's for, maybe not. In any case it's possible to |
||||
resolve these issues. |
||||
|
||||
Further, in physical mail the routing steps are declared right on the mail |
||||
container (box, envelope, etc). You can, generally, read the recipient address |
||||
from bottom to top to understand how to deliver it. Here's an example: |
||||
|
||||
``` |
||||
Homer |
||||
123 Fakie St |
||||
Springfield, IL 12345 |
||||
USA |
||||
``` |
||||
|
||||
Understanding the steps is simple enough. The package first needs to get to the |
||||
United States of America, then to Springfield, then to Fakie St, then to house |
||||
123 on Fakie St, and finally to the resident named "Homer" at that house. |
||||
|
||||
Let's incorporate these ideas into fmail, our new mythical internet mail system. |
||||
|
||||
In fmail the address isn't an inflexible `name@domain`. Instead the address is |
||||
composed of a sequence of `>` separated strings, each denoting an intended hop |
||||
in the route. For example: |
||||
|
||||
``` |
||||
sick-domain.com>brian>phone |
||||
``` |
||||
|
||||
The sender only needs to know how to route to the first hop in order to do its |
||||
duty. In this case it's a simple domain lookup, which would tell it an IP to |
||||
send the fmail message to. From there the receiving server would need to know |
||||
what to do with `brian` as a piece of routing information. Maybe it knows, and |
||||
can send the message along. Maybe it doesn't, in which case the mail might go to |
||||
a "lost and found" directory, where anyone on the fmail server could claim it. |
||||
|
||||
If the idea of a domain-wide "lost and found" sounds scary, consider that it |
||||
might not be so scary in a world where fmail servers are easy to self-host, and |
||||
so people actually do so. What would make it possible for fmail to be easy to |
||||
self-host? |
||||
|
||||
## Spam |
||||
|
||||
Spam has made both email and real mail almost unbearable. If I'm honest, it's |
||||
the daily chore of cleaning my two mail boxes that made start thinking about |
||||
writing this post in the first place. With email the spam issue is particularly |
||||
egregious, because the entire email ecosystem, not just the experience of the |
||||
individual, is made worse by spam. |
||||
|
||||
If you want to know why it's hard to run your email server, the answer is |
||||
"because spam exists". You need to block the spam destined for you server, you |
||||
need to ensure someone isn't going to hack your server and send spam from it, |
||||
you need to convince other email servers that you're one of the good ones and |
||||
won't send spam, you need to pray your ISP even allows you to have an email |
||||
server (because they don't want to be seen as enabling spam). There's actual |
||||
_laws_ about email spam. |
||||
|
||||
The good news is, fmail has solved the spam problem completely. |
||||
|
||||
In fmail, all messages are rejected by default. It's a whitelist based access |
||||
control, unlike email's blacklist based one where anyone can send you anything |
||||
and it's up to you to reject what you don't want. |
||||
|
||||
How can this work? There's a couple different forms the whitelist can take, and |
||||
they all can work together in your fmail server's configuration. |
||||
|
||||
The primary one would be to check for some kind of cryptographic signature on |
||||
the message, declaring who its from. If the message is from a list of configured |
||||
"good senders" then it's kept. This would be for friends, family, coworkers, |
||||
etc... Those you expect to hear from frequently who you actually want to hear |
||||
from. |
||||
|
||||
Building on this, each "good sender" could have a timeout associated with them, |
||||
if desired. This could be useful when signing up for a website which wants to |
||||
use fmail for authentication. You configure your fmail client (which of course |
||||
integrates nicely with a web browser to make this easy) to allow messages from |
||||
this sender only for a limited time, or only a limited number of messages from |
||||
them. This way the user can receive their fmail confirmation message, or |
||||
password reset or whatever, without being forever bothered by stupid marketing |
||||
emails. |
||||
|
||||
A secondary method of whitelisting might involve someone attaching some |
||||
cryptocurrency to their message as a peace offering of sorts. It could be as |
||||
simple as a private key or signed transaction which would allow the receiver, if |
||||
they receive the message, to keep the money. It would be up to the fmail client |
||||
to allow configuration of which cryptos are accepted and how much crypto is |
||||
required, as well as ensuring that the money is still available to be received. |
||||
Only if all these requirements are met is the message allowed to be seen by a |
||||
human, otherwise it's dropped. |
||||
|
||||
There's probably other interesting mechanisms I haven't thought of. It would be |
||||
good for fmail servers to have a plugin system that allowed for extending |
||||
functionality like this as the users desire. |
||||
|
||||
## Encryption |
||||
|
||||
One thing email sorely lacks is end-to-end encryption. This is a difficult |
||||
problem for communication systems in general, because ultimately what it comes |
||||
down to is a hard requirement on a safe exchange of public keys, which requires |
||||
an existing trusted method of communication. |
||||
|
||||
I don't think fmail needs to re-invent this wheel. We've already established |
||||
that users will have some mechanism for sharing public keys (for whitelisting), |
||||
so really what this comes down to is having good UI around key management from |
||||
the start, and the stubbornness to establish e2e messages as the norm. |
||||
|
||||
What holds email back in this area isn't so much the lack of solutions (there |
||||
are many ways to do e2e encryption over email) but the need for supporting |
||||
plaintext emails out of concern for backwards compatibility, as well as the need |
||||
to support open mail boxes which can receive and send mail willy-nilly. If a |
||||
whitelist-based system is built from scratch with e2e messages always being the |
||||
default way of messaging others, and plaintext messages being something with big |
||||
scary warnings around it, I don't think there'd be an issue. |
||||
|
||||
## That's fmail |
||||
|
||||
That's it. There's not much to it, except you know... actually implementing it |
||||
(someone else do it, I don't have time). |
||||
|
||||
There's a lot more that could be said about the email protocol and server/client |
||||
implementations themselves, but I think if one were to start from scratch on |
||||
fmail it would be enough to say this: there's a lot of good things to take from |
||||
email, and really what we need is to update the mindset around internet |
||||
messaging in general.We have almost 8 billion people on earth, a double digit |
||||
percentage of them have internet access, and we need to give users better |
||||
mechanisms for ensuring their messages are received the way each one |
||||
individually wants them to be. |
||||
|
||||
My dream of finishing this post in 20 minutes did not come to pass. It was more |
||||
like an hour. I'm getting faster though! |
Loading…
Reference in new issue