December 7, 2020

Eye of Newt and Stack of Sub

Why I am annoyed

Email is a big step backward in a lot of ways from RSS✱, both technically, and in terms of relationships.

✱ When I write RSS I mean all Web syndication feed technology, not just the one particular syntax specification.

More manual labour for everybody

I am skeptical of any technological "improvement" that requires me to do by hand what was previously automated. What I liked about RSS was that it was largely unobtrusive. Your feed reader is off in its own corner, and you only look at it when you want to. It required almost no maintenance, save for the occasional folder shuffle.

Email, by contrast, gets up in your face. Everything is mixed together, and the default behaviour is to interrupt you with notifications. Even an aggressive email filer like myself can’t keep on top of things landing into my inbox. I don’t know how other people handle this, but every new subscription to a mailing list or newsletter elicits a big sigh when I have to log in to the Web interface and set up a new filter rule, because there is no way to do that through an ordinary IMAP client. If you don’t do this though, are you just letting everything get jumbled together? Or are you filing your emails by hand?

There is actually a standard language called Sieve for expressing email filters, along with a managesieve protocol for manipulating them, but nothing actually uses it. Really, though, why don’t email clients—or servers—automatically create folders for, and filter messages with List-* headers?

This spike in manual labour is echoed on the publishing side. RSS is handled automatically: I don’t have to think about it; a script just punts out the updated feed and the readers pick it up. A newsletter means I have to format every document and send it out by hand.

On the subject of formatting

RSS could refer you to a webpage, or it could be the webpage, or both. Email only offers the option of being the webpage with a crappy ad-hoc reference to a webpage, so something that was standardized in feeds has been de-standardized in email.

An email client begins with the grounding assumption that anybody in the world can send you email, which means, at least in theory, it has to be maximally paranoid about what it shows you.

The problem with email being effectively pushed to you from any other point in the world is spam, scams/phishing, and malware. I saw plenty of creative examples when I worked in antispam in 2006-07; no doubt it is mounds more sophisticated now. The way vendors have responded to this situation is by clamping down what the email client’s rendering engine will show the user, and the most aggressive of these is Outlook on Windows, which was retrofitted years ago to use the HTML renderer from Microsoft Word. Outlook only appears to account for 10% of all email clients✱ but just about anybody in an office running Windows is going to be using Outlook, so they ruin it for everybody.

✱ Note the stats say the iPhone mail client and the Android native GMail clients are the biggest, so take that 10% share by Outlook with a grain of salt. A lot of those clients are going to be redundant because we tend to connect to the same email account with multiple devices.

The mere existence of Outlook on Windows constrains the markup you can send in an email to circa-dotcom-1.0 sophistication. It is an abject mess. Though, even if Outlook was erased from the planet, the markup you can reliably expect to send in an email is still extremely limited. Indeed, I have been planning to move in the direction of more composite, more hypertext-y content, which I will categorically not be able to deliver in a newsletter. Those are going to have to be straight-up WWW.

It raises the minimum engagement for readers

With a newsletter, you require your readers to consent to you contacting them, and in the process, give you their contact information. This is not the same as just letting them sniff your digital offgassing. They have to tell you they want it, and if they don’t want it anymore, they have to tell you they don’t want it.

You absolutely require an intermediary

From mid-2002 through mid-2005, I sent email for a living. Actually getting email to land in somebody’s inbox with some reliability is a pain in the ass. Back then, though, this was mainly a technical proposition: you just made sure you were RFC-compliant, and the mail would get through. Nowadays, I wouldn’t be so sure. Indeed, I would be extremely surprised if there was zero payola involved between the big bulk senders and the big email providers.

Unlike RSS, where you don’t have to think about delivering your content or what it looks like when it gets there, the vagaries of email—both servers and clients—are so vast that you really need a partner for whom email is their core competency.

I totally get why things went this way though

People blame Google pulling their Reader product for the death✱ of RSS but I think a better take is that Google Reader was temporarily plugging a hole that nobody else managed to properly fill.

✱ Rumours of the death of RSS are greatly exaggerated; rather, it just grew into its arguably more appropriate role as behind-the-scenes infrastructure.

Not that the gap could have been spanned by any single entity smaller than Google. The problem with RSS is that the median internet user doesn’t have the faintest idea what to do with it.

It isn’t obvious what to do with an RSS link. If you open one and you don’t know what you’re looking at, it looks like a mistake. Individual publishers could conceivably dress up RSS feeds and put instructions on them, but we would need each publisher, or at least their respective content management systems, to put up the styling and copywriting effort. The only other point of intervention is the browser: Firefox did put a rudimentary stylesheet and explanatory heading on feeds for a while, but has since gotten rid of that feature.

It is also not obvious that to use RSS you need a separate piece of software, whether that is a distinct service or on your machine. Some browsers had rudimentary RSS capabilities, as did some email clients, but in order to make the most of RSS, you really need a purpose-specific product. 25 years ago, you could rely on your dial-up ISP to ship you a bunch of apps on their get-started floppy disk, and two essentials would have been an email client and a Web browser. If RSS had existed back then, it probably would have been on that shortlist too, and clicking a feed link would magically bring up the correct app. That essential connection just doesn’t exist anymore.

I suppose every operating system has its own app store now, such that opening an unrecognized MIME type will trigger the "find in app store" functionality. It would be interesting to know how well that converts. I know that if I open an .atom file on MacOS Catalina and follow the "Search on App Store" link, it just plunks me into the main app store screen.

This brings me to the feed reader apps themselves: these are sort of awkward hybrids between an email client and a Web browser that, modulo some interesting exceptions, never really evolved past that goofy axolotl stage.

For starters, consider the notion of an unread count. Makes sense for email—which is nominally addressed to you—but is totally meaningless when considering a bottomless pit of syndicated content. Same deal with the three-pane interface, another idiom copied and pasted from email that only a few products ever attempted to deviate from.

There is one thing that email—modern email at least—does on the client side, and that’s maintain a consistent state across multiple devices, which it does using the IMAP protocol. Since RSS happens over HTTP, the IMAP of RSS is…HTTP.

This poses a problem for people designing feed reader applications. Classic desktop feed readers are like POP clients for email: they only store the state in one place. Nowadays, though, it’s likely that we’re interfacing with the same information on three or four devices. When a new item comes in while we’re on our phone, we don’t want to be notified again when we look at our feeds on our laptop or tablet. We likewise want any additions, manipulations or rearrangements we do to our feed library to be propagated everywhere, no matter where we issue our changes. This shared-state behaviour is essential.

From the point of view of an app developer, this obviously means you store the state on a server, and have thin-ish clients that connect to it. Unlike IMAP though—a standard interface with well-defined data semantics—you would be stuck inventing that protocol, with unclear benefit to you, unless you skip that part, set up a platform, and intermediate the experience entirely.

What I mean here is that IMAP, again for the purpose of example, defines a set of conceptual entities like message and mailbox, along with a set of verbs for manipulating those entities, as well as a precise set of expectations for what is supposed to happen when those verbs are applied to those entities. That is all stuff you would have to design if you were going to try to create an analogue for RSS.

When I say "intermediate the experience entirely", I’m suggesting, as a business model, that it’s a zillion times easier—and less risky, and more profitable—to make a product that aggregates RSS feeds on the back end, and does something with them other than a general-purpose feed-aggregating product: you don’t have to screw around designing protocols and native client applications only to create a commodity that can be easily substituted by a competitor.

So I guess my overarching argument here, regarding the peculiarities of the general-purpose RSS feed aggregator application archetype, and moreover implementing one such that you accrue more than extremely niche adoption, is that you basically had to be Google to pull it off. Google, true to form, puts a bullet in its successful product, torpedoes an entire ecosystem, so here we are bringing email newsletters back.

You can monetize it a heck of a lot easier, I guess

Nominally, at least. Newsletters are easier to monetize because the aforementioned intermediaries went and built out that infrastructure. There was, nor is, nothing in principle preventing charging readers for an RSS feed.

Metrics!

Oh right, I almost forgot. There’s one thing you ostensibly✱ couldn’t do with RSS that you can do with email, and that’s metrics. In email you can—indeed you are expected to—wire up every image and link with a unique identifier, so you can detect who opened the email and took what subsequent action.

✱ There is nothing in principle preventing this kind of infrastructure for RSS: common conventions around the sensorium for RSS feeds were just never really built out to the extent that they already existed for email. For example, if you wanted to track actions on a feed, back to an individual person, you would have to authenticate them somehow, and support for authentication on a feed is not something you could rely on from the client side.

I do not super care about metrics because I personally evade them whenever possible, and I expect a number of my readers to do the same. If anything, email open stats both overcount and undercount people actually reading the content because all you have to do is shut off images and not click on any links to not be counted. And of course, counted or not, just because you open an email doesn’t mean you actually read it.

Conclusion: I have created a Substack account

I put a considerable amount of thought into what precisely the contours of a newsletter ought to be. My initial thought was to simply use email as a new channel for the same content, potentially privileging newsletter subscribers by delaying publishing of articles to the website. I couldn’t convince myself this idea was a good one.

Email is where information goes to die. Email exists in a bizarre superposition of transience and permanence; it is highly perishable, and yet somehow it accumulates. The articles on my site, by contrast, deliberately exist as far outside of time as I can make them. Although they are often prompted by current events, they rarely engage directly with them, and instead focus on slower-moving themes. This is by design. Instead, I feel I should take advantage of email as a medium, and embrace the forced contemporaneity. In a way, newsletters are bloggier than blogs.

So here is the pitch: I begin writing a newsletter that will roughly reduce to the things I notice that make me think about the things I write about. The tone I’m aiming for is somewhere in between the shitposting of Twitter and the earnest of an actual essay. Indeed, I anticipate the role of the newsletter will largely be to directly connect the two. As for the length: ideally it will fit on one desktop or tablet screen, and maybe two screens on a phone. My ultimate goal is to make something you’ll actually read, without feeling guilty about eventually deleting it.

Finally, I’m hoping with this newsletter I can address a broader, or at least a more diverse audience than just tech industry insiders. Where I’m at with "technology"—that is to say, computers—is that they have been mundane pieces of everyday life for decades, and they don’t deserve the fawning and magisterial whizz-bang portrayal they get in the media. Indeed, once you strip away the veneer of "tech", it’s the same old shenanigans any stone-ager would recognize. Expect me to write a lot in the orbit of that. I will probably also be writing more about things like art. Hell, I might even throw in some bad poetry.