Specifying Spring ’83
What follows is a narrative description of a new protocol. I circulated it in June 2022, and it received a warm, engaged response.
Following several months of development and exploration, I wrote some reflections, which are appended below, in the section recounting the summer of Spring ’83.
Near the end of last year, I asked myself:
What do you want from the internet, anyway?
Somewhat to my surprise, I found an answer waiting.
I want to follow people who are interesting to me, in a way that’s simple, expressive, and predictable.
I want this to work, furthermore, whether those people are sharing a random thought every day, a blog post every week, or an art project every two years.
And I want it to work, of course, across media, so I can follow writers, musicians, programmers, theorists, troublemakers …
Pretty basic! And yet, nothing on the internet presently allows me to do this —
“Surely,” you say, “either Twitter, RSS, or email must suffice.”
Well, let’s go through them, quickly.
Twitter’s timeline is a muddle. It’s too uneven; when a user stops speaking, they disappear, and, by corollary, as a follower, you mostly encounter the users who are speaking nonstop. In my memory, Twitter was once a generous router of attention, with an ecology friendly to links; as the years have ticked by, the circle has tightened, and today, Twitter points mostly into itself.
That’s not the only problem. As I wrote earlier:
There are so many ways people might relate to one another online, so many ways exchange and conviviality might be organized. Look at these screens, this wash of pixels, the liquid potential! What a colossal bummer that Twitter eked out a local maximum; that its network effect still (!) consumes the fuel for other possibilities, other explorations.
This means I’m uninterested in the projects that accept Twitter’s design as sensible and try to implement it “better”. (I’m thinking of Mastodon, Scuttlebutt, and Bluesky.) A decentralized or federated timeline is still a timeline, and for me, the timeline is the problem.
RSS is too stark. I follow a lot of RSS feeds, and I appreciate them, and I almost want to leave it at that; nothing’s more boring than re-litigating RSS. I will just observe that there is something about this technology that has seemed, over the years, to scold rather than invite; enclose rather than expand; and strip away rather than layer upon.
For my part, I believe presentation is fused to content; I believe presentation is a kind of content; so RSS cannot be the end of the story.
Email is a retreat. You might have reached this web page through an email. Whew! It worked! The thing is, email inboxes have been algorithmic for a long time, and publishers struggle with Gmail’s caprice almost as much as they do Instagram’s. Furthermore, email’s crusty underpinnings, though they are precisely what make it so sturdy, really pinch at a moment when the web’s expressive power is waxing strong.
For me, the recent resurgence of the email newsletter feels not much like a renaissance, and more like a massing of exhausted refugees in the last reliable shelter. I’m glad we have it; but email cannot be the end of the story, either.
I’m dissembling a bit. The truth is, I reject Twitter, RSS, and email also because … I am hyped up to invent things!
So it came to pass that I found myself dreaming about designs that might satisfy my requirements, while also supporting new interactions, new ways of relating, new aesthetics. At the same time, I read a ton about the early days of the internet. I devoured oral histories; I dug into old protocols.
The crucial spark was RFC 865, published by the great Jon Postel in May 1983. The modern TCP/IP internet had only just come online that January, can you believe it? RFC 865 describes a Quote of the Day Protocol:
A server listens for TCP connections on TCP port 17. Once a connection is established a short message is sent out the connection (and any data received is thrown away). The service closes the connection after sending the quote.
That’s it. That’s the protocol.
I read RFC 865, and I thought about May 1983. How the internet might have felt at that moment. Jon Postel maintained its simple DNS by hand. There was a time when, you wanted a computer to have a name on the internet, you emailed Jon.
There’s a way of thinking about, and with, the internet of that era that isn’t mere nostalgia, but rather a conjuring of the deep opportunities and excitements of this global machine. I’ll say it again. There are so many ways people might relate to one another online, so many ways exchange and conviviality might be organized.
Spring ’83 isn’t over yet.
From my lab notebook:
FIRST LIGHT: successful request to server, cryptographic verification in browser, and display, on Sun April 24 at 3:42 pm.
The transmission side of the protocol is a tiny HTTP API; the display side is a simple set of rules. Put together, they help users follow publishers —
Here’s the current draft specification. I hope it is legible to the spec-readers among you; this is, I have discovered, a really difficult kind of writing!
I want to say: I recommend this kind of project, this flavor of puzzle, to anyone who feels tangled up by the present state of the internet. Protocol design is a form of investigation and critique. Even if what I describe below goes nowhere, I’ll be very glad to have done this thinking and writing. I found it challenging and energizing.
On the client side, Spring ’83 rejects the timeline and the inbox, aspiring instead to the logic of newspaper classifieds —
—and vintage comic books ads —
—and magazine racks:
A touch of chaos? Yes. More importantly, every board holds its place, regardless of when it was last updated. Each publisher maintains just one; there is no concept of a history. Think instead of a whiteboard that is amended or erased, or a magazine replaced with the new edition.
Client applications display all the boards you are following together, laying them out on a 2D canvas, producing unplanned juxtapositions, just like the newsstand above. Boards might be:
- mini home pages, updated regularly with new work
- lists of links to web pages recently read, perhaps with brief notes
- daily logs, wiped clean each morning
- yawps to the universe
Some boards will be baroque CSS confections, others a sentence and a link in the system font, still others blaring
<h1>s. Some publishers will be friends, others anonymous geniuses, still others robots. You’ll follow and unfollow publishers with a simple interface defined by the client, not the protocol.
Spring ’83 clients combine following and publishing. A board isn’t a project you manage separately; it’s a chunk of HTML you edit right there alongside the others, perhaps assisted by a simple template.
You might react to a book with a board like this:
Just finished Ways of Being, the new Bridle book. What a kaleidoscope. The material on alternative approaches to computing, including liquid computers (!), was fascinating.
- The Mountain in the Sea
- Frankenstein audiobook
- A truckload of Edgar Allan Poe
💌 Recs welcome!
Or with one like this:
This book is so good it's making me mad
Hmm, nice gradient. I could use one of those. No problem: clients always support View Source.
You might update your board twice an hour or twice a month; you might amend one sentence or reboot the whole thing. Publishing a new version is instantaneous, as easy as tapping a button. You don’t have to manage a server to publish a board; you don’t even have to establish an account on a server.
Spring ’83 doesn’t formalize interactions and relationships. The protocol doesn’t provide any mechanism for replies, likes, favorites, or, indeed, feedback of any kind. Publishers are encouraged to use the full flexibility of HTML to develop their own approaches, inviting readers to respond via email, join a live chat, send a postcard … whatever!
This is a “pull-only” protocol. As a user, you don’t see anything you didn’t specifically ask to see; no notifications, no recommendations, no unsolicited messages.
There are no analytics, obviously. Nothing is counted. Boards can’t load tracking pixels, and they can’t ping remote analytics APIs. Sorry, folks … you’ve got to let go of the numbers. In 2022, they are not helpful feedback, but rather a clear warning you are in the wrong place.
This raises the question, how can a network that abjures all these dark patterns possibly grow? The only possible answer is: I don’t know! Maybe we’ll figure it out together.
Let’s turn to the server side. The transmission protocol, a tiny HTTP API, is outlined in the spec. There are two things to know:
In operation, a Spring ’83 server is mostly a “plain old web” server.
Boards are cryptographically signed in such a way that they can be passed from server to server and, no matter where your client gets a copy of a publisher’s board, you can be assured it is valid.
The underlying cryptography is simple, totally off the rack, but still, every time I think about it, I’m astonished it works. Because publishers are identified by public keys, and because their boards are signed using those same public keys, the publisher/board link is “self-certifying”, a term gleaned from David Mazières’s 2000 Ph.D thesis.
In a self-certifying system, content carries its own durable provenance, allowing a network of servers to share it between them, and if one or two or a hundred are malefactors bent on deception, who cares? They can’t fool us.
So … who runs these servers?
A large fraction of my thinking about this protocol has consisted of me squirming out of actually operating infrastructure. I squirm still. My appetite for maintaining a server is infinitesimal. I whine to myself: can’t I just propose something? Do I really have to operate it?
Then, I remember a conversation with Hannu Rajaniemi about Frankenstein, one in which Hannu lamented the novel’s common portrayal as a cautionary tale about scientific hubris. In fact, Hannu argued, Frankenstein’s tragic mistake was not creating the monster. Mary Shelley makes this very, very clear: the great mistake was abandoning him.
Fine, okay, I get it! And yet: the last thing I want to do is start an internet business, even a cute, “sustainable” one. Databases terrify me. I’m offline for long stretches of the year. How is this possibly going to work?
Well, here’s an argument for you. Protocols aren’t only for using; they are for implementing. That’s part of their value in the world. They support negotations between devices, yes —
Spring ’83 is very simple, so I hope it might invite implementation, just for fun, in your favorite programming language, on your weirdest device, with plenty of elbow room for experimentation and innovation.
So that’s the idea. On the client side, a lightweight HTML magazine rack offered as an alternative to the timeline; on the server side, a federated network that tries to be more than just a burden to its operators, with an invitation to invent and explore.
I’m distributing this to you as an RRFFCC, which of course stands for Robin’s Request For Friendly Critique and Comment. For my part, I’ll continue to test my reference implementation with a very small group of people. I’m in no great rush with this —
It was the experience of drafting the spec that changed my view, and my pace. Writing! Gets you every time! It also helped me understand the appeal of the crypto white papers, honestly. Documents like these give you an opportunity to boot something up in your head, examine it in a way that’s technical, sure, but also literary, imaginative, maybe even dreamlike … I don’t know; I like it!
Anyway … I wonder if you might want some of the same things from the internet that I do. I wonder if you, too, might be hyped up to invent things. If so, I invite discussion all up and down the ladder of abstraction, from the protocol’s broad aims to its specific strategies. Send me a note,
firstname.lastname@example.org, or publish your thoughts and pass along the link. I’ll add it here.
In another year it will be Spring 2023, the modern internet’s fortieth birthday. Four decades is nothing —
After circulating this newsletter, I received a ton of terrific email correspondence, and several folks published their thoughts online.
Here’s a public consideration from Darius Kazemi.
Here are some musings from Tracy Durnell, focused on design.
Here are some notes and questions (fronted by a very kind meme) from Louis Potok, who traces the spec’s logic into a few interesting corners and edges.
Here’s a wide-ranging consideration from Maya, who maintains one of the great modern home pages; I am a longtime admirer and reader.
Here are some thoughts from makeworld, complete with suggestions and (very welcome) nitpicks.
And then, what followed was a season of actually using this protocol. Amazing! I’ll now reflect on …
The summer of Spring ’83
The first thing to say is, it worked! This document and the related specification inspired a ton of discussion. Better yet, they inspired implementation. You’ll find some great work linked in the GitHub project.
(Of particular note is Ryan Murphy’s
<spring-board> element, which encapsulates a whole Spring ’83 “board”, described above, into a reusable HTML5 Web Component. My web programming skill level is still anchored somewhere around 2010, so Ryan’s custom element feels, to me, like magic.)
What else happened? Well, people used —
My aspirational comparison with vintage comic books ads —
—turned out to be pretty apt. It looked eye-poppingly great.
By any measure: we stood up a protocol.
It is, however, very clear that Spring ’83 is not going to be “the next Twitter”, or “the next RSS”, or the next anything, really.
This is fine!
Indeed, I want to make a case for protocols —
I believe I learned a few things this summer, and I’ll jot them down below.
First, though, I want to repeat something from above: I really strongly recommend this exercise to anyone who feels dissatisfied with their options on the internet today. Give it a few evenings. Imagine something new; describe it as clearly as you can. You don’t have to actually build your something —
Now, here are a few jotted findings, left as notes along the path for future protocol-specifiers. This is all written in the past tense, which isn’t totally correct; some people, including me, are still using my demo client! But the present tense would feel too much like the forced cheer of a faltering startup. More to the point, it’s going to be a while before I, personally, do any more development on this protocol, or another one like it.
So, for me, the past tense is appropriate —
Here are my notes for fellow travelers.
Your protocol is too complicated
My initial specification of Spring ’83 was, I thought, very simple. Apparently not simple enough: in the months following its publication, most of my revisions were deletions.
Protocol specification plays into two key weaknessess of many technical people:
The desire to show off
The desire to say, “Don’t worry, I already thought of that”
My first draft of the Spring ’83 spec had material of both flavors, and it’s precisely that material that’s now been blasted away.
Keep it simple. It’s okay if you didn’t already think of it. You want people to implement this, don’t you? Keep it simple!
People really want to mention each other
A core part of this protocol’s design is that no messages are ever pushed; you get only what you ask for. As such, the “mention”, as experienced on Twitter and Instagram, doesn’t exist in Spring ’83. And yet! People still mentioned each other! The mentions were makeshift, inert, but they “worked”, because the universe was so small and we were all reading basically all the boards. And even if they didn’t work, the urge was still so strong! Overwhelming.
I guess you just can’t keep conversation out of it, where humans are involved.
Mentions seem simple, but I think they’re hugely fraught, and not only when they become a vector for harassment and abuse. I suspect the fairy tales tell us something real and true: names have power, and the invocation of a name always carries an impact. Even when it’s nothing but nice! Like ringing a bell.
I don’t, however, think the solution is a jet cockpit’s worth of access controls. Rather, I suspect there might be some clever new formulation of the “mention” waiting out there, just waiting to be discovered …
Public keys are a demon’s bargain
Spring ’83 uses public key cryptography for user identification and verification. Even as the specifier of this protocol, the person who brought those techniques into it … these keys were totally excruciatingly annoying.
It’s like a bargain out of a fable. Public key identifiers give you all these incredible powers, and they seem to spring out of nowhere —
The more you think about it, the funnier it gets.
DEMON: Human, I shall grant thee a name that none may imitate!
HUMAN: Wow, that’s so cool. What a gift! Okay, what’s my name?
DEMON: Known thee shall be as 1e4bed50500036e8e2 —
HUMAN: *walks away*
There’s no free lunch. I still find the capabilities of these magic numbers tantalizing, but I do not think I will include them in my next protocol.
Three cheers for HTML and CSS
You would not BELIEVE the boards people made. Not all were gonzo; many were sober, very clear and “designer-y”, in the best possible way. But some were gonzo, too, and this, more than anything, was the triumph of the summer of Spring ’83: a chorus of cheers for modern HTML and CSS, and all the ways you can express yourself with them, and in them.
The weakness of the protocol, as presented in my demo client, was that you could only design your board by writing raw HTML and CSS. That’s fine for the nerdiest among us, but still a bit forbidding for everyone else. A better client would provide built-in templates, maybe a little WYSIWIG editor —
For my part, I settled on a simple design: a blood-red headline in 72-pixel italic Bodoni over an acid green background. Someone said to me, not a little bit archly, “So, really, you made all of this because wanted to tweet in a 72-pixel font.”
And I had to confess that maybe I did.
On this front, I am an evangelist: arbitrary HTML and CSS should have a place in our social networks. They are so expressive, and they are available everywhere, on every device, essentially “for free”.
How do you run a platform slow but steady? Unclear
The whole premise of Spring ’83 was a protocol with a slower cadence. Indeed, after the summer’s flurry of activity, I’m now updating my board about once a month. In many ways, this is great. But … how do you build a habit of “checking in” when not much is changing? I struggled with this myself. Even during the summer, in the protocol’s fullest bloom, I would forget about my demo client for days! A week! It just did not —
Platform design seems to me now like a sharp hilltop with steep slopes descending in both directions. A platform built around twitchy compulsion will trend towards addiction; a platform built around stolid patience will trend towards … forgetting about it.
If only you could balance perfectly at the summit. Alas, I don’t think it’s possible.
The problem is that even when patience “wins”, it loses, because patience retreats, while compulsion compounds. What do I mean? Over the years, I’ve broken many of my twitchiest compulsions, and I’m much better off for it —
So, the partisans of patience need some new tricks. We need ways of claiming space on screens —
This is totally doable. These new tricks need only to be invented —
Who wants to host content? Nobody normal
My little Spring ’83 server has hosted, in total, probably 40 or 50 people’s boards: a miniscule burden, by any standard. But I report to you truthfully that this was, for me, a source of incredible stress, all summer long. My reaction made me realize something:
It takes a weird kind of person to want to host other people’s content.
Like, it’s kind of insane! Host content for people who you don’t KNOW? And take on, perforce, either (a) the obligation to moderate it upfront, reading everything —
Digital spaces are sometimes analogized to homes or restaurants, with the implication that of course you’re free to kick someone out, just as you would in your home or restaurant. Back before I’d ever hosted anything for anyone, I nodded along to this analogy, but now I see that it’s incomplete, because people only visit your home or restaurant while you’re there. These real spaces are, by the standards of digital spaces, almost impossibly well-moderated.
That’s what made my stomach churn: the reality that I’m not always, or even usually, at my computer.
Obviously, many people are not so concerned about this. The policy of reacting to harassment or abuse or vileness on a “best-effort” basis seems, to them, good enough. “Best effort” is, of course, the most I could aspire to —
Keep in mind, this was while everything I hosted was unfailingly nice and fun. If something had appeared that was actually vile —
(Who IS cut out for it? Perhaps only the people truly hungry for scale, who can separate themselves from the systems they’re operating. I’m trying not to be too dire and judgmental here, but honestly, I think it might be inhuman. I think you might have to make yourself into a kind of machine to be okay with “best effort”.)
This suggests a challenge: could you design a protocol that truly makes people responsible for their own content, eliminating or at least blunting the peril and stress of hosting? That puts us back in the world of “everybody should just host their own content on their own website”, which is, of course, what some people have been saying for decades. Well, it hasn’t caught on yet, and I don’t see any indication that it will … but maybe there is some analogy available, some reproduction of that arrangement on a different level, that could begin to address this challenge.
It’s ironic: in the development of this protocol, I spent more time thinking about abuse than anything else, by far. During the summer of Spring ’83, largely by dint of the size (very small) and quality (very high) of the protocol’s userbase, abuse was a non-issue. In a way, I wish I had just … chilled out. But, again, I think it might take a weird kind of person to do so.
A new era of protocols is upon us
You feel it, don’t you? They’re all crumbling, the platforms of the last decade. It’s unsettling, but/and also undeniably exciting. Tall trees fall in the forest, and light streams down, nourishing places it hasn’t reached in ages.
But we, as users of the global internet, cannot just ride the same rollercoaster again. It’s too embarrassing to be trapped inside these hungry corporate gambits, these dumb proper nouns. The nouns and verbs of our online relationships should be lowercase, the way “magazine” is lowercase, the way “movie” is lowercase. Anybody can make a movie. Anybody can try.
New protocols abound, and more are on their way. In the months and years ahead, as you explore and evaluate them, I encourage you to ask this question:
Does this protocol recreate something that already exists?
The opportunity before us, as investigators and experimenters in the 2020s, isn’t to make Twitter or Tumblr or Instagram again, just “in a better way” this time. Repeating myself from above: a decentralized or federated timeline is still a timeline, and for me, the timeline is the problem.
This digital medium remains liquid, protean, full of potential. Even after a decade of stasis, these pixels, and the ways of relating behind them, will eagerly become whatever you imagine.
November 2022, Oakland