move static files into static sub-dir, refactor nix a bit

1 files changed, 0 insertions, 172 deletions

diff --git a/src/_posts/2021-04-01-fmail.md b/src/_posts/2021-04-01-fmail.md
deleted file mode 100644
index bdc473c..0000000
--- a/src/_posts/2021-04-01-fmail.md
+++ /dev/null
@@ -1,172 +0,0 @@
----
-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!