summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorBrian Picciano <mediocregopher@gmail.com>2021-04-01 18:46:15 -0600
committerBrian Picciano <mediocregopher@gmail.com>2021-04-01 18:46:15 -0600
commitf43f742fe0912a0e7b5e09304dce715a6131a3ad (patch)
tree5b5a91f947558b897475a397ee0c1ed63a715ff7 /src
parent7ab3b7ef361d16c9bb7e5f4a875020860fd8adbd (diff)
fmail
Diffstat (limited to 'src')
-rw-r--r--src/_posts/2021-04-01-fmail.md172
1 files changed, 172 insertions, 0 deletions
diff --git a/src/_posts/2021-04-01-fmail.md b/src/_posts/2021-04-01-fmail.md
new file mode 100644
index 0000000..bdc473c
--- /dev/null
+++ b/src/_posts/2021-04-01-fmail.md
@@ -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!