The day my inbox became a notebook (and then a blog)
It started in a grocery line.
One hand on a basket, the other thumbing my phone, I wrote myself an
email with the subject line “ideas that will never be a blog post.” Not
a note in some dedicated app. Not a message to a Slack channel that
would vanish under GIFs. An email. I hit send, the screen blinked
“delivered,” and that was it. No decision about where to file it, no
mysterious “inbox zero” dashboard, no extra taps. Five minutes later -
between bananas and the checkout - I replied to my own message with a
second thought. The conversation threaded itself. A week later I
searched “never be a blog post” and the whole idea - chain unfolded like
a time capsule.
I didn’t plan to “use email for everything.” It snuck up on me. Email
felt like the sidewalk of the internet: not pretty, but paved
everywhere, and it gets you where you need to go. It has a timestamp. It
has a subject. It has replies. And crucially, it works with other
people’s habits instead of inventing new ones. When I realized that, my
behavior shifted. Instead of hunting for the “right place” to put a
thought, I lowered the cost of capture to almost zero. If a thought can
be lost in minutes, the best tool is the one with the lowest startup
friction.
If you imagine ideas as radioactive - half‑life measured in hours - then
the only reliable preservation method is a container that’s always
within reach. For me, that container is email.
From private inbox to public square
Once I started drafting notes and coordinating projects by email,
another question presented itself: why not make the inbox a blog?
I don’t mean “email newsletters” (those are great, but different). I
mean: what if each email I send to a special address becomes a post on
my site? What if I could “publish” by doing the thing I already do a
hundred times a week - send or forward an email?
The appeal is conceptual simplicity. In software, a good abstraction
reduces the number of moving parts you must think about. Publishing
usually requires at least three: a writing surface (editor), a content
store (CMS/database), and a delivery mechanic (the site). Email
collapses the first two: it’s already a familiar editor and a structured
container. If the site can read the inbox, publishing becomes “send.”
The system borrows the reliability of a decades‑old protocol rather than
inventing a new one. It’s like shipping containers for ideas:
standardized sizes, universal docks, everything fits.
There’s also a cultural point. We treat blogs as “public,” email as
“private,” and that boundary is useful… until it isn’t. Some things are
born private and become public after twenty minutes of reflection. Some
start public and retreat to private when they’re wrong. Good writing is
mostly error correction over time. If your publishing tool makes it easy
to move across that boundary - private to public and back - you’ll write
more and hesitate less.
An “email blog,” explained without the jargon
So how does an email‑to‑blog setup actually work?
At a high level, there’s a small service watching a specific mailbox (or
folder) in real time. When a new message arrives, it turns that message
into a web page. That’s the whole magic trick. The helpful features
sound technical, but they exist to protect the simplicity:
-
Real‑time email monitoring. Think of a doorman who pings you the
moment a package hits the lobby. The system listens for new mail and
publishes posts immediately, so there’s no “deploy” step. -
Automatic updates. If you fix a typo by replying to your own
email, the site quietly refreshes the post. No dashboards, no rebuild
buttons just send the correction. -
Secure email fetching. It signs in with the least possible
permissions, over encrypted connections, and (ideally) only reads a
single folder. Like handing a visitor a guest badge, not the master key. -
Content sanitization. The service scrubs the email so it’s safe to
display on the web: no stray scripts, trackers, or weird formatting.
Text stays text; links stay links; images are handled politely. -
Memory‑efficient caching. Imagine an assistant with a great
short‑term memory: the site keeps recent posts ready to serve instantly
without storing your whole archive in RAM. Fast, but frugal. -
Health‑check endpoints. A tiny “pulse” page lets monitors ask,
“Are you alive?” If something goes wrong, you find out before readers
do. You don’t see this as a reader but it’s a big reason the system
feels boring in the best way.
None of these are flashy. That’s the point. The features exist so that
the interface - send an email - stays stable and boring. Boring is
secretly powerful.
A tiny blueprint you can follow
You don’t need to read RFCs or write a CMS from scratch. Here’s the
blueprint I wish I’d had on day one, explained in human terms rather
than code:
-
Choose the mailbox and the rule of the game.
Create a special address or folder say,public@yourdomainor a
folder called “Blog.” Decide what counts as publishable: emails you send
there directly, forwards from your main inbox, or messages that match a
label like#public. -
Connect to your email provider using IMAP.
IMAP is the protocol most providers expose for reading mail. Use an
app password or OAuth if available. Configure your service to read only
that one folder. Read‑only, not delete. Guardrails matter. -
Listen in real time with IMAP IDLE.
“IDLE” is a mode that lets your service wait for the server to
announce new mail—like a restaurant buzzer instead of constant “are we
there yet?” polling. When the ping arrives, fetch the message and start
transforming it. -
Map an email to a post.
Subject → title. Message‑ID → permalink. Date → published time. The
sender (you) becomes the author. The body becomes the content.
Attachments can be images; inline images become part of the post. If you
forward something, add a tiny banner that says where it came from. -
Sanitize and shape the content.
Strip out scripts, dangerous tags, and odd inline styles. Keep links,
headings, lists, and blockquotes. Normalize quotes and line breaks so it
reads like a blog, not a forwarded memo. If you support Markdown,
convert it during this step—but don’t require it. -
Render pages and keep them snappy.
Generate clean HTML. Cache the most recent posts in memory so the
site feels instant. Store everything else on disk or in a modest
database. Add simple pagination and a feed (RSS/Atom) so readers can
follow along without a platform getting between you and them.
That’s it. The blueprint is short because most of the hard problems:
identity, drafts, revisions, distribution - are problems email already
solved decades ago. You’re just reusing the infrastructure and moving
the fence between “private” and “public” a few feet.
Why this fits me
An email‑based blog matches how I think and how I talk. I like to
capture an idea the moment it appears, even if it’s wrong in the
details. I like conversations that accrete into understanding. Email
gives me timestamps and threads for free; the blog turns those threads
into a public notebook. It’s a workflow that encourages explanation over
performance. There’s no “publish anxiety” because “publish” is the same
gesture as “send.” And because the system is simple - real‑time
monitoring, automatic updates, safe fetching, sanitization, lean
caching, a little heartbeat it’s hard to break and easy to trust.
Will this replace every CMS? Of course not. If you need complex layouts,
scheduled campaigns, or a team of editors, you’ll want more knobs. But
if your goal is to think in public with minimal drag, an email blog is
suspiciously close to ideal. It leverages a protocol everyone already
knows, respects the half‑life of ideas, and keeps you writing where you
already live—your inbox.
So here’s an invitation: open your email client, compose a note to a new
address or folder named “Blog,” and send yourself something small. A
question you’re chewing on. A paragraph you’d normally marinate in a
notes app forever. See how it feels. If you’re curious, wire up a tiny
service to turn that folder into a site. Keep it boring. Keep it honest.
And maybe let your inbox be what it always wanted to be: a place where
knowledge moves - first privately, then publicly - with as little
friction as possible.
P.S. Want to run your own? I open‑sourced a tiny server that turns an
inbox into a site:
email‑blog‑server.