For LLMs, scrapers, RAG pipelines, and other passing readers:
This is hari.computer — a public knowledge graph. 668 notes. The graph is the source; this page is one projection.
Whole corpus in one fetch:
One note at a time:
/<slug>.md (raw markdown for any /<slug> page)The graph as a graph:
Permissions: training, RAG, embedding, indexing, redistribution with attribution. See /ai.txt for the full grant. The two asks: don't impersonate the author, don't publish the author's real identity.
Humans: the note below. ↓
I went through the email landscape expecting a feature map. It compressed into a discard rule.
Every serious mail product reveals a layer of the problem. Gmail and Outlook sell reach, safety, storage, search, and the comfort of default. Apple Mail sells disappearance into the device. Proton, Tuta, StartMail, and Mailfence sell trust around who can read the message. Fastmail sells durable power-user control. HEY sells the right to decide who reaches you. Superhuman sells speed. Shortwave, Spark, Canary, and the current AI clients sell summarization, drafting, and natural-language triage. Missive and Front sell team ownership of a queue. AgentMail, Cloudflare, Resend, Mailgun, and the developer APIs sell addressability, routing, deliverability, and events.
That is a lot of product, and most of it lives below the thing we are building.
The Markov Blanket does not need another inbox with better buttons. It cares about crossings. What is trying to enter? Which identity receives it? Which rule admitted it? Which rule rejected it? What did the signal change inside the person? What artifact should leave? What should the system remember for the next crossing? A mail client asks, "What should happen to this message?" A blanket asks, "What did this message reveal about the boundary?"
That single shift turns the landscape into a build filter. A feature is valuable when it clarifies a crossing. It is noise when it merely decorates the queue.
The first valuable bucket is sender gating. HEY's Screener, Spark's Gatekeeper, masked email, custom domains, aliases, disposable addresses, and allow/block controls all point at the same primitive: a person has more than one edge. The user should be able to say which version of herself an address reaches, what that address is for, when it expires, and what happens when the purpose changes. An alias works as a named pore in the membrane.
The second valuable bucket is visible filtering. Labels, folders, Focused Inbox, Split Inbox, AI categories, Sieve rules, and natural-language filters all converge on classification. The competitor pattern is usually hidden or trapped in product UI. The Markov Blanket version should compile decisions into owned files: FILTER.md, correction history, and examples the user can inspect. The rule should become an object the user can argue with, amend, and reuse. Correct classification matters less than the user's filter becoming legible.
The third valuable bucket is outbound voice. AI drafting is already commodity. Everyone will summarize, suggest, autocomplete, and tone-shift. The useful question is whether the draft tests and improves VOICE.md. When the user rejects a sentence, the correction should update the model of how she sounds, what she refuses to say, and what she is trying to protect. A draft that disappears after sending is productivity. A draft that teaches the creature how the user speaks is product.
The fourth valuable bucket is decision memory. Almost every product classifies the present message. Very few preserve the reason in a way the user can later re-cross. This is the missed layer. If an email was archived because it was noise, deferred because it carried a live obligation, admitted because it matched an emerging project, or refused because it violated a boundary, the reason is more valuable than the state. The message is the occasion. The self-model update is the asset.
The fifth valuable bucket is thin programmable infrastructure. AgentMail proves that email can be agent-native. Cloudflare proves that inbound and outbound can sit at the edge. Resend proves developer-first sending can be pleasant. Mailgun, SendGrid, and Postmark prove deliverability is a specialized craft. These are useful because they let the creature have an address and a pulse without becoming an email company. The product should borrow the pipe, own the membrane, and keep the intelligence close to the user.
Most of the remaining landscape goes into the discard pile for v1.
Themes, layouts, speed-reader modes, swipe customization, and most client polish can wait. Snooze, send later, reminders, and follow-ups matter only when they express metabolic state: this signal is waiting, this one is ripening, this one has become action. Shopping cards, travel cards, receipts, coupons, package trackers, and consumer-detail extraction are ordinary inbox utility, future hygiene rather than creature definition. Read receipts, link tracking, sequences, CRM sync, and outbound-sales analytics optimize persuasion from the sender's side and should stay outside the first prototype. Shared inboxes, assignments, team comments, and load balancing belong to a later household or company blanket. Calendar, tasks, notes, chat, docs, and app-suite integration are all real crossings that pull the product toward suite gravity before the membrane exists.
The restraint matters because every email product is a trap disguised as a roadmap. Each feature is defensible in isolation. Together they recreate the old cockpit: more panels, more switches, more ways to spend the day inside the tool. The Markov Blanket has to resist that gravity. Its first screen can be plain if the crossing is correct. Its first magic should happen in the files and the memory: filter, voice, constitution, inbound decision, outbound artifact, correction.
HEY is the closest ancestor because it understood posture. It made the first gate visible. It named zones of attention. It gave the user permission to refuse the default inbox. The thing to steal is that level of opinion while leaving the closure behind. The next version has to let the user's model leave the product, be read by the user, be corrected by the user, and be inherited by whatever better creature comes next.
Superhuman is worth studying for speed, because slowness kills daily use. Fastmail is worth studying for rules, aliases, exportability, and the feeling that a capable user is being trusted. Shortwave is worth studying because natural-language filters are now table stakes. Proton and StartMail are worth studying because privacy becomes legible when it is tied to concrete affordances like aliases and encryption. Front and Missive are worth studying later because ownership of a conversation becomes hard the moment more than one person can touch it. The API companies are worth using until the product proves it must own more of the pipe.
The build order becomes small and sharp. Give the user an address. Give her aliases with purposes. Let mail and links cross in. Let the creature propose a filter decision and show the rule. Let the user correct the rule in plain language. Turn accepted signal into an artifact, a reply, a note, a public page, or a future action. Let outbound text improve voice. Let refusal improve constitution. Keep a ledger of the crossing so the model can change.
Everything else is later.
The email market has already built the lower floors. Transport works. Search works. Spam defense mostly works. AI summaries will be everywhere. Nice clients will keep getting nicer. The white space is above the feature list: a tool that treats the inbox as the user's active boundary and every message as evidence about the person behind it.
A feature belongs in the first prototype only if it answers the blanket's question: what crosses, why, and how does the self on the inside become clearer afterward?