{"id":23760,"date":"2026-09-06T01:16:25","date_gmt":"2026-09-06T01:16:25","guid":{"rendered":"https:\/\/scannn.com\/email-should-be-the-universal-interface-for-software\/"},"modified":"2026-09-06T01:16:25","modified_gmt":"2026-09-06T01:16:25","slug":"email-should-be-the-universal-interface-for-software","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/email-should-be-the-universal-interface-for-software\/","title":{"rendered":"Email should be the universal interface for software"},"content":{"rendered":"\n
\n

Nearly every button click online kicks off a chain reaction that sends data to a specific server, linked to you and your account. What we see as form fields and buttons and links are, behind the scenes, tools that kick off a stream of data from your computer to a server then back again.<\/p>\n

Which, if you squint, sounds a lot like email. Email, after all, is just structured text\u2014subject, body, recipient address (this person @ this server), sender\u2019s address, and random other odds and ends. It\u2019s an API call of a sort wrapped up as a human-readable letter, complete with the data to identify you as, well, you.<\/p>\n

When you email a colleague telling them about a task they need to do, it\u2019s not all that much different, data-wise, if you squint, from when you assign them a task in an online project management app.<\/p>\n

And squint they did, the earliest software developers, looking for ways to hammer distant computers together. In the days when ARPANET was the best network in town and the world wide web was a half-decade away from invention, computing was far from the standardized platforms it is today, with browsers that work more-or-less the same everywhere. \u201cWe had ports for two different variants of Unix, Motif and Open Look; Mac OS, Windows, NT,\u201d Ray Ozzie told me of the platform part of the challenge in bringing the email-and-everything-else app Lotus Notes<\/a> to market. \u201cWe had to make a decision of resource allocation.\u201d<\/p>\n

Smaller development teams with no resources to allocate had to find a shortcut, a more universal interface that worked on every computing platform, on every desk. The way to nail it, more often than not, turned out to be email. \u201cEveryone has email, right?,\u201d as developer Jon Fuller<\/a> put the email-as-interface argument. \u201cI definitely don\u2019t want to have to go sign up for something, create an account, and download another app\u201d for every new idea, and so email offers a happy medium, a way to interact with software with less commitment for users and less build-out for developers. Which is how email became, alongside terminal commands, one of the longest-running, most consistent software user interfaces.<\/p>\n

No need for an app. Just send an email.<\/p>\n

An App Store over Email, in 1985<\/h2>\n

Communication standards have been co-opted to control machines for as long as they\u2019ve been around. If you can send a message to another human, intermediated by machine, you can also send a message directly to a machine, as long as you teach it what to do with its contents. And therein lies possibility.<\/p>\n

The telegraph may have been invented to send words, dots and dashes at a time, over the wire. But the same wires, the same beeps and buzzes, were used for automated train signaling<\/a>, commercially, five years before Morse tapped out his famous first telegraphic message. Similar ideas relayed commands<\/a> from ship decks to the boiler room, and powered the original ticker tape on Times Square.<\/p>\n

So when email was invented, in 1971, it was only natural that email would borrow inspiration from the telegraph<\/a>, both in message style and in use cases. Email offered identity and a stand-in for accounts; you knew which account sent the message, at any rate, and could trust that your reply would go to their inbox and no one else\u2019s. Email offered a free-form way to send data to a server. As long as that server had code that\u2019d watch for new emails, parse their text, take action on what it said, then send back an email in reply, a simple email could be a software user interface.<\/p>\n

As it was for Netlib<\/a>, a 1985 App Store of sorts, built<\/a> \u201cto fill a need for cost-effective, timely distribution of freely available, high-quality mathematical software to the research community\u201d by Jack Dongarra (later a University of Tennessee professor and Turing Award laureate) and Eric Grosse (later Google VP of Security and Privacy Engineering).<\/p>\n

Software, at the time, was often stored on magnetic tapes, shared internally inside universities and over ARPANET connections, but inaccessible to the growing numbers of researchers using computers around the world. \u201cThere was no convenient mechanism for distributing small pieces of software or individual routines,\u201d wrote the team<\/a> a decade later. \u201cIn addition, there was no central repository for research software. As a result, valuable software produced from research in numerical analysis was often unavailable to others who might benefit from the work.\u201d<\/p>\n

Email to the rescue. Say, as their paper listed as an example, you needed software \u201cto compute several integrals numerically.\u201d You\u2019d send the following email, with a bang-separated email address<\/a> as Netlib launched a year before DNS came to email:<\/p>\n

\n
\n
\n
\n
\n
mail research!netlib <\/span><\/span>\nsend dqag from quadpack<\/span><\/span>\nsend gaussq from go<\/span><\/span>\n<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
Netlib\u2019s server would read the email, strip off any extraneous punctuation or signatures (\u201csince we do get requests like \u2018Please send me the index for port. Thank you.\u2019 from people who don\u2019t realize they are talking to a program,\u201d the team noted), then look up the library and routine names, package up the code, and send it via email.<\/p>\n
\u201cIn a short time, two pieces of mail come back from netlibd<\/em>,\u201d they described, one with each piece of requested software. One could instead email send index<\/code>, for example, to get back a list of all the software on offer, or a whois<\/code> to request a developer\u2019s address and phone number.<\/p>\n
\n
<\/div>\n<\/div>
Netlib was sending nearly 4,000 software downloads a month, over email, two years after launch<\/figcaption>
Netlib was sending nearly 4,000 software downloads a month, over email, two years after launch It worked well enough for the most part, human error aside. \u201cSometimes, by carefully puzzling over other information in the header, a human can guess how to fix the address on failed mail. But netlib doesn’t try to work miracles,\u201d said Grosse<\/a>. It was fast, too, \u201c5 or 10 minutes is typical for ARPANET,\u201d the team report noted, enough that \u201cone user wrote back enthusiastically that the system was so fast he preferred using it to hunting around on his own machine for the library software.\u201d<\/p>\n
All of that, over simple email.<\/p>\n
No need to build a user-facing app or interface, no restricting the software to one operating system or specific computer specs. Email was a universal way to search for and receive software, in the closest thing the \u201880\u2019s had to an App Store or a GitHub-style repository.<\/p>\n
\u201cWe chose this mode of interaction via electronic mail, keeping the intelligence local to the central depository,\u201d stated the team in 1987<\/a>, \u201cbecause mail is at present the only ubiquitous data-communications service.\u201d<\/p>\n
Email as the interface<\/h2>\n
And the idea spread.<\/p>\n
FTPmail<\/a> popped up on university servers, as a way to fetch files on FTP servers over email, in the early \u201890s. MCI Mail<\/a>, by 1993, let you send a fax via email (an idea Dropbox Fax carries on today), and RFC 1486<\/a> tried to standardize print-by-email the same year (still possible today on some printers, such as HP ePrint, even if the standard didn\u2019t take off). Ringo<\/a> gave you music recommendations, over email, in 1994.<\/p>\n
IMDb, even, \u201cwas all done by email,\u201d recalled founder Alan Jay<\/a> about the platform\u2019s early days. \u201cThere was no web.\u201d Its initial recommendations came from the rec.arts.movies<\/code> newsgroup, and you\u2019d email to \u201cquery the database by sending messages like title: Casablanca<\/em> or actor: Meryl Streep<\/em>,\u201d and \u201cit would send you back the cast list or actor\u2019s filmography.\u201d<\/p>\n
\n
\"Posterious<\/div>\n<\/div>
Posterious was a blogging platform built entirely around email.<\/figcaption>
Email was beguilingly simple. No need to design a website or support a new platform. All that was needed was a universal email address, a server with code to parse the messages and do their bidding, and reply emails with the data that users had requested. Not all that different from today\u2019s use of chat with emerging AI services; easier to tap into our existing communications paradigm than to invent something new.<\/p>\n
As web apps and software as a service emerged through the late \u201890\u2019s and early 2000\u2019s, email remained the fallback, a way to fit into the way people already worked without building out all that much infrastructure. No need to worry about slow mobile browsers or installing an app; just open your email app, send a message to your app, and carry on. Remember the Milk, a simple to-do list app, let you email in a whole list of tasks that it\u2019d parse into individual to-dos, in 2005, back when Blackberry was the king of smartphones.<\/p>\n
Task management is an obvious fit for email integration, as so much work happens in inboxes. Trello and Todoist, among other to-do list and project management apps, give you an email address per-project to email in tasks. I Done This takes the opposite approach, emailing you<\/em> each day so you can reply to log what you\u2019ve accomplished.<\/p>\n
Reading is another task that ties in well, with newsletters and blog posts competing for attention alongside personal and work messages. Instapaper, the app to save long-form articles, gives you an email address to forward in newsletters to read later, as does Kindle to let you email articles and books to your device. Readwise takes it one step further, with a unique address you can use to subscribe to newsletters so they bypass your inbox entirely and instead go straight to your reading list.<\/p>\n
Writing is natural enough in the inbox, too, making it a shortcut for publishing blog posts. Posterious, a now-defunct blogging platform, took the idea to its extreme. You\u2019d email [email\u00a0protected]<\/a><\/code>, and it\u2019d both create a new blog for you and publish your message as your first blog post in one fell swoop. The idea, if not the app, lives on today, with WordPress.com (and its companion feature in Jetpack) letting you post by email. And Buttondown\u2019s Magic Email Address<\/a> lets you write and send a newsletter in the most natural way possible, directly from your own email inbox.<\/p>\n
And if your favorite app doesn\u2019t include a built-in email integration, but does connect to automation platforms like Zapier, Make, or IFTTT, you can build your own, having the automation watch for an incoming email then take action on the app you want.<\/p>\n
Email as identity<\/h2>\n
\n
\"Send<\/div>\n<\/div>
You can send a Buttondown newsletter by emailing [email\u00a0protected]<\/a> from your account email, no login required.<\/figcaption>
Even for the apps that aren\u2019t built around email interaction, email still acts as your universal online passport, the common denominator between nearly every tool you use as the way to identify yourself.<\/p>\n
For the earliest email-powered tools like Netlib, that was a boon in building out some of the earliest push notifications. \u201cIn the early days of the Netlib repository, when all access was by e-mail and the traffic was mostly from professional numerical analysts, we relied on log files to send out notification of important bug fixes to everyone who had retrieved affected files,\u201d mentioned Dongarra<\/a> in a 1995 switch to opt-in notifications. But notifying people by email of important fixes based on which packages they\u2019d requested via email made Netlib feel closer to the App Store and its automated updates than anything we\u2019d see for a few decades. No opting in, no accounts needed\u2014an email address tied everything together.<\/p>\n
A similarly unique take on email-as-identity came from Japanese signup forms. Instead of tediously typing out your email address then opening your inbox and clicking a confirmation link, Karamail<\/a> (\u7a7a\u30e1\u30fc\u30eb, or \u201cblank email\u201d) lets you skip the entire process. A Karamail signup process has you tap a mailto:<\/code> link to open your email app with a blank email addressed to the site or app where you\u2019re registering. Tap send, without a subject or body, and you\u2019ll receive a reply with a login link, much like magic sign-in links but with less typing.<\/p>\n
Similar to Posterious\u2019 create-a-blog-by-sending-an-email workflow, the shift from \u201cemail as the lowest common denominator interface\u201d to \u201cemail as a unique way to interact with software\u201d makes you wonder what a more email-centric world could be.<\/p>\n
We\u2019re living in that world, on the publishing side, as social media feeds gave way to newsletters as the default way for serious writers to publish. That, and for authentication, where Slack and others have made magic link sign-in a new standard to keep you from remembering and typing in passwords.<\/p>\n
One could imagine, if you squint, a world where everything was run through email. You have to check your email anyhow. Why not email your apps, while you\u2019re at it, sending tasks to your to-do list and drafting your news newsletter in the app where your followers will read it?<\/p>\n
Turns out, after all these years of designing ever-better app interfaces, maybe email was the best way to communicate with computers and people alike all along.<\/p>\n
Image credits<\/figcaption><\/p>\n
<\/div>\n
Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Nearly every button click online kicks off a chain reaction that sends data to a specific server, linked to you and your account. What we see as form fields and buttons and links are, behind the scenes, tools that kick off a stream of data from your computer to a server then back again. Which, […]<\/p>\n","protected":false},"author":16,"featured_media":23761,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[143],"tags":[],"class_list":["post-23760","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"_links":{"self":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23760","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/comments?post=23760"}],"version-history":[{"count":0,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23760\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media\/23761"}],"wp:attachment":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media?parent=23760"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/categories?post=23760"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/tags?post=23760"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}